Use Case Diagram For System

What this diagram shows

A use case diagram maps the interactions between external actors and a system by showing what actions users or other systems can perform. Actors appear as stick figures or labels on the left, the system sits as a bounded box in the centre, and use cases inside the box represent distinct functionalities or user goals. Lines called associations connect actors to the use cases they initiate, while generalisation relationships and include/extend dependencies show how use cases relate to each other. This layout communicates scope, user roles, and system responsibilities at a glance.

Key components

• Actor — Represents an external user, role, or system that interacts with the system boundary.
• System Boundary — The rectangle that encloses all use cases and defines what belongs inside the system versus what lies outside.
• Use Case — An oval or ellipse inside the boundary describing a specific goal or interaction the system provides to an actor.
• Association — A straight line connecting an actor to a use case to show that the actor participates in or initiates that use case.
• Include Relationship — A dashed line with the stereotype <<include>> showing that one use case always calls another use case as part of its flow.
• Extend Relationship — A dashed line with the stereotype <<extend>> indicating that one use case optionally extends another use case under certain conditions.
• Generalisation — An inheritance arrow showing that one actor or use case is a specialisation of a more general parent actor or use case.

When to use it

Use this diagram early in requirements gathering to identify system scope, define user roles, and communicate what the system will and will not do. It works well for stakeholder discussions, project planning, and as a foundation for detailed requirements documentation. Avoid it when you need to show internal system logic, timing sequences, or data flows; use activity or sequence diagrams for those.

Common mistakes

• Drawing use cases as outputs or data instead of user goals (for example, 'login credentials' rather than 'authenticate user').
• Placing actors inside the system boundary or use cases outside it, which confuses what is internal responsibility versus external interaction.
• Creating overly detailed use case diagrams with dozens of use cases and tangled relationships instead of focusing on primary user journeys and key system responsibilities.

Adapting it to your system

Start by listing your main user roles or external systems as actors on the left side. Name each major goal or feature the system must support as a use case inside the boundary. Draw associations from actors to the use cases they trigger. Use <<include>> for mandatory sub-flows (for example, 'log in' may be included in many use cases) and <<extend>> for optional or conditional behaviour. Organise related use cases visually and review the diagram with stakeholders to confirm completeness and accuracy.