Skip to content

Unusual actors and scenarios

Your system doesn’t live in a bubble — it interacts with many actors. An actor can be a person, system, device, event, or even a rule that influences how your software behaves. This activity helps you discover actors you might have missed when writing your use cases.

What You’ll Do

  1. Start with your own project. Open your use cases or notes — you’ll expand them.
  2. You’ll get a few hint categories For each, try to list as many possible actors as you can, per team, while tutor there to answer questions.
  3. Work fast and creatively. Don’t judge your ideas yet — write them all down. Quantity first!
  4. Compare with others. Share and discuss what you found. You’ll probably discover new perspectives from your teammates.
  5. Reflect. Which categories were easy? Which ones surprised you? Did you find any missing cases or contradictions?

Hint Categories

Challenge Bonus: Actor Hunters

For each actor category, the team that identifies the most distinct and well-defined actors during class earns +1 bonus point. Counting only unique definitions — not repeats like “student1, student2.” Be creative, justify your reasoning, and explore all corners of your system! (Ties get no the points.)

Easy (obvious actors)

  1. Human User – Any person who directly interacts with the system (e.g., customer, employee, admin).
  2. External System – Other software or platforms your system exchanges data with (e.g., payment gateway, API, university database).
  3. Hardware Device – Physical devices that send or receive data (e.g., sensors, printers, smartcards, scanners).

Medium (indirect or situational actors)

  1. Time / Event – Scheduled or spontaneous triggers that cause actions (e.g., midnight batch job, end-of-month report, alarm event).
  2. Organization / Role – Groups or positions that represent authority or policy (e.g., management, IT department, partner company).
  3. Regulation / Policy – Laws, standards, or internal rules that constrain system behavior (e.g., GDPR, safety procedures).
  4. Data Source – Databases, documents, or streams that provide input the system depends on (e.g., sensor logs, CSV uploads).

Tricky (abstract or hidden influences)

  1. Place / Environment – Locations or contexts that change how the system behaves (e.g., factory floor, mobile network coverage).
  2. Failure / Exception – Unexpected conditions that act like “negative” actors (e.g., power outage, network loss, invalid input).
  3. Stakeholder with No Direct Access – People or groups affected by the system but not using it directly (e.g., auditors, customers of your customer, community members).

Why It Matters

If you miss an actor, you miss a part of reality. That means your system might ignore something important — a background process, a regulation, or even a forgotten user. Spotting these now makes your use cases more complete, consistent, and realistic.

Tip

Think beyond “the user.” Anything that affects, triggers, or is affected by your system might count as an actor.