Use Case Diagrams: Capturing Functional Requirements

A use case diagram answers "who uses this system, and what do they want to get done with it?" Stick figures (actors) stand outside a box (the system), and ovals inside the box are the goals the system supports, like "Withdraw Cash" or "Check Out". It deliberately leaves out how anything works, which makes it a good first conversation with stakeholders about scope.

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:

Key Audiences

Notation Legend

Use Case Diagram Notation actor (a role) Withdraw Cash use case (verb + noun) ATM System use cases go inside system boundary association (actor - use case) «include» «include»: always performed «extend» «extend»: optional, conditional generalization (specializes) «extend» arrows point to the base use case; «include» arrows point to the included one

An actor is a role (a person or another system), not a specific individual. Each oval is a use case named as a verb phrase. The rectangle is the system boundary: everything inside is in scope. Plain lines connect actors to the use cases they take part in; dashed «include» and «extend» arrows relate use cases; a hollow triangle shows generalization between actors or use cases.

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 Actor (Customer) Secondary Actor (Manager) System Actor (Payment) External Service (API) Roles, NOT Individuals Initiate Goals & Provide Services (Drawn outside the System Boundary) (Association) SYSTEM BOUNDARY (SCOPE) Use Case (Goal 1) Withdraw Use Case (Goal 2) Deposit Use Case (Goal 3) Check Balance Shared Use Case (Authenticate User) mandatory, reused Optional Use Case (Receipt) conditional <<include>> <<include>> <<extend>> (Atomic, Verb-Phrase Goals; What — not How) (Traceability) IMPLEMENTATION ARTIFACTS LAYER Derived Deliverables (Per Use Case) Use Case Descr. (Requirements) User Stories (Agile) Test Cases (Happy + Alt Flows) Code

How to Read This Diagram

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.

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.

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.

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.

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

4. Example: Banking System Use Case Diagram

Let's design use cases for an automated teller machine (ATM) system.

Use Cases Identified:

ASCII Diagram

Customer (Actor) Bank System (Actor) ATM System Withdraw Cash Check Balance Deposit Funds Transfer Funds Authenticate User <<include>> <<include>> Withdraw Cash Print Receipt <<extend>> (Print Receipt extends Withdraw Cash)

How to Read This Diagram:

5. Example: Online Shopping System

A multi-actor example showing customer, administrator, and external payment service interactions.

Use Cases:

ASCII Diagram

Customer (Actor) Admin User (Actor) Payment System (Actor) Online Shopping System Browse Products Add to Cart View Cart Proceed to Checkout Place Order Process Payment (via Payment Gateway) <<include>> <<include>> <<include>> <<include>> Manage Inventory Generate Reports Query Database <<include>>

6. Example: Hospital Management System

A complex system with multiple actor types and specialized use cases.

Actors:

ASCII Diagram

Patient (Actor) Doctor (Actor) Nurse (Actor) Admin (Actor) Hospital Management System Schedule Appointment Check Patient History <<include>> Record Medical Info Update Patient Vitals Retrieve Medical Records <<include>> Process Billing <<include>> Generate Invoice <<extend>>

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 -->|<<include>>| Authenticate
    DepositFunds -->|<<include>>| Authenticate
    CheckBalance -->|<<include>>| Authenticate
    TransferFunds -->|<<include>>| Authenticate

    WithdrawCash -->|<<extend>>| PrintReceipt

    BankSystem -->|provides| Authenticate
    BankSystem -->|updates| TransferFunds

Online Shopping in Mermaid


graph TD
    Customer -->|initiates| Browse
    Customer -->|initiates| AddCart
    Customer -->|initiates| Checkout

    Browse -->|<<include>>| ViewCart
    AddCart -->|<<include>>| ViewCart
    ViewCart -->|<<include>>| Checkout
    Checkout -->|<<include>>| ProcessPayment

    ProcessPayment -->|<<extend>>| 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

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

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

Traceability Matrix

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

Organizations maintain a traceability matrix linking use cases → user stories → test cases → code. This ensures every requirement is implemented and tested.

Agile Workflow: Use Cases to Sprint

  1. Discovery Phase: Create use case diagrams and descriptions with stakeholders
  2. Decomposition: Break each use case into 2-5 user stories
  3. Sprint Planning: Prioritize and estimate user stories
  4. Development: Implement stories, reference use case flows for acceptance criteria
  5. Testing: Test scenarios defined in use case alternative flows
  6. Review: Validate against original use case requirements

Summary: Key Takeaways

Further Reading

Pros and Cons

Pros

Cons

When to Use / When Not To

When to use

When not to use

Main Example as Diagrams-as-Code

Rendered by PlantUML (PlantUML server, IDE plugins or plantuml.jar), which supports actors, boundaries and include/extend natively; Mermaid has no real use case diagram type. The ATM example:

@startuml
left to right direction
actor Customer
actor "Bank System" as Bank
actor Technician
rectangle "ATM System" {
  usecase "Check Balance" as UC1
  usecase "Withdraw Cash" as UC2
  usecase "Deposit Funds" as UC3
  usecase "Transfer Funds" as UC4
  usecase "Authenticate" as Auth
  usecase "Print Receipt" as Receipt
  usecase "Perform Maintenance" as Maint
}
Customer --> UC1
Customer --> UC2
Customer --> UC3
Customer --> UC4
Technician --> Maint
UC1 ..> Auth : <<include>>
UC2 ..> Auth : <<include>>
UC3 ..> Auth : <<include>>
UC4 ..> Auth : <<include>>
Receipt .> UC2 : <<extend>>
UC2 --> Bank
UC4 --> Bank
@enduml