Use-case diagram
Actors, the services they use and the system boundary.
What it explains and when it is useful
A use-case diagram shows who (or what) uses the system and the services the system offers each of them. Actors are outside the boundary; use cases (ovals) are inside.
When to use it: Whenever there is more than one kind of user, a login with roles, or automatic behaviour triggered by time or another system. It is a fast way to show the examiner your design covers every success criterion.
Worked example
Illustrative: PracticePal is a fictional project used throughout this guide.
Scroll sideways to see the whole diagram.
Companion: user roles and permissions table
When users have different rights, a permissions table states exactly who can do what. It doubles as a test list for SC1 (only the head of music can open admin screens).
| Data or action | Student | Head of music | Clock (scheduler) |
|---|---|---|---|
| View week grid (all rooms) | Read | Read | – |
| Own bookings | Create, cancel, check in | Read, cancel | Set status no-show / completed |
| Other students' bookings | See as “Booked” only | Read, cancel | Set status |
| Waiting list entries | Join, accept, leave (own) | Read | Offer, expire |
| Room blocks | – | Create, delete | – |
| Rooms and neighbours | – | Edit | – |
| Usage report | – | Download | – |
Notation and legend
| Symbol or part | Meaning |
|---|---|
| Stick figure | Actor: a role (not a named person) or an external system or clock |
| Oval | Use case: something the actor wants to do, written as a verb phrase |
| Large rectangle | System boundary |
| Plain line | The actor takes part in the use case |
| Dashed arrow «include» | The base use case always uses the other (Book a slot always checks the rules) |
| Dashed arrow «extend» | Optional extra behaviour under a condition (join the waiting list when the slot is full); the arrow points to the base use case |
Design decisions it communicates
A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:
- The clock is an actor because no-shows are released without anyone pressing a button (SC8).
- “Check booking rules” is a separate, included use case, showing that the same rules guard every booking.
- Offering a freed slot is included by both cancelling and releasing no-shows, so it is designed once.
Common mistakes
- Drawing screens or steps in order: use cases are services, not a flowchart.
- Naming people (“Ms Okafor”) instead of roles.
- Pointing «extend» arrows the wrong way (they point to the base use case).
- Calling a class diagram a use-case diagram (the exemplars lost marks for wrong labels).
Checklist for your own version
Ticks are saved in this browser only, so you can use the list while you draft.