Use Case Diagram

What this diagram shows

A use case diagram models interactions between actors (users, systems, or external entities) and a system under study. It shows what the system does from the perspective of those who use it, without detailing how. Actors appear as stick figures or roles on the left and right; use cases appear as ovals in the centre, connected to actors by lines showing relationships. The boundary rectangle encloses all use cases belonging to the system. The diagram captures functional requirements and clarifies scope by showing which features exist and who interacts with them.

Key components

• Actor — A user, external system, or role that interacts with the system and initiates or participates in use cases.
• Use Case — A named oval representing a specific interaction or feature the system provides, such as 'Login User' or 'Generate Report'.
• System Boundary — A rectangle that encloses all use cases and shows the limits of what the system is responsible for delivering.
• Association — A line connecting an actor to a use case, showing that the actor participates in or triggers that interaction.
• Include Relationship — A dashed arrow (stereotyped <<include>>) showing that one use case always calls another as a mandatory sub-step.
• Extend Relationship — A dashed arrow (stereotyped <<extend>>) showing that one use case may conditionally add behaviour to another under specific circumstances.
• Generalization — A solid arrow showing that an actor or use case inherits from a parent actor or use case, representing specialisation or hierarchy.

When to use it

Use case diagrams are most effective during requirements gathering and system design, particularly when you need to communicate functionality to stakeholders who are not technical. They work well for defining scope, identifying actors, and capturing what the system must do. Use them early in the project to gain alignment on features and boundaries before detailed design or implementation. Avoid them if you need to show how the system works internally or the sequence of steps within a single interaction; sequence or activity diagrams suit those purposes.

Common mistakes

• Placing implementation details inside use cases (such as 'read from database') instead of keeping them at the user-facing interaction level like 'retrieve account information'.
• Creating too many include and extend relationships without clear rationale, which clutters the diagram and obscures the actual interactions users care about.
• Forgetting to define the system boundary, making it unclear whether a use case belongs to your system or an external one, and confusing stakeholders about project scope.

Adapting it to your system

Start by identifying all actors: users, external systems, and roles that touch your system. List each interaction each actor needs to perform, then draw ovals for those interactions inside your system boundary. Connect actors to use cases with lines. If one use case always requires another (such as 'verify payment' whenever 'checkout' happens), use <<include>>. If behaviour is optional or triggered by a condition, use <<extend>>. Keep the diagram at a high level; if it grows beyond 15 use cases, split it into separate diagrams by module or subsystem to maintain clarity.