UML: Use Case Diagrams & Scenarios
Project: A Use Case Model
Project: A Use Case Model
This final lesson is a complete, end-to-end modeling project. You will build the entire use case model for a realistic system — the Online Bookstore — from a brief stakeholder description, through a full use case diagram with relationships, to two fully-dressed scenarios that a development team could hand directly to a developer or tester. Everything you practiced across this tutorial converges here.
What you will produce: (1) a complete use case diagram showing actors, use cases, system boundary, include/extend relationships, and actor generalization; (2) two fully-dressed use case scenarios written in the standard template with main success flow, alternate flows, and exception flows.
Step 1 — The Project Brief
The business analyst has conducted stakeholder interviews for an Online Bookstore. The key facts are:
- A Guest (unauthenticated visitor) can browse the catalog, search for books, and view a book detail page. Guests can also register for an account.
- A Registered Customer (extends Guest — a Registered Customer can do everything a Guest can, plus more) can log in, add books to a wishlist, add books to the shopping cart, and place an order. Placing an order always requires the customer to confirm payment details — a sub-behavior that is always included.
- Whenever an order is placed, the system must send a confirmation email. This is handled by the Email Service, an external system.
- A Store Administrator can log in to the admin panel, manage the book catalog (add, edit, remove books), and process refund requests.
- Processing a refund always includes verifying the original order — mandatory sub-behavior.
- A Registered Customer may optionally write a review after placing an order — but only if they choose to.
- An external Payment Gateway handles the actual charge whenever the customer confirms payment.
Step 2 — Identify Actors and Use Cases
From the brief, the analyst identifies the following actors and goals:
- Actors: Guest, Registered Customer (generalizes Guest), Store Administrator, Email Service, Payment Gateway.
- Use cases: Browse Catalog, Search Books, View Book Details, Register Account, Log In, Add to Wishlist, Add to Cart, Place Order, Confirm Payment, Write Review, Manage Book Catalog, Process Refund, Verify Order, Send Confirmation Email.
- Relationships:
Place Order«include»Confirm Payment— always happens.Confirm Paymenttriggers the Payment Gateway (association to external actor).Place Order«include»Send Confirmation Email— Email Service always triggered.Place Order«extend»Write Review— optional, post-order.Process Refund«include»Verify Order— always happens.- Registered Customer generalizes Guest — inherits Browse, Search, View, Register.
Step 3 — The Full Use Case Diagram
Reading the diagram: follow the generalization arrow first — a Registered Customer inherits all Guest associations (Browse Catalog, Search Books, View Book Details, Register Account) without repeating the lines. The «include» dashed arrows show mandatory sub-behaviors; the «extend» dashed arrow to Write Review shows an optional post-order activity. Every actor sits outside the system boundary rectangle.
Step 4 — Fully-Dressed Use Case Scenario 1: Place Order
A fully-dressed scenario is a structured prose document that specifies every step, condition, alternative path, and exception for one use case. Below is the complete scenario for Place Order, the most business-critical use case in this system.
Use Case ID: UC-05
Name: Place Order
Actor(s): Registered Customer (primary); Payment Gateway, Email Service (supporting)
Preconditions:
1. Customer is logged in.
2. Shopping cart contains at least one item with sufficient stock.
Goal: Customer successfully purchases all items in the cart.
Trigger: Customer clicks "Proceed to Checkout."
MAIN SUCCESS FLOW (Basic Path)
1. System displays the order summary: items, quantities, unit prices, subtotal, tax, total.
2. Customer reviews the summary and confirms.
3. System prompts for payment details (card number, expiry, CVV).
[INCLUDE: Confirm Payment]
4. Payment Gateway authorizes the charge.
5. System decrements stock for each ordered item.
6. System creates an order record with status "Confirmed."
7. System triggers the Email Service.
[INCLUDE: Send Confirmation Email]
8. System displays the order confirmation page with order ID and estimated delivery date.
[EXTEND: Write Review — available after order is confirmed, at customer's discretion]
ALTERNATE FLOWS
A1 — Customer edits the cart (step 2):
A1.1 Customer clicks "Edit Cart."
A1.2 System returns to the cart page.
A1.3 Use case resumes from step 1 when customer returns to checkout.
A2 — Customer applies a discount code (step 2):
A2.1 Customer enters a discount code.
A2.2 System validates the code; if valid, recalculates the total.
A2.3 If invalid, system displays "Invalid or expired code" and keeps the original total.
A2.4 Use case resumes from step 2.
EXCEPTION FLOWS
E1 — Payment is declined (step 4):
E1.1 Payment Gateway returns "Declined."
E1.2 System displays "Payment declined. Please check your card details or use a different card."
E1.3 System does NOT decrement stock or create an order record.
E1.4 Customer may re-enter payment details (return to step 3) or cancel the order.
E2 — Item goes out of stock between cart and checkout (step 5):
E2.1 System detects zero available stock for at least one cart item.
E2.2 System cancels the charge via the Payment Gateway (refund request).
E2.3 System displays "Sorry, [item] is no longer in stock. Your payment has not been taken."
E2.4 System removes the out-of-stock item from the cart.
E2.5 Customer may continue with remaining items (return to step 1) or cancel.
E3 — Email Service is unavailable (step 7):
E3.1 Email Service returns a timeout or error.
E3.2 System logs the failure and queues the email for retry.
E3.3 Order is still confirmed; customer sees the confirmation page without email mention.
Postconditions (success): Order record created, stock decremented, confirmation email sent.
Postconditions (failure): No order record; stock unchanged; card not charged.
Step 5 — Fully-Dressed Use Case Scenario 2: Process Refund
Use Case ID: UC-12
Name: Process Refund
Actor(s): Store Administrator (primary); Payment Gateway (supporting)
Preconditions:
1. Administrator is logged in to the admin panel.
2. A customer has submitted a refund request through the customer portal.
Goal: Administrator issues a full or partial refund and closes the request.
Trigger: Administrator opens a pending refund request from the queue.
MAIN SUCCESS FLOW (Basic Path)
1. System displays the refund request: customer name, order ID, items, reason, requested amount.
2. Administrator reviews the request.
[INCLUDE: Verify Order]
3. System retrieves and displays the original order record: payment status, items shipped, amount charged.
4. Administrator confirms the refund amount (full or partial) and clicks "Approve Refund."
5. System sends a refund instruction to the Payment Gateway for the approved amount.
6. Payment Gateway confirms the refund is processed (typically 3-5 business days for card refunds).
7. System updates the order status to "Refunded" (full) or "Partially Refunded."
8. System notifies the customer by email that the refund has been approved.
9. System closes the refund request with status "Resolved."
ALTERNATE FLOWS
A1 — Administrator issues a partial refund (step 4):
A1.1 Administrator enters a custom amount less than the original charge.
A1.2 System validates the amount is not greater than the original charge.
A1.3 Use case continues from step 5 with the partial amount.
A2 — Administrator rejects the refund request (step 4):
A2.1 Administrator clicks "Reject" and enters a rejection reason.
A2.2 System notifies the customer by email with the rejection reason.
A2.3 System closes the request with status "Rejected."
A2.4 Use case ends.
EXCEPTION FLOWS
E1 — Original order not found (step 3):
E1.1 System cannot locate the order record (deleted or data integrity issue).
E1.2 System displays "Order record not found. Contact database administration."
E1.3 Use case is suspended; administrator escalates to technical support.
E2 — Payment Gateway rejects the refund (step 6):
E2.1 Gateway returns an error (e.g., original charge too old, gateway technical issue).
E2.2 System displays the gateway error message to the administrator.
E2.3 System marks the refund request as "Pending — Gateway Error."
E2.4 Administrator contacts the payment provider directly to resolve.
Postconditions (success): Refund issued, order status updated, customer notified.
Postconditions (failure): No refund issued; request remains open or rejected.
What Makes a Complete Use Case Model
A finished use case model is not just a diagram. It consists of three layers:
- The diagram — gives the big picture: scope, actors, goals, and relationships at a glance. This is your communication tool for stakeholder reviews.
- The scenario documents — one fully-dressed scenario per important use case. These are the bridge between requirements and design: a developer reads the scenario and knows exactly what to build; a tester reads it and knows every path to verify.
- The glossary and business rules — definitions of domain terms (what counts as "in stock"? what is the refund window?) that the scenarios reference but do not define inline. Kept in the Requirements Specification Document (RSD).
Do not write fully-dressed scenarios for every use case. Prioritize: write fully-dressed scenarios for use cases that are high-risk, involve complex flows, or are business-critical (Place Order, Process Refund, Register Account). For simple use cases (Browse Catalog, View Book Details), a brief scenario or just the diagram association is enough. Over-documenting wastes time and produces specs nobody reads.
Project Checklist — Before You Hand Off the Model
- Every actor is named as a role, not a person or a job title.
- Every use case is named with a verb phrase from the actor's perspective.
- All actors sit outside the system boundary; all use cases sit inside it.
- «include» relationships point to mandatory sub-behaviors; «extend» relationships point to optional extensions with an extension point noted.
- Generalization arrows use a hollow-triangle arrowhead pointing to the parent actor or use case.
- Each fully-dressed scenario has: ID, name, actor(s), preconditions, trigger, main success flow, at least one alternate flow, at least one exception flow, and postconditions.
- The model has been reviewed with at least one domain stakeholder — not just the development team.
Summary
You have now produced a complete, professional use case model: a diagram with all five notation elements (actor, use case, system boundary, association, include/extend/generalization), and two fully-dressed scenarios covering the most critical flows with their alternate and exception paths. This is the deliverable a systems analyst hands to a project team before detailed design begins — and it is the artifact that testers use to derive their test cases in the next phase of the SDLC.