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

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   │ │
│    └──────────────────┘       └──────────────────┘ │
│            ▲                           ▲             │
│            │ <>               │ <> │
│            │                           │             │
│    ┌─────────────────────┐    ┌──────────────────┐ │
│    │  Check Balance      │    │  Transfer Funds  │ │
│    └─────────────────────┘    └──────────────────┘ │
│            ▲                           ▲             │
│            │ <>               │ <> │
│            │                           │             │
│            └───────────┬───────────────┘             │
│                        │                             │
│                  ┌──────────────┐                   │
│                  │ Authenticate │                   │
│                  │    User      │                   │
│                  └──────────────┘                   │
│                                                      │
│    ┌──────────────────┐         <>   ┌────┐│
│    │  Withdraw Cash   │─────────────────────▶│Prnt││
│    └──────────────────┘                      │Rcpt││
│                                              └────┘│
└────────────────────────────────────────────────────┘
          ▲                       ▲
          │                       │
      ┌─────────┐             ┌────────────┐
      │ 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     │          │
│  └──────────────────┘      └──────────────────┘          │
│           ▲                         ▲                      │
│           │                         │                      │
│           └─────────┬───────────────┘                     │
│                     │ <>                         │
│                     ▼                                      │
│           ┌──────────────────┐                            │
│           │   View Cart      │                            │
│           └──────────────────┘                            │
│                     │                                      │
│                     │ <>                         │
│                     ▼                                      │
│           ┌──────────────────┐                            │
│           │Proceed to Checkout                            │
│           └──────────────────┘                            │
│                     │                                      │
│                     │ <>                         │
│                     ▼                                      │
│         ┌──────────────────────┐                          │
│         │   Place Order        │                          │
│         └──────────────────────┘                          │
│                     │                                      │
│         <> │                                      │
│                     ▼                                      │
│         ┌──────────────────────┐                          │
│         │ Process Payment      │ ◄─────┐                 │
│         └──────────────────────┘       │                 │
│                                 (via Payment Gateway)    │
│                                                            │
│  ┌──────────────────┐      ┌──────────────────┐          │
│  │ Manage Inventory │      │Generate Reports  │          │
│  └──────────────────┘      └──────────────────┘          │
│           ▲                         ▲                      │
│           └────────────┬────────────┘                     │
│                        │ <>                      │
│                        ▼                                   │
│           ┌──────────────────────┐                        │
│           │  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                        │         │
│  └──────────────────┘      └──────────────────┘         │
│           ▲                                               │
│           │ <>                                  │
│           │                                               │
│  ┌────────────────────────┐                             │
│  │ Check Patient History  │                             │
│  └────────────────────────┘                             │
│           ▲                                               │
│                                                           │
│  ┌──────────────────────────┐  ┌─────────────────────┐ │
│  │ Record Medical Info      │  │ Update Patient Vitals
│  └──────────────────────────┘  └─────────────────────┘ │
│           ▲                           ▲                   │
│           └─────────────┬─────────────┘                  │
│                  <>                             │
│                         │                                │
│           ┌─────────────▼──────────────┐                │
│           │ Retrieve Medical Records   │                │
│           └───────────────────────────┘                 │
│                         ▲                                │
│                         │ <>                    │
│                         │                                │
│           ┌─────────────▼──────────────┐                │
│           │   Process Billing         │                │
│           └───────────────────────────┘                 │
│                                                           │
│           ┌──────────────────────┐                       │
│           │ 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 line)│
│ 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

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

• 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.