Use case diagrams are like blueprints for your system—mess them up, and you’ll pay for it later in confused stakeholders, missed requirements, and rework. But even experienced teams fall into traps that turn these diagrams from clarity into chaos.
Here’s what goes wrong, why it matters, and how to fix it—with real examples you won’t find in textbook UML guides.
1. The “Kitchen Sink” Diagram
The Mistake: Trying to cram every actor, use case, and edge case into one sprawling diagram.
Why It Backfires:
- Developers glaze over trying to trace spaghetti-like connections.
- Stakeholders miss critical interactions buried in the noise.
Fix: Slice by scope or user role.
- Example: A hotel booking system should have separate diagrams for:
- Guest-facing flows (Search Rooms, Book Stay)
- Staff workflows (Check-In Guest, Process Payment)
- Backend integrations (Sync with PMS, Update Inventory)
2. The Phantom Actor Problem
The Mistake: Forgetting key players who interact with the system.
Real-World Consequences:
- No one modeled the Tax Calculation Service in an e-commerce system? Enjoy manual refunds at year-end.
- Missing Maintenance Crew in a smart building app? Alarms won’t trigger repairs.
Fix: Run the “Who Else?” test
- For every actor (e.g., “Customer”), ask:
- Who helps them? (Live Chat Agent)
- What systems do they depend on? (FedEx API for shipping)
3. Vague Connections That Confuse Teams
The Mistake: Lines between actors and use cases that leave room for interpretation.
Example of Disaster:
- A diagram shows “Manager” → “Approve Request” but doesn’t clarify:
- Can managers also submit requests?
- Is this for PTO requests, budget approvals, or both?
Fix: Verb-driven use case names
- Bad: “Handle Request”
- Good: “Approve Budget Increase”, “Reject Vacation Submission”
4. “Include/Extend” Mayhem
The Classic Confusion:
- Include = “Always happens” (like Verify Payment during Place Order)
- Extend = “Only sometimes” (like Add Gift Note during checkout)
How Teams Screw It Up:
- Using extend for core flows (e.g., making User Login optional)
- Overusing includes until the diagram looks like a dependency graph
Fix: The “Mandatory vs. Bonus” Rule
- Ask: “If we skip this, does the use case break?”
- Yes? → Include (e.g., authentication)
- No? → Extend (e.g., expedited shipping option)
5. Ignoring the Machines
The Blind Spot: Only drawing human actors while systems do the heavy lifting.
Costly Oversights:
- Not showing Weather API as an actor for a drone delivery system → surprise delays when integrations fail.
- Omitting Legacy Database in a bank’s use case diagram → missed migration costs.
Fix: Treat external systems as VIPs
- Example: In a food delivery app:
- Human actors: Customer, Driver
- Non-human: Route Optimization Engine, POS System
6. Inconsistency Chaos
The Symptom:
- Admin in one diagram, System Administrator in another
- Some use cases in bold, others italicized for no reason
Why It Hurts:
- Developers waste time reconciling discrepancies.
- QA misses test cases because naming isn’t traceable.
Fix: Enforce a style guide
- Actor naming: Stick to roles (Customer, not User or Client)
- Formatting: Always underline use cases or always use PascalCase—pick one.
7. Zombie Use Cases
The Deadwood: Redundant or obsolete use cases that linger from old drafts.
Example:
- “Fax Confirmation” in a modern SaaS product
- Both “Email Receipt” and “Send Invoice” doing the same job
Fix: Prune ruthlessly before reviews
- Merge duplicates (e.g., Upload Photo + Add Profile Picture → Manage Profile Media)
- Kill deprecated features (no, your app doesn’t need “Dial Modem”)
The Golden Rule: Diagrams Are Conversations, Not Relics
The best use case diagrams evolve. They’re whiteboard sketches that get refined as you:
- Test with users (e.g., realizing “Apply Coupon” needs to extend both Checkout and Subscription Renewal)
- Pressure-test edge cases (What happens when the Payment Gateway actor is down?)
Pro Tip: Pair diagrams with user stories for context:
“As a guest, I want to book a room so I can reserve my dates—but only if the Property Management System confirms availability.”
Final Thought: Avoid Perfection Paralysis
Use case diagrams aren’t museum pieces. They’re tools to:
✅ Align teams
✅ Expose gaps early
✅ Prevent “But I thought…” disasters
A messy-but-useful diagram that sparks the right debates beats a “correct” one that sits unused in Confluence. Now go fix that tangled diagram before the next sprint planning!