Use Case Diagram: Symbols, Steps & Example Guide

A use case diagram is a UML behavioral diagram that shows how actors interact with a system and what that system does for them. It captures the outside view: who uses the software, what goals they pursue, and where the system boundary sits. You read it in seconds, which is why product teams reach for it when scoping features and writing requirements.

The diagram sits in the same family as the other UML diagram types you may already sketch, and it pairs well with a sequence diagram example once you drill into a single interaction. Where a user story template captures one need in a sentence, a use case diagram maps every goal against the system at once. This guide covers the symbols, the include and extend relationships, a numbered how-to, and a worked SaaS example you can adapt.

Use case diagrams entered UML when the Object Management Group standardized the language in 1997, drawing on Ivar Jacobson's earlier work on use cases. Nearly three decades later the notation has barely changed, which is part of its value. A diagram you drew years ago still reads correctly today, and a new hire who learned UML anywhere can parse it without a legend.

Use case diagram vs user story vs activity diagram

Teams mix these three up constantly, so it helps to place them side by side before going deeper. Each answers a different question about the same feature, and each lives in a different part of your requirements documentation.

A use case diagram gives you the map. A user story gives you a single destination on that map. An activity diagram gives you the turn-by-turn directions for reaching one destination. You often draw all three for the same feature at different moments, starting broad and narrowing as the work gets concrete.

Reach for a use case diagram early, when the scope of a system is still fuzzy and a team needs to agree on what it will and will not do. It shines in kickoff meetings, requirements reviews, and any conversation where a non-technical stakeholder needs to see the whole picture. Once everyone agrees on the goals, you break each one into stories and model the tricky flows in detail. The diagram then becomes the index that ties those smaller artifacts back to the system as a whole.

Use case diagram symbols

A use case diagram uses a small, fixed vocabulary. Master five symbols and you can read or draw almost any diagram you meet. The UML specification, maintained by the Object Management Group, keeps these notations stable across tools, so a diagram drawn in one editor reads the same in another.

• Actor: a stick figure representing a role that interacts with the system. An actor is a user type or an external system, never a specific person. Examples: Customer, Admin, Payment Gateway.
• Use case: an oval holding a verb phrase that names a goal the system delivers. Examples: "Place Order," "Reset Password," "Generate Report."
• System boundary: a labeled rectangle drawn around the use cases. Everything inside is your system; actors stay outside.
• Association: a plain line connecting an actor to a use case, showing that the actor takes part in that goal.
• Relationships: dashed or solid arrows between use cases, covered next.

Keep actor names as roles and use case names as short verb phrases. That discipline keeps the diagram readable at a glance, which is the entire point of drawing one.

Include, extend, and generalization

Three relationships connect use cases to each other, and they trip up newcomers most. Getting them right separates a clear diagram from a confusing one.

Include means one use case always runs another as a mandatory step. "Place Order" includes "Validate Payment" because you cannot place an order without validation. Draw a dashed arrow labeled <<include>> pointing from the base use case to the included one.

Extend means one use case optionally adds behavior to another under a condition. "Place Order" is extended by "Apply Discount Code" because a discount only applies when the customer enters a code. Draw a dashed arrow labeled <<extend>> pointing from the extension to the base use case.

Generalization means one actor or use case is a specialized version of another. A "Premium Customer" generalizes from "Customer" and inherits every association the parent has. Draw a solid line with a hollow triangle arrowhead pointing at the parent.

How to create a use case diagram

You do not need a modeling degree to draw one. Follow these six steps and the structure falls into place. The order matters: define the edges before you fill in the middle.

1. Identify the system boundary. Decide what you are modeling and draw the labeled rectangle. Everything inside is in scope; everything else is an actor or ignored.
2. List the actors. Name every role and external system that interacts with your software. Place them outside the boundary, primary actors on the left and secondary ones on the right.
3. Capture the use cases. For each actor, ask what goals they pursue. Write each as a verb phrase inside an oval within the boundary.
4. Connect associations. Draw a line from each actor to every use case they participate in. If nothing connects an actor, you have missed a goal or an actor.
5. Add relationships. Layer in include, extend, and generalization where behavior is shared, optional, or inherited. Do not force them; only add what clarifies.
6. Review with stakeholders. Walk the diagram past the people who requested the feature. Missing use cases surface fast when a domain expert reads it.

Resist the urge to model internal steps. A use case diagram answers "what and who," not "how." Save the how for an activity or sequence diagram.

Use case diagram example

Consider a SaaS checkout system. The actors are a Customer, an Admin, and an external Payment Gateway. The Customer wants to browse products, place an order, and view order history. The Admin wants to manage the product catalog. The Payment Gateway, a secondary actor, participates whenever payment is validated.

Placing an order includes validating payment every time, so that relationship is an include. Applying a discount code happens only sometimes, so that is an extend on "Place Order." A Premium Customer inherits every Customer goal and adds "Access Priority Support," a clean case for generalization.

Mermaid has no native use case diagram type, so the example below approximates one with a flowchart LR. Actors sit outside a subgraph that stands in for the system boundary, and lines connect actors to labeled use case nodes. The rendered result reads like a use case diagram even though the underlying syntax is a flowchart.

flowchart LR
    Customer((Customer))
    Admin((Admin))
    Gateway((Payment Gateway))

    subgraph System [Checkout System]
        UC1([Browse Products])
        UC2([Place Order])
        UC3([View Order History])
        UC4([Validate Payment])
        UC5([Manage Catalog])
    end

    Customer --- UC1
    Customer --- UC2
    Customer --- UC3
    Admin --- UC5
    UC2 -. include .-> UC4
    Gateway --- UC4

Read left to right, the diagram says the Customer browses, orders, and reviews history; the Admin manages the catalog; and placing an order always pulls in payment validation, which the external gateway handles. That single picture aligns a whole team on scope faster than a page of prose. To learn the full flowchart vocabulary behind this approximation, see the Mermaid diagram syntax guide.

The Mermaid approximation drops two things a strict UML tool would draw: the dashed <<extend>> arrow for the optional discount code, and the hollow triangle marking Premium Customer as a specialization of Customer. You can add those as labeled edges and extra nodes, but the trade-off is honest. You gain a diagram that lives in version control and loses a little notational precision. For most product and requirements docs, that trade favors keeping the diagram as text. When you need pixel-perfect UML for a formal specification, a dedicated modeling tool still wins, and nothing stops you from keeping both.

Common mistakes

The same errors show up in nearly every first draft. Watch for these and your diagrams stay clean.

Modeling steps instead of goals. "Enter Email," "Click Submit," and "See Confirmation" are steps, not use cases. Collapse them into one goal like "Register Account." A use case diagram is not a flowchart.

Overusing include and extend. These relationships add power but also clutter. If a diagram has more dashed arrows than associations, you are modeling internal logic that belongs in an activity diagram instead.

Naming actors as people. "Sarah from finance" is a person; "Finance Manager" is a role. Always name the role, because roles outlive individuals and keep the diagram reusable.

Forgetting secondary actors. External systems like payment gateways, email services, and third-party APIs are actors too. Leaving them off hides real integration requirements from your team.

Cramming everything onto one canvas. A diagram with forty use cases stops being readable. When a system grows large, split it into several diagrams by subsystem or by actor, and keep each one focused on a handful of related goals. A reader should grasp any single diagram in under a minute.

Use case diagrams in your documentation

A use case diagram earns its keep when it lives inside your requirements and product docs, not in a slide deck that nobody opens again. The trouble starts when you export the diagram as a PNG and paste the image into a doc. The moment someone adds an actor or renames a goal, that exported image goes stale, and readers trust a picture that no longer matches the build.

Keeping the diagram as code fixes the drift. When your use case diagram is a Mermaid block in a Markdown file, it updates in the same pull request as the feature it describes and never falls out of sync. Docsio generates a documentation site from your URL and renders Mermaid natively, so your diagrams stay in version-controlled docs beside the product requirements they support. Edit the text, and the diagram redraws on publish.

That keeps use case diagrams useful long after the kickoff meeting. Requirements evolve, and a diagram that evolves with them stays a source of truth instead of becoming a historical artifact. Store the diagram beside the feature spec it belongs to, link it from the relevant user stories, and a reader always has the wide view and the detail one click apart.

FAQ

What are the 4 major elements of a use case diagram?

The four core elements are actors, use cases, the system boundary, and relationships. Actors are the roles that interact with the system, use cases are the goals it delivers, the boundary marks what is in scope, and relationships like associations, include, and extend connect the pieces.

What is a use case diagram?

A use case diagram is a UML behavioral diagram that shows how actors interact with a system to achieve goals. It gives a high-level, outside-in view of what the software does and who uses it, making it a fast way to scope features and align stakeholders on requirements.

How do you make a simple use case diagram?

Draw a rectangle for the system boundary, add stick-figure actors outside it, and place ovals inside for each goal an actor pursues. Connect actors to their goals with lines. Add include or extend arrows only where behavior is shared or optional, then review with stakeholders.

Is a use case diagram the same as UML?

No. UML is the full modeling language with fourteen diagram types. A use case diagram is one of those types, specifically a behavioral diagram. So every use case diagram is UML, but UML also covers class diagrams, sequence diagrams, activity diagrams, and many others.