Use case diagram

Use case diagrams give a team a one-page answer to “what does this system do, and for whom?” Product managers use them to set the scope of a release, and engineers use them to check that every feature has an owner and that nothing outside the boundary has been assumed to exist.

When should you use a use case diagram?

• Scoping a system or a feature. Agree on what is inside the boundary and what is not before design starts.
• Finding the actors. List every kind of user and every external system the new system has to talk to.
• Writing requirements. Each oval becomes a use case description or a set of user stories, so the diagram doubles as a table of contents.
• Explaining a system to stakeholders. It is the most readable UML diagram for people who do not write code.

What are the parts of a use case diagram?

Actors

An actor is a role outside the system that interacts with it. It is drawn as a stick figure with a name under it. Actors can be people, such as a customer or an administrator, or other systems, such as a payment network. A primary actor starts a use case; a secondary actor is called on during it.

Use cases

A use case is one goal an actor can achieve with the system, drawn as an oval with a short verb phrase inside, such as “Transfer funds”. It is a complete goal, not a step, so “Enter PIN” is too small and “Use the bank” is too large.

System boundary

A rectangle around the use cases with the system’s name on it. Actors sit outside it. The boundary is the whole point of the diagram: it makes the scope visible.

Relationships

Relationship	Notation	Meaning
Association	Solid line from an actor to a use case	The actor takes part in the use case
Include	Dashed arrow labeled «include», pointing at the included use case	The base use case always runs the included one
Extend	Dashed arrow labeled «extend», pointing at the base use case	The extension runs only under some condition
Generalization	Solid line with a hollow triangle	One actor or use case is a special kind of another

Include pulls out a shared step, so “Verify identity” is drawn once rather than inside three use cases. Extend is for optional behavior, so the base use case stays simple.

How do you read a use case diagram?

Start with the actors, then follow their lines into the boundary. In the online banking example, the customer is connected to “View balance”, “Transfer funds” and “Pay bill”. The administrator is connected to “Manage accounts” and “Review audit log”. Two actors with no shared use cases tells you the system has two distinct audiences.

Then read the dashed arrows. “Transfer funds” and “Pay bill” both point at “Verify identity” with «include», so every transfer and every bill payment goes through an identity check, and that check is specified once. “Confirm large transfer” points at “Transfer funds” with «extend», so the confirmation step exists but only applies in some cases, such as transfers over a limit. The condition itself is written in the use case description, not on the diagram.

What the diagram does not say is also useful. There is no “Open account” oval, so account opening happens somewhere else, and there is no payment network actor, so either transfers stay within the bank or an actor is missing.

How do you create a use case diagram?

1. Name the system. Write it on the boundary. If you struggle to name it, the scope is not clear yet.
2. List the actors. Ask who uses the system and what other systems it depends on. Name roles, not people.
3. List each actor’s goals. Each goal that the system completes on its own becomes a use case. Use a verb and an object.
4. Draw the associations. Connect each actor to the use cases it starts or takes part in.
5. Factor out shared steps with include. If three use cases all verify identity, pull it out.
6. Add exceptions with extend. Keep the base use cases for the normal path.
7. Review the boundary. Anything an actor needs that is not inside it is either out of scope or missing.

What are common use case diagram mistakes?

• Use cases that are steps. “Click submit” is not a goal. Each oval should be something an actor would recognize as finished.
• Modeling the flow. A use case diagram has no order. If you find yourself drawing arrows between use cases to show sequence, you want an activity diagram or a user flow.
• Overusing include and extend. A diagram where every oval points at another is harder to read than one with a few duplicated steps.
• Actors inside the boundary. If a role is inside the system, it is a component, not an actor.

How does a use case diagram compare with other diagrams?

Diagram	What it shows	Use it when
Use case diagram	What the system does and for whom	You are agreeing on scope
User flow	The screens and choices in one task	You are designing the path through one use case
User journey map	A user’s experience over time, across touchpoints	You are looking beyond the system at the whole experience
Activity diagram	The steps and decisions inside a use case	You need the detail of how a use case runs
Sequence diagram	The messages between components during a use case	You are designing the implementation

What tools can you use to make a use case diagram?

• Drag-and-drop diagramming tools. Most include the UML use case shapes. They suit stakeholder-facing diagrams where the layout matters.
• Diagram-as-code tools. PlantUML has a use case syntax, so the diagram can sit in the repository next to the requirements it summarizes.
• AI diagramming tools. Tools like Eraser take a product description or a requirements document and return a use case diagram you can keep editing, which is a quick way to get a first draft of the scope on the page.

Frequently asked questions