Use case modeling is one of the most powerful weapons against scope creep—when done correctly. A well-constructed use case model creates an explicit, visual, and binding contract between stakeholders and the development team about what the system will actually do.
This guide will walk you through the key concepts, practical guidelines, and real-world examples to transform use case modeling from a bureaucratic exercise into your project's primary defense against uncontrolled expansion.
Scope creep thrives in ambiguity. Use case modeling eliminates ambiguity by forcing stakeholders to answer three brutal questions upfront:
Who is using the system?
What specific goal are they trying to achieve?
What happens when things go wrong?
When these are documented visually and textually, every future "quick addition" must be measured against the existing model. If it isn't in a use case, it isn't in scope.
An actor is anyone or anything that interacts with your system to achieve a goal.
| Type | Definition | Example |
|---|---|---|
| Primary Actor | The one who initiates the use case to achieve a goal. | Customer (placing an order) |
| Secondary Actor | A system or person that the system interacts with to fulfill the goal. | Payment Gateway, Warehouse System |
| Supporting Actor | Helps the system but doesn't initiate anything. | System Administrator (setting up user permissions) |
⚠️ Scope Creep Trap: Vague actors like "User" or "Stakeholder." If you don't know exactly who is doing something, you will inevitably build features for imaginary users. Always name specific roles (e.g., "Registered Customer," "Store Manager," not just "User").
A use case is a specific, discrete unit of work that provides a measurable outcome of value to the actor.
The Golden Rule: A use case must represent a complete business goal, not just a single step.
| ❌ Bad (Step) | ✅ Good (Goal) |
|---|---|
| "Enter Password" | "Authenticate User Identity" |
| "Click Submit" | "Submit Order for Processing" |
| "Validate Credit Card Number" | "Process Payment" |
Every robust use case has three mandatory parts:
Basic Flow (Happy Path): The ideal sequence of steps when everything works perfectly.
Alternative Flows: Valid variations of the basic flow (e.g., "User pays with PayPal instead of Credit Card").
Exception Flows: What happens when things break (e.g., "Credit card is declined," "Network timeout").
⚠️ Scope Creep Trap: Documenting only the happy path. When surprises happen in development (and they always do), developers invent solutions on the fly, creating uncontrolled scope expansion. Pre-defining exceptions kills this.
These are your scope fences.
Precondition: What must be true before the use case can start? (e.g., "User is logged in.")
Postcondition: What must be true after the use case successfully finishes? (e.g., "Order is stored in the database with status 'PENDING'.")
If a stakeholder asks for a new feature that changes a postcondition, you can immediately flag it as a scope change.
Before writing a single use case, draw a large rectangle. That rectangle is your system. Everything inside is your responsibility. Everything outside is out of scope.
The Exercise: Sit with stakeholders and physically place features inside or outside the box. If something is outside, it becomes an "external system" that your system merely integrates with—not builds.
Example:
Inside: "Process payments," "Manage user profiles."
Outside: "Calculate shipping costs via FedEx API" (Your system just calls the API; you don't build the calculator).
Use Cockburn's Goal Level framework:
Sea Level (User Goal): The primary use cases. A single actor completes a single goal in one sitting. (e.g., "Withdraw Cash").
Kite Level (Summary): Higher-level business processes that span multiple use cases. (e.g., "Manage ATM Operations").
Fish Level (Subfunction): Low-level, reusable steps that are not complete goals. (e.g., "Validate PIN").
Rule: Write only Sea Level use cases for your initial scope. If you dive to Fish Level too early, stakeholders will treat every micro-step as a feature request, massively inflating scope.
For every use case you write, ask: "Can a primary actor achieve this goal in under 2 hours (in a single session)?"
If it takes longer, it is likely multiple use cases stuck together. Break it apart.
If it takes 2 minutes, you are probably writing a subfunction. Roll it up into a larger goal.
Why this prevents creep: It prevents stakeholders from bundling a massive project feature (like "Manage Entire Supply Chain") into a single use case. By breaking it down, you can prioritize and de-scope individual pieces.
Within each use case description, create a dedicated section called "Stretch Goals" or "Out of Scope for v1.0."
When a stakeholder suggests a new exception flow (e.g., "What if the user wants to split payment across two cards?"), do not delete it. Document it clearly in the "Out of Scope" section and label it for "Future Release."
Psychological trick: Stakeholders calm down when they see their idea is written down and not forgotten. They will accept delaying it if it's on the roadmap.
Link every single use case to a specific business requirement in a Requirements Traceability Matrix (RTM).
| Requirement ID | Business Need | Use Case(s) | Status |
|---|---|---|---|
| REQ-101 | Users must log in | UC-01: Authenticate User | Approved |
| REQ-102 | Users must reset passwords | UC-02: Recover Credentials | Approved |
| (New) REQ-103 | Users must log in via Google | (No linked UC) | Rejected/Change Request |
If a new requirement doesn't map back to an existing, approved use case, it is automatically scope creep and triggers the formal change control process.
Use Case: "Checkout"
Actor: User
Flow: User adds items and pays.
Why it fails: "Pays" is completely open-ended. The stakeholder will ask for PayPal, Apple Pay, Klarna, gift cards, and store credit mid-development.
Use Case ID: UC-07
Name: Complete Purchase
Primary Actor: Registered Customer
Precondition: Customer has at least one item in the shopping cart.
Postcondition: Order is created with status "PAID" and inventory is reserved.
Basic Flow:
Customer initiates checkout.
System displays order summary with total cost.
Customer selects Credit Card as payment method.
Customer enters card details.
System validates card format.
System submits charge to External Payment Gateway.
Gateway returns "SUCCESS."
System creates the order and displays confirmation number.
Alternative Flows:
Customer selects PayPal → Redirect to PayPal, return to step 7.
Exception Flows:
Invalid card format → Display error, return to step 4.
Gateway returns "DECLINED" → Display "Insufficient funds" message, return to step 3.
Gateway times out after 10 seconds → Display "Payment processing error," do NOT create order.
📌 Out of Scope (v1.0):
Splitting payments across multiple cards.
Using store gift cards.
"Buy Now, Pay Later" options.
Saving credit cards for future use.
Result: When a stakeholder asks for "Saving credit cards" mid-sprint, the project manager points to the "Out of Scope" section and says, "That will cost an additional 2 weeks—shall we file a change request?"
Use Case: "Onboard New Employee"
Actor: HR Manager
Flow: Enter employee details and send IT ticket.
The Creep: Mid-project, IT says, "We also need to order a laptop based on their department." Finance says, "We need to add them to payroll." Suddenly, scope triples.
Instead of one giant use case, break it into distinct goals:
UC-10: Register Employee Profile (HR enters name, address, role).
UC-11: Assign Role-Based Permissions (System auto-assigns software access).
UC-12: Initiate Equipment Procurement (System creates a ticket for IT).
The Inclusion Relationship (<>):
UC-10 includes UC-11 automatically (you can't register without setting permissions).
The Extend Relationship (<>):
UC-10 extends to UC-12 only if the employee's role requires hardware (e.g., "Engineer" gets a laptop; "Intern" does not).
Why this prevents creep: It isolates responsibilities. Finance cannot hijack UC-10 to add payroll because "Payroll Setup" is an entirely separate use case that sits outside the HR system's scope. Finance would need a new use case, which equals a new budget.
The Stakeholder Request: "Can we add facial recognition login?"
Without Use Case Model: "Sure, it's just a quick API integration." (Spoiler: It takes 3 weeks.)
With Use Case Model: The PM pulls up UC-03: Authenticate User. The existing flows are:
Flow A: PIN entry.
Flow B: Fingerprint.
The PM says: "Facial recognition is a new Alternative Flow for UC-03. According to our change control, adding a new flow requires a formal impact analysis. We estimate 3 weeks and $5,000. Do you want to delay the 'Bill Pay' feature to accommodate this, or do we file it for v2.0?"
The stakeholder chooses v2.0. Scope creep successfully avoided.
Never allow synonyms. If you call it "Customer" in one use case and "User" in another, stakeholders will assume they are different entities and demand new features for both. Create a Glossary of Terms attached to your use case model.
Group use cases into three priority buckets (using the MoSCoW method):
Must-Have: The system cannot launch without these.
Should-Have: Important but can be worked around.
Could-Have: Nice-to-haves for v1.0.
Won't-Have (this cycle): Explicitly excluded.
When scope creep knocks, ask: "Which Must-Have use case are we deprioritizing to make room for this?"
If a new use case is requested, it must sit in a "Backlog" folder for two full weeks before it can be discussed at a formal change board meeting.
Why this works: 80% of new feature requests lose their urgency after 14 days. Stakeholders realize they can live without it, or they gather more data to prove it is essential (which makes it a formal Scope Change, not creep).
Always create a Use Case Diagram (the simple stick-figure and oval diagram).
Keep it to 5–10 ovals maximum for v1.0.
Rule: If a diagram has more than 10 use cases, you are looking at a multi-phase project. Break the diagram into "Release 1" and "Release 2" swimlanes.
Before you show your model to a stakeholder, run through this checklist:
Are all actors named with specific job titles (not generic "Users")?
Does every use case represent a complete, measurable business goal?
Have I documented at least 2 exception flows for every basic flow?
Is the system boundary clearly drawn and scoped?
Is there a dedicated "Out of Scope for v1.0" section for each major use case?
Does every use case have a clear precondition and postcondition?
Does every requirement trace back to at least one use case?
Have I secured stakeholder sign-off on the model before development starts?
Use case modeling doesn't just prevent scope creep—it changes the conversation with stakeholders. Instead of asking, "Can you build this?" they start asking, "Which use case does this belong to, and how does it affect our timeline?"
That shift—from passive receiver of requests to active guardian of the scope—is the ultimate victory of good use case modeling.
