Identifying Actors and Scenarios in Real Projects

When I first worked on a healthcare system, I spent days drawing use cases—only to realize we’d missed a critical external system: the national patient registry. It wasn’t just a missing detail; it was a failure to ask the right questions about who or what interacts with the system. That moment taught me: identifying use case actors isn’t about guessing. It’s about listening to your system’s environment.

Use case actors are the lifelines of functional modeling. They’re not just users. They’re any entity—people, systems, or devices—that initiates or receives behavior from your system. If you skip this step, your use cases will miss key interactions, and your software will be built on assumptions, not requirements.

What you’ll learn here is how to spot these actors reliably in real projects, avoid common traps, and turn user needs into clear, actionable use case scenarios. You’ll walk away with a repeatable process, not just theory.

Start with the Right Questions: The First Step to Finding Use Case Actors

Don’t start by drawing boxes. Start by asking: who or what uses this system—or is affected by it?

Begin with the system boundary. Define the scope first. Then ask who or what crosses that boundary to trigger behavior.

Here’s a simple but powerful checklist to guide you:

• Who performs actions like login, submit, or approve?
• Who receives outputs like reports, alerts, or confirmations?
• Is there an external system that sends data or expects a response?
• Does any device or service interact automatically (e.g., IoT sensor, payment gateway)?

These questions shift focus from “what can the system do” to “who has a stake in it?”

Real-World Example: Online Grocery Ordering

Let’s say you’re modeling a grocery delivery app. You might start with these actors:

• Customer: places orders, views inventory.
• Delivery Driver: receives pickup instructions, updates delivery status.
• Payment Gateway: processes credit card charges.
• Inventory System: updates stock levels after an order is confirmed.

See how the Payment Gateway isn’t a user. It’s an external system that interacts with your app. Yet if you miss it during initial modeling, your payment process will be incomplete.

Common Pitfalls in Identifying Actors in UML

Even experienced modelers stumble here. Let’s break down the top three:

1. Confusing Actors with Roles

Not every role in a business process is a use case actor. A “Manager” might be a role, but if they don’t initiate or receive behavior from the system, they’re not an actor.

Ask: Does this role trigger or receive an action from the system? If not, it’s likely a participant in a scenario, not an actor.

2. Overlooking External Systems

Many beginners focus only on people. But systems—like a weather API, a bank’s fraud detection system, or a CRM—often drive behavior.

Tip: When reviewing requirements, watch for phrases like “integrated with,” “connected to,” or “sends data to.” These signal potential actors.

3. Treating Use Cases as Actors

Use cases are actions: “Place Order,” “Cancel Payment.” They don’t initiate behavior—they’re performed by actors.

Don’t confuse: Customer places order. The actor is Customer, the use case is Place Order.

Step-by-Step Guide to Derive Use Cases from Requirements

Use case actors are the trigger. Use cases are the response. Here’s how to turn stakeholder needs into real use cases.

1. Identify all actors: Use the checklist above. Write each down.
2. For each actor, ask: “What do they need from the system?” Focus on goals.
3. Group similar needs: Two users might both need to “view their orders,” but if the data or permissions differ, they may have different use cases.
4. Phrase use cases as goals: Start with a verb. “Pay for order,” “Cancel reservation,” “Receive confirmation email.”
5. Validate with stakeholders: Run the list past users or domain experts. If they say “That’s not what I do,” refine the use case.

Example: Refining a Use Case from a Requirement

Requirement: “The system must allow customers to change their delivery address.”

Step 1: Actor is Customer.

Step 2: What do they need? To update their delivery address.

Step 3: Phrase it: Update Delivery Address.

Step 4: Ask: Does this cover all scenarios? What if the address is invalid? What if the user has no saved addresses? That’s where sub-steps and exceptions come in later.

Practical Tips for Beginner Use Case Scenarios

Use case scenarios are the narrative behind the diagram. They’re not just a list—they’re stories of how the system behaves in real contexts.

A common mistake is writing overly technical or vague descriptions. Instead, use the Actor + Goal + Action pattern:

• Customer wants to update their delivery address, so they select the profile menu, choose “Edit Address,” enter new details, and confirm.

Keep scenarios short, specific, and goal-driven. Avoid details like “click the blue button”—focus on intent, not interface elements.

Here’s how to make your beginner use case scenarios more effective:

• Start with the actor’s goal: “I want to cancel a reservation.”
• Use active voice: “User clicks ‘Cancel’” not “Cancellation is processed.”
• Include key variations: What if the reservation is already past the cancellation deadline?
• Use natural language: Avoid technical jargon unless necessary.

How to Find Use Cases: A Reality Check

Let’s be clear: you won’t get it perfect on the first try. The goal isn’t perfection—it’s clarity and coverage.

Here’s a table summarizing how to approach each step:

Step	Action	Why It Matters
1. Spot stakeholders	List every person, system, or device interacting with your app	Ensures no key interactions are missed
2. Ask “What do they want?”	Focus on the user’s goal, not the feature	Aligns use cases with real needs
3. Avoid overloading	Split large use cases (e.g., “Manage Order”) into smaller ones	Improves readability and testability
4. Review for completeness	Check if every actor has at least one interaction	Prevents missing critical flows

Remember: the goal of use case modeling isn’t to draw a perfect diagram. It’s to uncover what the system must do—and who it’s for.

Frequently Asked Questions

How to find use cases when requirements are vague?

Start by identifying actors. If a requirement says “the system handles orders,” ask: “Who places these orders? Who receives confirmation? Who processes payment?” Each answer points to a potential use case. Use phrases like “X needs to…” or “Y expects…” to uncover hidden goals.

How to identify actors in UML when multiple users share the same role?

Group them under one actor if they perform the same actions with the same permissions. For example, “Cashier” and “Manager” in a store app might both handle returns. But if managers can approve more than $100 refunds and cashiers can’t, they should be separate actors with different use cases.

What’s the best way to write use case scenarios for beginners?

Use the “Actor + Goal + Action” format. Keep it simple. Describe the main success scenario (happy path), then add alternate paths like invalid input or system failure. Use natural language—aim for clarity, not jargon.

Can an actor be a system or a device?

Absolutely. External systems like a payment processor, weather API, or a sensor device are valid actors. They initiate or receive behavior. Example: “Payment Gateway” sends confirmation; “IoT Thermostat” triggers a home automation event.

Why do use case actors matter for software design?

They define the system’s boundaries. Without clear actors, your use cases may not cover all stakeholder needs. This leads to missing features, incorrect assumptions, and costly rework later. Use case actors help align design with real-world behavior.

How often should you revisit use case actors during development?

Revisit them early and often. As the project evolves, new actors may emerge—like a third-party audit system or a new device interface. Review use cases during sprint planning or after stakeholder feedback to ensure nothing has changed.