The Basics of Use Case Diagrams Explained

Start with the end in mind—not the technical details. When I first worked on a healthcare portal, the team spent days arguing about features. We weren’t modeling what users actually did; we were guessing. That’s when I learned: use case diagrams aren’t about complexity. They’re about clarity.

They serve as the first visual language of requirements. Not every system needs a class diagram at the start. But every system needs to answer: What can the user do? That’s what a UML use case diagram captures.

By the end of this chapter, you’ll know how to define actors, model key scenarios, and draw a clean, actionable use case diagram—no prior modeling experience needed. You’ll see why this is the most practical starting point for beginners.

What Is Use Case in UML?

Use cases describe a specific interaction between a user (or external system) and the software to achieve a goal.

Unlike class diagrams that focus on structure, use cases focus on behavior from the user’s perspective.

Think of it like a step-by-step recipe: the user performs actions, the system responds, and a valuable outcome is achieved.

Key Elements of a Use Case Diagram

• Actor: A role played by a user or external system that interacts with the system.
• Use Case: A function or activity the system performs for the actor.
• System Boundary: A rectangle that defines the system’s scope. Everything inside is part of the software.
• Relationships: Lines that connect actors to use cases or use cases to each other.

These components work together to answer: Who uses the system? What do they want to do? Is it within the system’s scope?

Why Use Case Diagrams Matter for Requirements

They’re not just for documentation. They’re a conversation starter.

When I led requirements workshops, I always started with a blank whiteboard and a simple use case diagram. The result? Developers stopped asking “What does this mean?” and users stopped saying “That’s not what I meant.”

The real power lies in simplifying ambiguity. A well-drawn use case diagram makes it easy to spot missing features or overly broad goals.

When to Use a Use Case Diagram

• During initial discovery with stakeholders.
• Before writing user stories or planning sprints.
• To validate that the system covers all user goals.
• When onboarding new team members to the system’s functions.

It’s the blueprint before the blueprint. You’re not modeling code yet—you’re modeling intent.

How to Build Your First Use Case Diagram

Start simple. Don’t rush into complex relationships. Begin with the system boundary and one to three core use cases.

Step-by-Step Process

1. Identify the system: Define what the software does. For example, “Online Shopping System”.
2. Draw the system boundary: A rectangle around the future use cases.
3. Identify actors: Who uses the system? Customers, admins, payment gateways.
4. Define use cases: What goals do they have? “Browse products”, “Place order”, “View order history”.
5. Draw relationships: Connect actors to relevant use cases with lines.
6. Review scope: Ensure all major user goals are included. Remove anything outside the boundary.

Don’t overthink it. A basic diagram is better than no diagram. You can refine it later.

Example: Online Shopping Use Case Diagram

Imagine a small online shop. Here’s how the diagram starts:

• Actor: Customer
• Use Cases:
  • View products
  • Add item to cart
  • Checkout
  • View order history
• System Boundary: Rectangle enclosing all use cases.
• Relationships: Customer connected to each use case.

This basic view already reveals gaps. What about returns? Payments? Now you know where to focus next.

Advanced Relationships: Extend and Include

Once the core diagram is solid, you can add complexity with two key relationships.

Include (<>)

Used when one use case always includes the behavior of another.

Example: “Checkout” <> “Validate payment details”.

Draw a dashed line with an open arrow, labeled with <>.

This isn’t optional. It’s required for the primary use case to work.

Extend (<>)

Used when one use case conditionally adds extra steps.

Example: “Place order” <> “Apply discount code”.

Draw a dashed line with an open arrow from the extending use case, labeled <>.

Use a note to specify the condition: “Only if user has a valid code”.

These aren’t just notation—they’re tools to avoid duplication and keep your model lean.

When to Use Include vs Extend

Use Case	When to Use	Example
Include	Required functionality	“Login” <> “Verify credentials”
Extend	Optional or conditional behavior	“Purchase” <> “Apply gift card”

Confusion here often leads to clutter. Stick to one rule: if the behavior is mandatory, use include. If it’s optional, use extend.

Best Practices for Use Case Diagrams

Accuracy and clarity are more important than complexity.

• Use verbs in use case names: “Place order”, not “Order placement”.
• Keep use cases at a single level: Don’t break “Check out” into “Enter shipping info”, “Enter payment”, etc., in the diagram. Save that for sequence diagrams.
• Limit the number of use cases: 5–8 is ideal. More than that, and you’re modeling implementation, not requirements.
• Group related use cases: Use packages or note them. Helps with readability.
• Validate with stakeholders: Show the diagram to users. If they don’t recognize a goal, it’s not clear enough.

Remember: this isn’t a design document. It’s a shared understanding tool.

Common Pitfalls to Avoid

• Confusing actors with roles: An actor is a user or system, not a job title. “Manager” is a role. “Warehouse Supervisor” is a user.
• Overloading use cases: “Manage customer and product data” is too broad. Split into “View customer list” and “Update product inventory”.
• Ignoring system boundary: Use cases outside the boundary are not part of the system—either move them in or remove them.
• Using too many relationships: A diagram with 15+ connections becomes unreadable. Use packages or separate diagrams for large systems.

Beginners often try to capture everything. Resist that urge. Focus on the user’s goal, not the internal steps.

Frequently Asked Questions

What is use case in UML for beginners?

A use case in UML represents a specific task or goal a user can achieve with the system. It’s written in active voice and describes what the system does from the user’s point of view. For example, “Place order” or “View account details”.

How do I know if a use case is too detailed?

If a use case name includes verbs like “enter”, “click”, or “select”, it’s likely too detailed. Use cases should describe a goal, not a sequence of steps. For instance, “Add item to cart” is fine; “Click Add button in product view” is too low-level.

Can I use a use case diagram for a mobile app?

Absolutely. Use case diagrams work for any system where users interact with software. They’re especially helpful for mobile apps because they clarify user journeys—like “Check in”, “Update profile”, or “Receive notification”.

Should I include technical components in a use case diagram?

No. Use cases focus on user goals, not backend systems. Don’t add “Database”, “API”, or “Server” as actors or use cases. Save those for class or component diagrams.

Is it okay to have multiple actors?

Yes. Different roles (e.g., “Customer”, “Admin”, “Payment Gateway”) can all be actors. Each represents a different type of user or system interacting with the software.

How do I prioritize use cases?

Rank them by frequency, business value, or risk. Use case diagrams don’t force this, but you can annotate use cases with priority labels (e.g., H for high, M for medium). This helps teams focus on what matters most during development.

Use case diagrams are not the end. They’re the starting point for deeper modeling. Next, you’ll link them to sequence diagrams to explore how the system behaves step by step.

Master the basics, and you’ll be able to communicate requirements with confidence—no matter what system you’re building.

Remember: clarity beats completeness. A simple, accurate use case diagram is more valuable than a complex one that confuses everyone.