What is a Use Case?
A use case describes a specific way that a system interacts with its users (actors) to achieve a particular goal. It captures the functional requirements of a system from the user's perspective — what the system does, not how it does it internally.
Think of use cases as stories: "As a [role], I want to [action] so that [benefit]." Each use case represents one complete interaction that delivers value to an actor.
Use Case: "Place an Order"
┌─────────────────────────────────────────────────────┐
│ Actor: Customer │
│ Goal: Successfully place an order for items │
│ │
│ Preconditions: │
│ • Customer is logged in │
│ • Cart has at least one item │
│ • Customer has a valid shipping address │
│ │
│ Main Flow: │
│ 1. Customer reviews cart │
│ 2. Customer proceeds to checkout │
│ 3. System displays order summary │
│ 4. Customer selects payment method │
│ 5. System processes payment │
│ 6. System confirms order │
│ 7. System sends confirmation email │
│ │
│ Alternative Flows: │
│ 5a. Payment fails → Show error, return to step 4 │
│ 5b. Card declined → Suggest different payment │
│ │
│ Postconditions: │
│ • Order is created with status "confirmed" │
│ • Inventory is decremented │
│ • Payment is recorded │
│ • Confirmation email is sent │
└─────────────────────────────────────────────────────┘Anatomy of a Use Case
Every well-written use case has these key components:
1. Name
A clear, verb phrase describing the goal.
"Register Account", "Search Products", "Generate Report"
2. Actor
Who or what initiates or participates in the use case.
Can be a human user, external system, or timer.
3. Preconditions
What must be true before the use case can start.
"User must be authenticated" or "Cart is not empty"
4. Main Flow (Happy Path)
The step-by-step sequence for the successful scenario.
Each step describes an interaction between actor and system.
5. Alternative Flows
Variations that occur when conditions differ.
"Payment declined" or "Item out of stock"
6. Exception Flows
Error conditions and how the system handles them.
"Network timeout" or "Invalid input"
7. Postconditions
What is true after the use case completes successfully.
"Order is created" or "Email is sent"Identifying Use Cases
Use cases come from analyzing the goals and tasks of each actor in the system. Start by listing what each actor wants to accomplish:
System: Online Bookstore
Actors and their goals:
┌──────────────┬─────────────────────────────────────────┐
│ Actor │ Goals │
├──────────────┼─────────────────────────────────────────┤
│ Customer │ • Browse books │
│ │ • Search for specific books │
│ │ • Add books to cart │
│ │ • Place an order │
│ │ • Track order status │
│ │ • Return a book │
│ │ • Write a review │
├──────────────┼─────────────────────────────────────────┤
│ Admin │ • Add/edit/remove books │
│ │ • Manage inventory │
│ │ • View sales reports │
│ │ • Process returns │
│ │ • Manage user accounts │
├──────────────┼─────────────────────────────────────────┤
│ System │ • Send order confirmations │
│ │ • Process payments │
│ │ • Update inventory │
│ │ • Generate invoices │
└──────────────┴─────────────────────────────────────────┘
Each goal becomes a use case candidate.
Filter: is it specific enough? Does it deliver value?Use Case Relationships
Use cases can relate to each other in three ways:
1. Include («include»)
─────────────────────
One use case REQUIRES another to complete.
The base use case always includes the included one.
"Place Order" «include» "Process Payment"
You can't place an order without processing payment.
2. Extend («extend»)
──────────────────
One use case EXTENDS another with optional behavior.
The extension only happens under certain conditions.
"Place Order" «extend» "Apply Discount Code"
Discounts are optional — not every order has one.
3. Generalization
──────────────
A child use case inherits from a parent use case.
The child specializes the parent's behavior.
"Make Payment" ▶ "Pay with Credit Card"
"Pay with PayPal"
"Pay with Bank Transfer"Example Use Case Diagram:
┌─────────────────────────────────────────────────┐
│ Online Bookstore │
│ │
│ «include» │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ Process │◀────│ Place Order │ │
│ │ Payment │ └────────┬─────────┘ │
│ └──────────────┘ │ │
│ «extend» │
│ ┌──────────────────┐ │
│ │ Apply Discount │ │
│ │ Code │ │
│ └──────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Browse Books │ │ Search Books │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
▲ ▲
│ │
┌─────┴─────┐ ┌──────┴──────┐
│ Customer │ │ Admin │
└───────────┘ └─────────────┘Writing Good Use Cases
Follow these guidelines for effective use cases:
DO:
✓ Use clear, action-oriented titles ("Place Order", not "Order")
✓ Write steps from the actor's perspective
✓ Keep steps atomic (one action per step)
✓ Include all alternative and exception flows
✓ Define clear preconditions and postconditions
DON'T:
✗ Mix multiple goals into one use case
✗ Include implementation details ("System queries MySQL database")
✗ Use vague language ("System handles things properly")
✗ Create use cases for every tiny action ("Click button")
✗ Forget error scenariosBad Use Case Steps:
1. User clicks button
2. System processes data
3. Something happens
Good Use Case Steps:
1. Customer selects items and clicks "Checkout"
2. System displays order summary with items, quantities, and total
3. Customer selects payment method (Credit Card, PayPal, or Bank Transfer)
4. Customer enters payment details and clicks "Confirm Payment"
5. System validates payment information
6. System processes the payment with the payment gateway
7. System creates the order with status "Confirmed"
8. System displays order confirmation with order number
9. System sends confirmation email to customer's registered email