Use Case Diagram Explained: Actors, Include and Extend (Full Example)
"What does checkout actually do?" A use case diagram answers that on one page. In this video I draw a full use case diagram for a made-up online shop checkout: actors, use cases, the system boundary and associations, the include and extend arrows (and which way they point), a 5-step method to draw one, a use case description you can copy, and the 5 mistakes to avoid.
Step by step
A use case diagram is not a flowchart
- A use case diagram is not a flowchart. It shows no steps and no order. It answers 3 questions: who uses the system, what they use it for, and where the system stops. The BABOK Guide from the IIBA covers it under Use Cases and Scenarios. The drawing rules come from UML.
Explain like I'm 5: the menu, not the recipe
- Think of a restaurant menu. It shows what you can order and who it's for, but not the recipe. A use case diagram is the menu of a system: each oval is something someone can get done. The steps, the recipe, go in the use case description.
Diagram plus description (BABOK)
- The BABOK Guide splits a use case into 2 parts. The diagram shows the scope: actors, use cases and how they connect. The description, one per use case, gives the name, goal, actors, preconditions, trigger, flow of events and postconditions. The diagram is the table of contents; the descriptions are the chapters.
What you need before you draw
- Before you draw, have 3 things: a system name and a rough idea of where it stops, your stakeholder list, and goals people told you in interviews or support tickets. Test each use case: one actor, one sitting, one useful result. Place order passes. Click the pay button is a step, not a goal.
The problem: a spec nobody reads
- The example: 2 new developers join an online shop team and ask what checkout actually does. The only answer is a 40-page spec nobody has read. The task is to give them one picture of checkout, built from 4 parts (actor, use case, system boundary, association) and 2 arrows.
Part 1: the actor
- Part 1 is the actor: a stick figure with a name under it. An actor is anyone or anything outside the system that interacts with it. Name the role (shopper), not the person (Maria). Actors can be other systems, like the payment provider. Put primary actors on the left and secondary actors on the right.
Part 2: the use case
- Part 2 is the use case: an oval with a goal inside, named with a verb and a noun, like place order or view cart. It is a whole goal from the actor's side, not a screen or a button. Ask: would the shopper be happy if this was the only thing they did today? Place order, yes. Enter a postcode, no.
Parts 3-4: the boundary and the lines
- Part 3 is the system boundary: a box around the use cases with the system name on top (UML calls it the subject). Inside is what you build; actors stay outside. Track order is outside this box. Part 4 is the association: a plain line meaning this actor takes part. It does not show flow, order or data.
The two arrows: include and extend
- Both arrows are dashed and labelled. Include means always: place order and view cart both include calculate shipping cost, and the arrow points from the base use case to the included one. Extend means sometimes: apply discount code extends place order only when the shopper has a code, and points to the base use case.
Draw it in 5 steps
- A simple 5-step method (the author's, not a BABOK recipe): draw the box, find the actors, find their goals, connect them, and walk it through with users. Step 1 here: a box called online shop checkout, with one line under it. In: the cart, the order, the payment. Out: tracking and returns.
Step 2: find the actors
- Step 2: ask who starts something in checkout, and who checkout needs help from. The shopper starts almost everything; the payment provider takes the money. The warehouse packs orders but never touches checkout, so it is not an actor here. An actor deals with this system, not just with the business.
Step 3: find the goals
- Step 3: list each actor's goals, one oval each: view cart, place order and apply discount code. Both the cart and the order need the shipping cost, so calculate shipping cost becomes its own use case. Enter shipping address fails the test: it's a step inside place order, so it goes in the description.
Step 4: connect and add the arrows
- Step 4: draw lines from the shopper to view cart and to place order, and from place order to the payment provider. Add include arrows from view cart and place order to calculate shipping cost, and an extend arrow from apply discount code to place order. If an arrow doesn't help a reader, leave it out.
Step 5: walk it through
- Step 5: put the diagram on screen and tell the story: the shopper opens the cart, sees the shipping cost, places the order, and the payment provider takes the money. Then ask what's missing. Here the customer service lead adds a new actor, the customer service agent, who places phone orders. Same use case, 2 actors.
Worked example: the finished diagram
- The finished diagram: one box, online shop checkout. On the left, the shopper and the customer service agent. On the right, the payment provider. Inside, 4 use cases. Place order links to all 3 actors, view cart to the shopper. Both include calculate shipping cost, and apply discount code extends place order.
The use case description
- Place order's description. Goal: the shopper buys the cart. Actors: shopper or agent, plus payment provider. Precondition: 1+ item in cart. Trigger: checkout is pressed. Flow: confirm address, see shipping cost, pay, get confirmation. Exception: card declined, no order saved. Success: order saved, email sent.
Build it in draw.io
- In draw.io, click More Shapes, tick UML and click Apply to get the stick figure and oval shapes. Drop in a container, make it tall and name it online shop checkout. Put the shopper outside the box on the left, place order as an oval inside, and draw a plain line between them.
5 common mistakes
- 5 common mistakes: ovals in a sequence with arrows between them (that's a process map), tiny use cases like click pay, people's names instead of roles, include and extend arrows everywhere, and a diagram with no descriptions behind it.
Recap
- Recap: actors sit outside the box and are named as roles. Use cases are a verb and a noun, one useful goal each. The box is the system boundary. Associations are plain lines meaning takes part. Include means always, extend means sometimes. Write a description for every oval.
Common mistakes
- Drawing a flowchart with ovals. If your use cases are chained in order with arrows between them, you have a process map. A use case diagram shows only who does what. Put the order of steps in the use case description or a separate process map.
- Pointing the include or extend arrow the wrong way. Include points from the base use case to the included one (place order to calculate shipping cost). Extend points from the optional piece to the base (apply discount code to place order).
- Steps drawn as use cases. Ovals like click pay or enter shipping address are steps, not goals. Check each one: one actor, one sitting, one useful result. Move the steps into the description.
- Naming people instead of roles. Maria will change jobs, but the shopper role stays. Name actors by role, and remember an actor can be another system, like a payment provider.
When a business analyst uses this
In a scoping workshop, a business analyst puts the draft use case diagram on screen and walks stakeholders through it to agree what is in and out of scope and to spot missing actors, like a customer service agent placing phone orders. Each use case then gets an ID and a description that the requirements log can trace back to.
Questions people ask
What is the purpose of a use case diagram?
It shows on one page who uses a system, what they use it for, and where the system's scope ends. It gives people a quick picture of scope, while the detailed steps go in written use case descriptions.
What is the difference between include and extend in a use case diagram?
Include means a use case always runs as part of another, like place order including calculate shipping cost. Extend means it runs only sometimes, under a condition, like apply discount code extending place order when the shopper has a code.
What is a use case diagram in business analysis?
The BABOK Guide covers it under the Use Cases and Scenarios technique. The diagram shows scope (the actors, the use cases and how they connect), and each use case gets a written description with its goal, trigger, preconditions, flow and postconditions.
