Use Case Diagrams: Capturing Functional Requirements
1. Overview
Use Case Diagrams are a visual language for capturing and communicating functional requirements from the perspective of system users. They sit at the intersection of business analysis and software design, serving as a bridge between stakeholder needs and technical implementation.
Purpose and Context
Use cases answer a fundamental question: "What can the system do, and who can do it?" They are essential during the requirements analysis phase of the Software Development Lifecycle (SDLC) because they:
- Capture functional requirements — What behavior the system must provide
- Focus on user goals — Not implementation details, but what users want to accomplish
- Enable traceability — Link requirements to design and test cases
- Facilitate communication — Stakeholders, developers, and testers all speak the same language
- Scope the project — Define system boundaries and what is in/out of scope
Key Audiences
- Business Stakeholders — Understand what the system will do without technical jargon
- Product Managers — Prioritize features and manage scope
- Developers — Design system architecture and implement features
- Testers — Write test cases based on use case flows
- Project Managers — Estimate effort and schedule work
2. Core Elements of Use Case Diagrams
Before diving into each element individually, here is a layered view of how a use case diagram is structured. The three layers map to who uses the system (actors), what the system does (use cases inside the boundary), and what artifacts the model produces downstream (descriptions, stories, tests). This mirrors the classic separation of requirements, specification, and implementation.
Anatomy at a Glance (Layered View)
┌──────────────────────────────────────────────────────────┐
│ EXTERNAL ACTORS LAYER │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────┐ │
│ │ Primary │ │Secondary │ │ System │ │ External │ │
│ │ Actor │ │ Actor │ │ Actor │ │ Service │ │
│ │(Customer)│ │(Manager) │ │(Payment) │ │ (API) │ │
│ └──────────┘ └──────────┘ └──────────┘ └─────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Roles, NOT Individuals │ │
│ │ Initiate Goals & Provide Services │ │
│ │ (Drawn outside the System Boundary) │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
│
▼ (Association)
┌──────────────────────────────────────────────────────────┐
│ SYSTEM BOUNDARY (SCOPE) │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────────┐ │
│ │ Use Case │ │ Use Case │ │ Use Case │ │
│ │ (Goal 1) │ │ (Goal 2) │ │ (Goal 3) │ │
│ │ Withdraw │ │ Deposit │ │ Check Balance │ │
│ └─────┬──────┘ └─────┬──────┘ └────────┬───────┘ │
│ │ │ │ │
│ │ <<include>> │ <<include>> │ <<extend>> │
│ ▼ ▼ ▼ │
│ ┌────────────────────────────┐ ┌──────────────────┐ │
│ │ Shared Use Case │ │ Optional Use │ │
│ │ (Authenticate User) │ │ Case (Receipt) │ │
│ │ ─ mandatory, reused ─ │ │ ─ conditional ─ │ │
│ └────────────────────────────┘ └──────────────────┘ │
│ │
│ (Atomic, Verb-Phrase Goals; What — not How) │
└──────────────────────────────────────────────────────────┘
│
▼ (Traceability)
┌──────────────────────────────────────────────────────────┐
│ IMPLEMENTATION ARTIFACTS LAYER │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Derived Deliverables (Per Use Case) │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ Use │ │ User │ │ Test Cases │ │ │
│ │ │ Case │ │ Stories │ │ (Happy + Alt │ │ │
│ │ │ Descr. │ │ (Agile) │ │ Flows) │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ │ │ │
│ │ (Requirements → Stories → Tests → Code) │ │
│ └────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
How to Read This Diagram
- Top layer — Actors: Anything external to the system. They initiate use cases (primary) or provide services to them (secondary, system, external). They are roles, not specific people.
- Middle layer — System Boundary: The rectangle defines what is in scope. Inside live the use cases (ovals). Use cases connect to each other through three relationships:
<<include>>— mandatory shared behavior (function call)<<extend>>— optional conditional behavior (plugin)- generalization — inheritance between use cases or actors
- Bottom layer — Implementation Artifacts: Each use case in the diagram produces a written description, decomposes into multiple user stories during sprint planning, and is verified by a set of test cases tracing back to the original goal.
- Vertical arrows show the flow of meaning: actors associate with use cases, and use cases trace downstream into stories, tests, and code.
Actors
An actor is any entity (person, system, or external service) that interacts with the system. Actors are drawn as stick figures or labeled rectangles. They represent roles, not individuals.
- Primary Actor — The user who initiates a use case to achieve a goal (e.g., a Customer withdrawing cash)
- Secondary Actor — Provides a service or data to the system (e.g., a Bank's internal authorization system)
- System Actor — External systems or services the application integrates with (e.g., Payment Gateway)
Use Cases
A use case is a specific interaction scenario between an actor and the system. Drawn as an oval with a descriptive name (usually a verb phrase like "Withdraw Cash"). Each use case represents a single, cohesive business goal.
- Name use cases as verb phrases — "Login User", "Process Order", "Generate Report"
- Each use case should be atomic — One logical piece of work
- Use cases are independent — They can be read in any order
System Boundary
A rectangle that encloses all use cases, representing the scope of the system being designed. Everything inside is the responsibility of the system; actors are outside.
Relationships in Use Case Diagrams
Association (Simple Connection)
A solid line connecting an actor to a use case, indicating that the actor participates in (initiates or uses) that use case. Direction can be shown with arrowheads, though often it is implicit.
Include (Dependency)
A dashed arrow labeled <<include>> from one use case to another, meaning the source use case always invokes the target use case as a mandatory part of its behavior. Think of it as a function call.
Extend (Conditional Extension)
A dashed arrow labeled <<extend>> from one use case to another, meaning the source use case may optionally invoke the target use case under specific conditions. The base use case is complete without the extension.
Generalization (Inheritance)
A solid line with a hollow triangle arrowhead, indicating that a specialized use case or actor inherits from a more general one. Example: "Registered User" is a generalization of both "Customer" and "Administrator".
3. Include vs Extend: A Critical Distinction
The most commonly misunderstood relationship in use case modeling is the difference between <<include>> and <<extend>>. Let's clarify with analogies and examples.
Include: Mandatory Shared Behavior
Use include when a use case always requires the behavior of another use case.
- The included use case is part of the base use case's normal flow
- It is mandatory — the base use case cannot complete without it
- Think: A function that must be called every time
Example: "Withdraw Cash" always includes "Authenticate User" (check PIN). You cannot withdraw without authenticating.
Extend: Optional Conditional Behavior
Use extend when a use case may optionally invoke another use case under specific conditions.
- The extending use case adds alternative or additional behavior under certain conditions
- It is optional — the base use case is complete without it
- Think: An optional feature triggered by a condition
Example: "Withdraw Cash" may extend to "Print Receipt", but only if the customer requests it. Withdrawal is complete without a receipt.
Quick Comparison Table
┌─────────────────┬────────────────────┬──────────────────────┐ │ Aspect │ Include │ Extend │ ├─────────────────┼────────────────────┼──────────────────────┤ │ Mandatory? │ YES │ NO (Conditional) │ │ When Used │ Shared behavior │ Optional extension │ │ Direction │ Base → Included │ Extended → Base │ │ Analogy │ Function call │ Plugin / Hook │ │ Example │ Auth in Withdraw │ Receipt in Withdraw │ └─────────────────┴────────────────────┴──────────────────────┘
Common Confusion Points
- Direction matters: Include points FROM the base TO the included. Extend points FROM the extending TO the base. This is counterintuitive!
- Semantics: A use case that includes another is saying "I always do this." A use case that extends another is saying "I sometimes add this."
- Don't overuse extend: If something is truly optional, consider whether it belongs in the use case diagram at all, or document it in the written description instead.
4. Example: Banking System Use Case Diagram
Let's design use cases for an automated teller machine (ATM) system.
Use Cases Identified:
- Withdraw Cash
- Deposit Funds
- Check Balance
- Transfer Funds
- Authenticate User (included by others)
- Print Receipt (extended by others)
ASCII Diagram
┌──────────────────────────────────────────────────────────────────────────────┐
│ ATM System │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ Withdraw Cash │ │ Deposit Funds │ │
│ └──────────┬─────────┘ └──────────┬─────────┘ │
│ │ <<include>> │ <<include>> │
│ ▼ ▼ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ Check Balance │ │ Transfer Funds │ │
│ └──────────┬─────────┘ └──────────┬─────────┘ │
│ │ <<include>> │ <<include>> │
│ └────────────────────┬──────────────────┘ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ Authenticate User │ │
│ └────────────────────────┘ │
│ │
│ ┌────────────────────┐ <<extend>> ┌────────────────────┐ │
│ │ Withdraw Cash │─────────────────▶│ Print Receipt │ │
│ └────────────────────┘ └────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘
▲ ▲
│ │
┌──────────┐ ┌──────────────┐
│ Customer │ │ Bank System │
│ (Actor) │ │ (Actor) │
└──────────┘ └──────────────┘
How to Read This Diagram:
- Customer actor: Interacts with Withdraw Cash, Deposit Funds, Check Balance, and Transfer Funds
- Bank System actor: Provides data/services to authentication and fund transfer
- Include relationships: All four transaction use cases must first Authenticate User (mandatory)
- Extend relationship: Withdraw Cash may optionally result in Print Receipt
5. Example: Online Shopping System
A multi-actor example showing customer, administrator, and external payment service interactions.
Use Cases:
- Customer Use Cases: Browse Products, Add to Cart, View Cart, Proceed to Checkout, Place Order
- Admin Use Cases: Manage Inventory, Generate Reports, Process Returns
- External: Process Payment (via Payment Gateway)
ASCII Diagram
┌──────────────────────────────────────────────────────────────────────────────┐
│ Online Shopping System │
│ │
│ ┌──────────────────────┐ ┌──────────────────────┐ │
│ │ Browse Products │ │ Add to Cart │ │
│ └──────────┬───────────┘ └──────────┬───────────┘ │
│ │ │ │
│ └─────────────────┬───────────────────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ View Cart │ │
│ └──────────┬───────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Proceed to Checkout │ │
│ └──────────┬───────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Place Order │ │
│ └──────────┬───────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────┐ (via Payment Gateway) │
│ │ Process Payment │ ◄──────────────────────┐ │
│ └──────────────────────┘ │ │
│ │ │
│ ┌──────────────────────┐ ┌──────────────────────┴──┐ │
│ │ Manage Inventory │ │ Generate Reports │ │
│ └──────────┬───────────┘ └──────────┬──────────────┘ │
│ │ │ │
│ └─────────────────┬───────────────────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Query Database │ │
│ └──────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘
▲ ▲ ▲
│ │ │
┌──────────┐ ┌────────────┐ ┌────────────────┐
│ Customer │ │ Admin User │ │ Payment System │
│ (Actor) │ │ (Actor) │ │ (Actor) │
└──────────┘ └────────────┘ └────────────────┘
6. Example: Hospital Management System
A complex system with multiple actor types and specialized use cases.
Actors:
- Patient: Primary actor for appointment and medical record access
- Doctor: Manages appointments and medical records
- Nurse: Updates patient vitals, assists with records
- Administrator: Manages billing and system settings
ASCII Diagram
┌──────────────────────────────────────────────────────────────────────────────┐
│ Hospital Management System │
│ │
│ ┌──────────────────────────┐ │
│ │ Schedule Appointment │ │
│ └─────────────┬────────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ Check Patient History │ │
│ └──────────────────────────┘ │
│ │
│ ┌────────────────────────┐ ┌────────────────────────┐ │
│ │ Record Medical Info │ │ Update Patient Vitals │ │
│ └────────────┬───────────┘ └────────────┬───────────┘ │
│ │ │ │
│ └──────────────────┬────────────────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ Retrieve Medical Records │ │
│ └─────────────┬────────────┘ │
│ │ <<include>> │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ Process Billing │ │
│ └─────────────┬────────────┘ │
│ │ <<extend>> │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ Generate Invoice │ │
│ └──────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘
▲ ▲ ▲ ▲
│ │ │ │
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌─────────────┐
│ Patient │ │ Doctor │ │ Nurse │ │ Admin │
│ (Actor) │ │ (Actor) │ │ (Actor) │ │ (Actor) │
└─────────┘ └──────────┘ └──────────┘ └─────────────┘
7. Writing Use Case Descriptions
Diagrams are visual overviews. Each use case needs a detailed written description. Here is the standard template:
Use Case Description Template
USE CASE NAME: [Verb phrase describing the user goal] ACTOR: [Primary actor initiating this use case] PRECONDITION: [What must be true before the use case starts] MAIN FLOW: [Step-by-step normal behavior] ALTERNATIVE FLOWS: [Exception paths, edge cases] POSTCONDITION: [What is true after successful completion] BUSINESS RULES: [Constraints, validations, policies]
Complete Example: Withdraw Cash
USE CASE NAME: Withdraw Cash
ACTOR: Customer
PRECONDITION: - Customer has a valid ATM card
- ATM is operational
- Account has sufficient funds
MAIN FLOW:
1. Customer inserts ATM card
2. System reads card and prompts for PIN
3. Customer enters PIN
4. System validates PIN (includes Authenticate User)
5. System displays menu options
6. Customer selects "Withdraw Cash"
7. Customer enters desired amount
8. System validates:
- Amount is multiple of $20
- Account balance ≥ withdrawal amount
- Daily withdrawal limit not exceeded
9. System dispenses cash
10. System updates account balance
11. System asks "Print receipt?"
12. (If yes) System prints receipt (extends Print Receipt)
13. System ejects card
14. Customer takes card and cash
15. Use case ends
ALTERNATIVE FLOWS:
A1. Invalid PIN (Step 3):
- System prompts for retry (max 3 attempts)
- If 3 failures: ATM card is retained, use case ends
A2. Insufficient Funds (Step 8):
- System displays error message
- Offers alternative amounts
- Customer may re-enter or cancel
A3. Daily Limit Exceeded (Step 8):
- System displays maximum remaining withdrawal amount
- Customer may adjust amount or cancel
A4. Card Error (Step 1):
- System displays "Card Error" message
- System ejects card
- Use case ends
POSTCONDITION: - Account balance is reduced by withdrawal amount
- Transaction is logged
- Card is returned to customer
- ATM inventory is updated
BUSINESS RULES:
- Maximum daily withdrawal: $1000
- Cash must be in $20 increments
- Transaction fee: $2.50 (if applicable to account type)
- Failed PIN attempts: Card retained after 3 failures
- Withdrawal timeout: 2 minutes of inactivity
8. Mermaid.js Code Examples
Modern teams often use code-based diagram tools. Mermaid.js is a popular choice for generating UML diagrams from text.
ATM System in Mermaid Syntax
graph TD
Customer -->|initiates| WithdrawCash
Customer -->|initiates| DepositFunds
Customer -->|initiates| CheckBalance
Customer -->|initiates| TransferFunds
WithdrawCash -->|<>| Authenticate
DepositFunds -->|<>| Authenticate
CheckBalance -->|<>| Authenticate
TransferFunds -->|<>| Authenticate
WithdrawCash -->|<>| PrintReceipt
BankSystem -->|provides| Authenticate
BankSystem -->|updates| TransferFunds
Online Shopping in Mermaid
graph TD
Customer -->|initiates| Browse
Customer -->|initiates| AddCart
Customer -->|initiates| Checkout
Browse -->|<>| ViewCart
AddCart -->|<>| ViewCart
ViewCart -->|<>| Checkout
Checkout -->|<>| ProcessPayment
ProcessPayment -->|<>| SendConfirmation
PaymentGateway -->|processes| ProcessPayment
Admin -->|manages| Inventory
Admin -->|queries| Inventory
9. Best Practices for Use Case Modeling
Keep Diagrams Simple: The 7±2 Rule
A single use case diagram should contain between 5 and 9 use cases. If you have more, split into multiple diagrams by subsystem or business area. Complexity kills clarity.
Naming Conventions
- Use cases: Verb + Object (e.g., "Login User", "Process Order", "Generate Report")
- Actors: Role + type (e.g., "Admin User", "External Payment System", "Customer")
- Avoid: UI-centric names like "Click Login Button" or implementation details
Actors Are Roles, Not Individuals
An actor represents a role that any user might play. "Customer" is an actor; "John Smith" is not. This enables generalization and makes diagrams reusable.
Don't Model UI Details
Use cases describe business goals, not UI flows. "Enter Username and Password" is too low-level. Instead, write "Authenticate User".
Include vs Extend Rules of Thumb
- Use include if: The behavior is mandatory and used by multiple use cases (DRY principle)
- Use extend if: The behavior is optional or triggered by a specific condition
- When in doubt: Use include for shared behavior, extend sparingly
- Over-use warning: Too many extends makes the diagram hard to understand. Document these in the written use case instead.
System Boundary is Critical
The system boundary rectangle clearly defines what is IN scope and what is OUT. Actors live outside; use cases live inside. This boundary prevents scope creep.
Validate Against Stakeholder Goals
Every use case should support at least one business objective. If a use case doesn't map to a goal, remove it or combine it with another.
10. From Use Cases to User Stories
In Agile development, teams often transition from use cases (analysis artifact) to user stories (implementation artifact). They are complementary, not competing approaches.
Use Cases vs User Stories
┌────────────────┬────────────────────┬────────────────────┐ │ Aspect │ Use Case │ User Story │ ├────────────────┼────────────────────┼────────────────────┤ │ Purpose │ Capture all flows │ Capture one goal │ │ Detail Level │ Comprehensive │ Brief (3-5 lines) │ │ Scope │ Entire interaction │ Single feature │ │ Audience │ Stakeholders │ Dev Team │ │ Includes │ Happy + alt flows │ Happy path only │ │ Lifecycle │ Analysis phase │ Sprint planning │ │ Format │ Formal template │ "As a..." format │ └────────────────┴────────────────────┴────────────────────┘
Mapping Use Cases to User Stories
One use case typically maps to multiple user stories. Each user story represents an implementable slice of the use case.
Example: "Withdraw Cash" use case → User Stories
- User Story 1: "As a customer, I want to insert my card and enter my PIN so I can access my account"
- User Story 2: "As a customer, I want to select a withdrawal amount and receive cash so I can access my funds"
- User Story 3: "As a customer, I want to receive a receipt so I can track my transaction"
- User Story 4: "As a customer, I want the system to reject invalid PINs and block my card after 3 attempts so my account is secure"
Traceability Matrix
Organizations maintain a traceability matrix linking use cases → user stories → test cases → code. This ensures every requirement is implemented and tested.
┌─────────────────┬──────────────────────────┬──────────────────────────┬──────────────┐ │ Use Case │ User Story │ Test Case │ Code Module │ ├─────────────────┼──────────────────────────┼──────────────────────────┼──────────────┤ │ Withdraw Cash │ Insert card + enter PIN │ TC-01: Valid PIN │ auth.py │ │ │ │ TC-02: Invalid PIN x3 │ │ │ │ │ TC-03: Timeout │ │ │ ├──────────────────────────┼──────────────────────────┼──────────────┤ │ │ Enter amount + dispense │ TC-04: Valid amount │ withdrawal.py│ │ │ │ TC-05: Insufficient $ │ │ │ │ │ TC-06: Daily limit │ │ │ ├──────────────────────────┼──────────────────────────┼──────────────┤ │ │ Print receipt (optional) │ TC-07: Receipt printed │ receipts.py │ │ │ │ TC-08: No receipt │ │ └─────────────────┴──────────────────────────┴──────────────────────────┴──────────────┘
Agile Workflow: Use Cases to Sprint
- Discovery Phase: Create use case diagrams and descriptions with stakeholders
- Decomposition: Break each use case into 2-5 user stories
- Sprint Planning: Prioritize and estimate user stories
- Development: Implement stories, reference use case flows for acceptance criteria
- Testing: Test scenarios defined in use case alternative flows
- Review: Validate against original use case requirements
Summary: Key Takeaways
- Use case diagrams bridge business and technical worlds — They capture functional requirements in language all stakeholders understand.
- Core elements: Actors, use cases, system boundary, and four types of relationships (association, include, extend, generalization).
- Include = mandatory; extend = optional. This distinction prevents confusion and keeps diagrams maintainable.
- Always pair diagrams with written descriptions. Diagrams show the big picture; descriptions provide the detail.
- Keep diagrams simple (7±2 use cases per diagram) and don't model UI details.
- Use cases are the foundation for user stories, test cases, and traceability. They ensure requirements are fully implemented and validated.
- Name use cases as verb phrases, actors as roles. This consistency aids communication and tool integration.
Further Reading
- Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley.
- Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall.
- Cockburn, A. (2001). Writing Effective Use Cases. Addison-Wesley.