What is a Use Case Diagram? Complete Guide with Examples (2026)

What is a Use Case Diagram?

A Use Case Diagram is a high-level Unified Modeling Language (UML) behavioral diagram that visualizes the interactions between external users (Actors) and a system under development to achieve specific business goals.

In business analysis and software engineering, BAs use Use Case Diagrams during requirement gathering to define project scope, establish system boundaries, and illustrate feature interactions without diving into deep code implementation.

4 Essential Components of a Use Case Diagram

Component	Symbol / Representation	Description	Example
1. Actor	Stick Figure	An external entity (person, organization, or third-party system) that interacts with the system.	Customer, Admin, Payment Gateway API.
2. Use Case	Oval / Ellipse	A specific action or feature function performed within the system to achieve a goal.	Transfer Funds, Generate Invoice, Reset Password.
3. System Boundary	Rectangle Box	A rectangular enclosure containing all use cases, defining what is inside vs. outside project scope.	Mobile Banking App Boundary.
4. Relationships	Solid or Dashed Lines	Lines showing interactions between actors and use cases or between individual use cases.	Association (—), Include (<<include>>), Extend (<<extend>>).

Primary vs. Secondary Actors

Understanding actor roles is critical when mapping business requirements:

• Primary Actor: Initiates the interaction with the system to achieve a goal (e.g., a Customer logging in to transfer money). Placed on the left side of the diagram.

• Secondary Actor: Assists the system in fulfilling the primary actor’s request, often by providing backend services (e.g., a Core Banking API or SMS Gateway). Placed on the right side of the diagram.

Relationships in Use Case Diagrams Explained

1. Association (—): A solid line connecting an Actor to a Use Case, representing direct communication.

2. Include (<<include>>): Represents a mandatory sub-step required by a base use case. (Example: Transfer Funds ALWAYS includes Authenticate User).

3. Extend (<<extend>>): Represents optional or conditional functionality that only executes under specific circumstances. (Example: Transfer Funds extends Generate High Value Transaction Alert ONLY IF transfer > $10,000).

4. Generalization (──►): Represents child use cases or actors inheriting properties from a parent. (Example: Credit Card Payment and Net Banking Payment generalize Payment Method).

🏦 Real-Time Scenario: E-Commerce Order Processing System

Context & Objective

A Business Analyst is defining requirements for an online retail portal’s checkout process. The BA creates a Use Case Diagram to present functional scope to stakeholders, developers, and QA teams.

Diagram Breakdown in Practice

• Primary Actors: Registered Customer and Store Admin.

• Secondary Actors: Stripe Payment Gateway API and Email Notification Service.

• System Boundary: E-Commerce Checkout Engine.

• Use Cases inside the Boundary:

  1. Place Order: Triggered by Customer. Includes Validate Cart mandatory step.

  2. Process Payment: Interacts with Stripe Payment Gateway API (Secondary Actor).

  3. Send Order Confirmation: Triggers Email Notification Service.

  4. Apply Discount Code: An <<extend>> relationship attached to Place Order (executes only if user enters a coupon code).

Why the BA Used This Diagram

By reviewing this single visual diagram during the JAD (Joint Application Design) session, the product team immediately noticed that Refund Processing was missing from the initial scope, avoiding a costly mid-sprint redesign.

How to Draw a Use Case Diagram in 5 Steps

1. Identify the Project Scope: Draw a rectangle box representing the system boundary.

2. Identify Primary and Secondary Actors: List all human roles and external systems interacting with the solution.

3. Identify Key Business Functions (Use Cases): Write actionable verbs inside ovals (View Account, Download Statement).

4. Establish Relationships: Connect actors to use cases using association lines.

5. Apply Include & Extend Rules: Add conditional or mandatory relationships between use cases.

🔗 Business Analysis Resource Hub (Internal Links)

• 📘 Documentation Blueprint: BRD vs FRD Differences & Real-World Examples — Learn how Use Case Diagrams convert into FRD requirements.

• 🛠️ Waterfall & SDLC: Waterfall Model in Software Engineering: 6 Phases & BA Role — Understand where UML diagrams fit into traditional SDLC phases.

• ✍️ Agile Requirements: How to Write User Stories with Examples — Transition from Use Case Diagrams to Agile User Stories and Acceptance Criteria.

 

UseCase diagrams plays very important role, these diagrams help to understand the relationship between user to user and user to system. Like what is the relationship with the user and what are the actions done by the User and how user wants to interact with the system.

The focus of this diagram will be on “how external interfaces” (End users, Support systems, Database and internet connectivity to third party) will be interacting with the Proposed IT System.

Use Case Diagram contains below:

1. Use Case will be as below:

        2. Actor:

        3. Use Case System Boundary.

        4. Lines to match the Activity with the user:

---

Relationships between Actors and Use-Cases

Use-cases could be organized using following relationships −

• Generalization
• Association
• Extend
• Include

Where and Why Use Case Diagrams can be used:

1. Describe the functionality of a System
2. Describe the user Actions
3. Use case diagrams represents only positive flow.
4. Should not use for alternate flow, like if any error happens what to be done.
5. To describe how user interacts with the system.
6. To describe how external interfaces, interact with the proposed system.
7. Actor and use case play important role.
8. Lines represent the relationship between Actor and Use Case (Oval Shape).

Information which we should not use in use case diagrams.

1. Technology Names (Java, .Net Mainframes)
2. Brand Names ( Lenovo, Sony etc..)
3. Data Base Names (SQL, MySQL, Oracle etc..)
4. Networks (LAN, WAN etc.,)
5. Architectures (2 Tier, 3 Tier etc..)
6. Name of the systems (Laptop/ Desktop)

Actor :

1. Actor stay away from the system boundary.
2. Primary actor initiates the system to work.
3. System depends on secondary actor for information.
4. Reusable actors will be placed right side of the system boundary.

How to draw Use Case diagram

1. Write all sequence of Actions.
2. Differentiate information against Actions.
3. Try to find out which actor is performing which action.
4. Try to find out some modules with respect to functionality or usage.
5. Try to draw the relationships between the identified Actors and use Cases

Once completes the Use case diagram then we will prepare use Case Specification Document. This is also called as Use Case description Document. This document helps to provide the clear picture of the Use Case Diagram.

UseCase Specification document contains below.

1. Name of the Use Case
2. Description of the Use Case
3. Actors
4. Primary
5. Secondary
6. Basic flow
7. Pre-Conditions
8. Post conditions
9. Assumptions
10. Dependencies
11. Constraints
12. Input and output
13. Miscellaneous information.
14. Alternate Flow.

We can’t tell which use case diagram is correct and which use case diagram is wrong. It depends on the project and stakeholders.

How to Derive Test cases.

1. UseCase Diagram
2. UseCase Description Document
3. UseCase specification document will have, Basic flow, Alternate flow and description of the use cases.
4. We can identify the scenarios from these flows.
5. Try to identify 3 to 5 valid test data from each scenario.
6. Then try to write the test cases from the gathered test data and scenarios.

To Know more about UML Diagrams.

Frequently Asked Questions (FAQ)