Actors and Use Cases — The Foundation of Requirements Visualization - Use Case Diagrams | OneNoughtOne

0/246

System DesignUML & Design Representation

Use Case Diagrams — Requirements Capture

LevelBeginner

Duration50 mins

TopicUML & Design Representation

1 / 4

Actors and Use Cases — The Foundation of Requirements Visualization

The Bridge Between Stakeholders and Engineers

Every software system exists to serve users. Yet the journey from understanding what users need to building software that meets those needs is fraught with miscommunication, ambiguity, and missed expectations. Use case diagrams represent one of the most powerful tools in a system designer's arsenal for bridging this gap—providing a visual language that both technical and non-technical stakeholders can understand.

At their core, use case diagrams answer a deceptively simple question: Who interacts with our system, and what can they do? This seemingly straightforward question, when answered rigorously, reveals the functional scope of any software system and establishes a shared understanding between everyone involved in building it.

What You Will Learn

By the end of this page, you will understand the fundamental concepts of actors and use cases—the two primary building blocks of use case diagrams. You'll learn how to identify actors from different perspectives, define meaningful use cases that capture user goals, and understand why these diagrams remain essential in modern software development despite being a decades-old technique.

What Are Use Case Diagrams?

A use case diagram is a behavioral UML diagram that captures the functional requirements of a system from the user's perspective. Unlike class diagrams (which show structure) or sequence diagrams (which show interactions over time), use case diagrams operate at the highest level of abstraction—depicting what a system does without specifying how it accomplishes those functions.

Historical Context:

Use case diagrams emerged from the pioneering work of Ivar Jacobson in the late 1980s while he was at Ericsson developing object-oriented software engineering methods. Jacobson observed that capturing requirements from the user's perspective—rather than from a technical or data-centric viewpoint—produced systems that better aligned with actual user needs. His approach was later incorporated into the Unified Modeling Language (UML) and became a standard technique in software engineering.

The Core Philosophy:

Use case diagrams embody a fundamental principle: requirements should be expressed in terms of user goals, not system internals. This perspective shift is profound. Instead of asking 'What data should the database store?' or 'What modules should we build?', use case modeling asks 'What does the user want to accomplish?' This user-centric approach ensures that technical decisions are always traceable to actual user value.

The Power of the User Perspective

Use case diagrams force you to think from the outside-in rather than the inside-out. This seemingly simple shift in perspective is why they remain valuable even in agile environments—they keep the team focused on delivering user value rather than building features for features' sake.

Key Characteristics of Use Case Diagrams:

Use case diagrams possess several defining characteristics that distinguish them from other modeling techniques:

External Perspective: They depict the system as a black box, showing only externally visible behavior
Goal-Oriented: Each use case represents a complete user goal, not a step in a process
Technology-Independent: They describe what the system does, not how it's implemented
Stakeholder-Accessible: They use natural language and simple notation that non-technical stakeholders can understand
Scope-Defining: They explicitly show what is inside versus outside the system boundary

Understanding Actors — Who Interacts with the System

An actor is any entity that interacts with the system from outside its boundaries. Actors represent the different roles that users, other systems, or external forces play in relation to your system. Understanding actors is crucial because they define the context in which your system operates and the expectations it must satisfy.

The Critical Distinction: Actors Are Roles, Not Individuals

A common misconception is that actors represent specific people. They do not. Actors represent roles. A single person might play multiple actor roles, and a single actor role might be played by many different people. This abstraction is intentional—it focuses on the relationship between the role and the system, not on individual identity.

Actor Types and Their Characteristics
Actor Type	Description	Examples	Representation
Primary Actor	The main initiator who triggers usage; the 'hero' of the use case whose goal is being served	Customer, Administrator, Employee	Stick figure on the left side of the diagram
Secondary Actor	Provides services to the system; the system depends on them to fulfill a use case	Payment Gateway, Email Service, Authentication Provider	Stick figure on the right side
Human Actor	A person who interacts with the system	End User, Support Agent, Manager	Stick figure (standard UML notation)
System Actor	An external system or hardware that interacts with your system	Database, Third-party API, IoT Device	Stick figure with «system» stereotype or box notation
Time Actor	Represents scheduled or time-triggered events	Cron Job, Scheduled Report, System Timer	Often shown as an actor with «timer» stereotype

The Art of Actor Identification:

Identifying actors is not merely listing job titles or system names. It requires deep analysis of who has stakes in the system and how those stakes manifest as interactions. Consider these guiding questions:

For Human Actors:

Who will use the system directly to accomplish goals?
Who will administer, configure, or maintain the system?
Who will receive information from the system (even if passively)?
Who makes decisions that affect how the system behaves?
Who might be affected by the system's actions?

For System Actors:

What external systems must our system integrate with?
What services does our system depend on?
What systems will consume data or services from our system?
What hardware or devices will interact with our system?

Common Actor Identification Mistakes

Don't confuse actors with system components. The database is inside your system boundary—it's not an actor. If you find yourself listing internal components as actors, you're breaking the 'external entity' rule. Also avoid overly generic actors like 'User'—if different users have different goals, they should be different actors.

Actor Generalization:

Actors can have inheritance relationships, just like classes. When one actor inherits from another, they inherit all use cases associated with the parent actor while potentially having additional ones. This is particularly useful for modeling permission hierarchies.

Example: In an e-commerce system:

Customer can browse products, add to cart, and place orders
Premium Customer inherits all Customer use cases but can also access exclusive products and priority support
Administrator is a completely separate actor with use cases for managing products and user accounts

This generalization reduces duplication and makes role hierarchies explicit in your diagrams.

Actor Identification Checklist

•Identify all stakeholder categories — Who benefits from, uses, or is affected by the system?
•Distinguish roles from individuals — One person may play multiple actor roles
•Consider primary vs secondary — Who initiates actions vs who provides services?
•Include system actors — What external systems or hardware must integrate?
•Look for time-triggered behavior — Are there scheduled or automated processes?
•Apply generalization appropriately — Do some actors share use cases but have unique permissions?
•Validate completeness — Can every system interaction be traced to at least one actor?

Defining Use Cases — What the System Does

A use case represents a complete, discrete interaction between an actor and the system that delivers value to the actor. The key word is 'complete'—a use case should represent a meaningful goal achievement, not an arbitrary step in a larger process.

The Essence of a Good Use Case:

Alistair Cockburn, a leading expert on use case modeling, introduced the concept of 'goal levels' to help identify appropriate use case granularity. A well-formed use case should represent a user goal—something an actor wants to accomplish in a single sitting that leaves them satisfied.

The 'Boss Test': Imagine an employee telling their boss, 'I just finished [action].' If the boss would say 'Good work, what's next?' it's probably a good use case. If the boss would say 'So what? Keep going,' it's probably too low-level.

The 'Complete Transaction Test': A use case should complete a transaction from the actor's perspective. 'Place Order' is complete—when done, the customer has committed to a purchase. 'Enter Shipping Address' is incomplete—it's just a step toward placing an order.

Good Use Case Examples

•Place Order — Complete transaction with value delivered
•Transfer Funds — Discrete goal with clear completion
•Register Account — Self-contained user goal
•Submit Support Ticket — Meaningful actor goal achieved
•Generate Monthly Report — Complete deliverable produced
•Schedule Appointment — Discrete, valuable outcome

Poor Use Case Examples

•Enter Password — Too granular, just a step
•Click Submit Button — UI action, not a goal
•Load User Record — Internal system action
•Validate Email Format — Technical implementation detail
•Connect to Database — System internal, not user goal
•Authenticate — Sub-function (unless primary purpose)

Use Case Naming Conventions:

Use cases should be named with verb-object phrases written in active voice. The verb should express what the actor accomplishes, and the object should be the thing they're acting upon. This naming convention makes use cases immediately understandable:

Verb + Object: Place Order, Transfer Funds, Update Profile
Active Voice: 'Customer places order' not 'Order is placed by customer'
Actor's Perspective: Name should reflect what the actor does, not what the system does

The Goal-Level Hierarchy:

Use cases operate at different levels of abstraction. Understanding these levels helps you model at the right granularity:

Level	Description	Example	Typical Use
Summary/Cloud	Very high-level, multiple user goals	'Manage Customer Relationship'	Business capability overview
User Goal/Sea Level	Standard use case, one sitting	'Place Order'	Primary use case level
Subfunction/Fish	Below water, supporting function	'Authenticate User'	Included/shared functionality

The Sweet Spot

Most use cases in your diagrams should be at the 'sea level'—user goal level. Summary-level use cases are useful for high-level overviews, and subfunction-level use cases typically exist to be «included» by multiple user-goal level use cases.

Use Case Documentation Beyond the Diagram:

While the diagram itself shows use case names and their relationships to actors, each use case should be accompanied by narrative documentation called a use case specification or use case description. This specification captures:

Name: The verb-object title
Primary Actor: Who initiates this use case
Preconditions: What must be true before the use case begins
Postconditions: What is guaranteed to be true after successful completion
Main Success Scenario: The 'happy path' steps
Alternative Flows: What happens when things deviate from the happy path
Exception Flows: How failures and errors are handled

The diagram provides the overview; the specifications provide the details.

The Visual Notation — Reading and Creating Use Case Diagrams

Use case diagrams employ a minimal visual vocabulary intentionally. The simplicity is a feature—it keeps diagrams accessible to non-technical stakeholders while still conveying essential information about system scope and actor interactions.

The Core Visual Elements:

Use Case Diagram Visual Elements
Element	Symbol	Purpose	Placement Guidelines
Actor	Stick figure	Represents external entity that interacts with the system	Left side for primary actors, right side for secondary actors
Use Case	Oval/ellipse	Represents a complete user goal or system function	Inside the system boundary, labeled with verb-object phrase
System Boundary	Rectangle	Defines the scope of the system being modeled	Encloses all use cases; actors remain outside
Association	Solid line	Shows that an actor participates in a use case	Connects actor to use case; no arrowhead needed for basic association
System Name	Label	Identifies the system or subsystem being modeled	Top of the boundary rectangle

Association Lines:

The solid line connecting an actor to a use case represents participation. It's called an association and indicates that the actor participates in that use case. Some modeling conventions include:

No arrowhead: Simple participation (most common)
Arrowhead toward use case: Actor initiates the use case (sometimes used but not strictly required by UML)
Arrowhead toward actor: The use case provides information to the actor (less common)

In practice, keeping associations as simple solid lines without arrowheads is most common because the directionality is usually clear from context.

Reading a Use Case Diagram:

When reading a use case diagram, follow this pattern:

Identify the system: What is inside the boundary?
Identify all actors: Who or what interacts from outside?
For each actor: What use cases are they connected to? These are their available interactions.
For each use case: Which actors participate? Is there more than one?
Consider the relationships: Are there any include, extend, or generalization relationships? (covered in detail in later pages)

This systematic reading reveals the functional scope and the actor-to-functionality mapping.

Converting Mermaid diagram...

Diagram Layout Best Practices

Place primary actors (who initiate interactions) on the left side of your diagram and secondary actors (who provide services) on the right. This left-to-right flow mirrors how we read and creates intuitive visual hierarchy. Keep the diagram uncluttered—if it's getting crowded, consider splitting into subsystem diagrams.

Real-World Example — E-Commerce Platform Analysis

Let's walk through a comprehensive example that demonstrates actor and use case identification in practice. Consider designing a use case model for an e-commerce platform.

Step 1: Stakeholder Analysis

Before drawing anything, we identify everyone who has a stake in the system:

Customers: Want to browse, purchase, and receive products
Guest Visitors: Want to browse without creating accounts
Sellers/Merchants: Want to list products and manage orders
Administrators: Want to manage the platform, users, and policies
Support Agents: Want to resolve customer issues
External Systems: Payment processors, shipping providers, inventory systems

Step 2: Actor Identification

From our stakeholder analysis, we derive actors:

Actor	Role Type	Primary Goals
Guest	Human, Primary	Browse catalog, search products
Registered Customer	Human, Primary	All guest functions + purchase, track orders, manage profile
Seller	Human, Primary	Manage listings, fulfill orders, view analytics
Administrator	Human, Primary	Manage users, configure policies, view reports
Support Agent	Human, Primary	Resolve tickets, process refunds, assist customers
Payment Gateway	System, Secondary	Process payments, handle refunds
Shipping Provider	System, Secondary	Calculate rates, track shipments
Inventory System	System, Secondary	Track stock levels, receive updates

Step 3: Use Case Identification

For each actor, we identify their goals and translate them into use cases:

Customer-Centric Use Cases:

Browse Product Catalog
Search Products
View Product Details
Add Item to Cart
Manage Shopping Cart
Place Order
Track Order Status
Submit Product Review
Manage Account Settings
View Order History

Seller-Centric Use Cases:

Create Product Listing
Update Product Information
Manage Inventory
View Sales Analytics
Process Order Fulfillment
Respond to Customer Questions
Manage Seller Profile

Administrator-Centric Use Cases:

Manage User Accounts
Configure Platform Policies
Review Flagged Content
Generate Platform Reports
Manage Product Categories

Granularity Check

Notice how each use case passes the 'boss test.' A customer can say 'I just placed an order' and feel satisfied. A seller can say 'I created a product listing' and have accomplished a complete goal. Some use cases like 'Process Payment' might be candidates for «include» relationships—they support other use cases rather than being directly valuable to actors.

Step 4: Actor-Use Case Association

Now we connect actors to their use cases. Note that:

Some use cases are shared: Multiple actors might participate in 'View Product Details'
Generalization applies: 'Registered Customer' inherits from 'Guest' and adds purchase-related use cases
Secondary actors participate in use cases initiated by primary actors: 'Payment Gateway' participates in 'Place Order'

Key Insights from This Analysis:

Actor generalization reduces duplication: Guest and Registered Customer share browsing use cases
System actors appear when use cases require external services: Payment, shipping, and inventory
Each use case represents real user value: No technical implementation details appear
The model is technology-independent: Whether the platform is web, mobile, or API-based doesn't change the use cases

This systematic approach ensures comprehensive coverage while maintaining appropriate abstraction.

Common Mistakes and Best Practices

Even experienced practitioners make mistakes when creating use case diagrams. Understanding these pitfalls helps you avoid them and create more effective models.

Common Mistakes to Avoid

•Functional Decomposition: Treating use cases like a hierarchical breakdown of system functions rather than user goals. If your 'use cases' read like a task list (Enter Data → Validate → Save → Confirm), you're doing functional decomposition.
•CRUD Use Cases: Creating separate use cases for Create, Read, Update, Delete operations on every entity. 'Manage Products' is usually better than four separate CRUD use cases—unless the create and update processes are fundamentally different.
•Including Internal Operations: Use cases should be external interactions. 'Validate Input' or 'Log Transaction' are system internals, not use cases that actors interact with.
•Overly Generic Actors: An actor named 'User' tells you nothing. Distinguish between Customer, Administrator, Guest, and other roles with different goals.
•Missing Secondary Actors: Forgetting that external systems (payment gateways, APIs, schedulers) are actors too. Your system doesn't exist in isolation.
•Confusing UI with Use Cases: 'Click Submit Button' or 'Navigate to Dashboard' describe interface actions, not user goals. Use cases are UI-independent.

Best Practices for Effective Use Cases

•Apply the Boss Test: Would the actor's supervisor be satisfied if they said 'I just finished [use case]'? If not, the use case is too granular.
•Use Verb-Object Naming: 'Place Order' not 'Order Placement' or 'Ordering'. Active voice with clear objects.
•Maintain Consistent Granularity: All use cases in a diagram should be at roughly the same level of abstraction. Don't mix summary-level with subfunction-level.
•Keep Diagrams Readable: If your diagram needs scrolling, consider breaking into subsystem views. Seven to fifteen use cases per diagram is a good guideline.
•Document Each Use Case: The diagram is an overview. Each use case needs narrative documentation describing preconditions, postconditions, main flow, and alternatives.
•Validate with Stakeholders: Use case diagrams are meant to be understood by non-technical stakeholders. If they can't read your diagram, it has failed its purpose.

The Danger of Over-Modeling

Use case diagrams can become an end in themselves. Remember: the goal is shared understanding and clear requirements, not a perfect UML diagram. If spending more time on the diagram than discussing requirements with stakeholders, the model is failing its purpose.

When to Use Use Case Diagrams

Use case diagrams are not always the right tool. Understanding their strengths and limitations helps you apply them effectively.

Use Case Diagrams Excel When:

Capturing initial requirements: They help translate business needs into functional scope
Communicating with non-technical stakeholders: The simple notation is immediately understandable
Defining system boundaries: They explicitly show what's in scope and what isn't
Planning iterations: Each use case can become a feature or story for development
Contract negotiation: They establish what the system will and won't do
System integration planning: They identify external system actors that require interfaces

Use Case Diagrams Are Less Suitable When:

Modeling business processes: Activity diagrams or BPMN are better for workflows
Showing system architecture: Component or deployment diagrams serve this purpose
Detailing object interactions: Sequence diagrams show how objects collaborate
Modeling data structures: Class diagrams or ER diagrams are appropriate
Specifying user interfaces: Wireframes and prototypes are more effective

Use Case Diagrams in Modern Development Contexts
Context	Value of Use Cases	Recommended Approach
Agile/Scrum Projects	Medium — Can seed product backlog and define epics	Use lightweight use case lists rather than formal diagrams; elaborate in user stories
Waterfall Projects	High — Formal requirements documentation	Full use case specification with detailed documentation
API Design	High — Defines capabilities for API consumers	Map use cases to API endpoints; actors become API consumers
Microservices	High — Helps define service boundaries	Use case diagrams per service; actors may be other services
System Integration	High — Identifies integration points	Focus on system actors and data exchange use cases
Startup/MVP	Medium — Helps scope minimum viable features	Keep minimal; focus on primary actor, primary use cases only

The Agile Adaptation:

In agile environments, use case diagrams are often adapted rather than abandoned. A common approach:

Use cases become epics: High-level user goals that span multiple sprints
Use case scenarios become user stories: The main success scenario and alternatives translate to stories
Actors inform personas: Actor definitions evolve into detailed user personas
The diagram becomes living documentation: Updated as understanding evolves

The formality of traditional use case modeling is reduced, but the core concept—understanding user goals before building—remains valuable.

Summary: Actors and Use Cases

We've established the foundation of use case modeling. Let's consolidate the essential concepts:

Key Takeaways

•Use case diagrams capture functional requirements — They show what a system does from an external perspective without specifying how.
•Actors represent roles, not individuals — Human actors, system actors, and even time can be actors. Primary actors initiate; secondary actors provide services.
•Use cases represent complete user goals — Apply the 'boss test' and 'complete transaction test' to ensure appropriate granularity.
•Naming conventions matter — Verb-object phrases in active voice make use cases immediately understandable.
•Goal levels guide granularity — Most use cases should be at 'user goal' (sea level); summary and subfunction levels serve specific purposes.
•Diagrams are just the beginning — Each use case needs detailed specification documenting flows, preconditions, and postconditions.
•Common mistakes are avoidable — Functional decomposition, CRUD overload, and missing system actors are prevalent pitfalls.

What's Next:

Now that we understand actors and use cases—the fundamental building blocks—we need to understand how to define what's inside versus outside our system. The next page explores system boundaries: how to scope your system, what belongs inside the boundary, and how boundary decisions affect your entire design.

Page Complete

You now understand actors and use cases—the two primary elements of use case diagrams. You can identify different types of actors, define meaningful use cases at appropriate granularity, and understand the notation used to represent them. Next, we'll explore how system boundaries define the scope of your modeling efforts.