UML use case diagram template
Two actors, a system boundary and four use cases with a correct include and extend already drawn - the scope diagram a requirements document actually needs.
Notation: UML 2.5.1Diagram: Use case diagram
Open this template in Archyno
It opens as an editable model, not an image. Change it in the browser, then export to PNG, SVG, Mermaid, XMI, or a Sparx .qea file.
Open this templateWhat is on this diagram
- System boundary
- The rectangle. Everything inside it is yours to build.
- Customer
- The primary actor - the one with a goal. Rename to yours.
- Administrator
- A secondary actor. Delete it if only one role matters.
- Place order
- The goal-level use case. One per thing an actor wants done.
- «include»
- Always-runs behaviour factored out of the base case.
- «extend»
- Conditional behaviour. The arrow points at the case it extends.
How to make it yours
- Name every use case verb-first, from the actor's side: 'Place order', not 'Order processing'.
- Put the boundary around what you are building, and leave every actor outside it.
- Keep the include arrow pointing away from the base case and the extend arrow pointing at it.
- Delete any use case that is a step rather than a goal - logging in is not usually a goal.
- Stop at about eight ovals. A use case diagram is a table of contents, not the contents.
Common questions
What is the difference between include and extend?
Include is behaviour the base use case always runs, factored out so two cases can share it, and its arrow points from the base to the included case. Extend is behaviour that runs only under a condition, and its arrow points from the extending case back at the base.
Should actors go inside the system boundary?
No. The boundary encloses what you are responsible for building, and an actor is by definition outside it - a person, another system, or a clock. Putting an actor inside is the single most common error on a use case diagram, because it quietly claims you are building the user.
How detailed should a use case diagram be?
Barely. It exists to name the goals and show who has them, and the detail belongs in the use case text underneath. Eight ovals is a healthy diagram; thirty is a diagram nobody reads and a scope nobody agreed to.
Read the notation
Use case diagrams
How to read and draw a UML use case diagram: actors, the system boundary, associations, and the include and extend relationships that people most often get backwards.
What is UML?
The Unified Modeling Language in practice: the fourteen diagram types, how structure and behaviour split, and how to pick the right diagram for the question you are actually asking.
Activity diagrams
How to read and draw a UML activity diagram: actions, decisions and merges, forks and joins, guards, swimlanes, and the difference between a branch and true parallelism.