Use Cases - Guide
development project-management use-cases requirements
What is a Use Case?
A use case describes a specific way an actor (user or system) interacts with software to achieve a goal. It captures what a system should do from the outside — the full interaction flow, including what happens when things go right and when they go wrong.
Use cases are a requirements technique — they help you understand, document, and communicate what needs to be built before you build it.
Core Components
| Component | What It Defines | Example |
|---|---|---|
| Actor | Who or what initiates the interaction | User, Admin, External API, Scheduled Job |
| Goal | What the actor wants to accomplish | Reset their password |
| Preconditions | What must be true before the use case starts | User has a registered account |
| Main Flow | The step-by-step happy path (everything goes right) | Click “forgot password” → enter email → receive link → set new password |
| Alternate Flows | Variations that still succeed | User enters username instead of email |
| Exception Flows | What happens when things go wrong | Email not found, link expired, password doesn’t meet requirements |
| Postconditions | What’s true after the use case completes | Password is updated, user is logged in |
Use Case vs User Story
Both capture requirements, but at different levels of detail:
| User Story | Use Case | |
|---|---|---|
| Format | ”As a [user], I want [goal], so that [reason]“ | Structured document with flows and conditions |
| Detail | One sentence + acceptance criteria | Full interaction flow with branches |
| Formality | Informal, conversational | Semi-formal to formal |
| Audience | Developers, sprint planning | Developers, testers, stakeholders, auditors |
| Scope | Single feature or behavior | Complete interaction from start to finish |
| When to use | Agile sprints, quick planning | Complex features, compliance, thorough documentation |
They complement each other. User stories are great for planning and prioritization. Use cases flesh out the details when you need to understand the full picture — edge cases, error handling, and alternate paths.
Types of Use Cases
By Detail Level
| Level | Description | When to Use |
|---|---|---|
| Brief | A few sentences summarizing the interaction | Quick standup discussions, early brainstorming |
| Casual | Multiple paragraphs covering main and alternate flows loosely | Team discussions, internal documentation |
| Fully Dressed | Formal document with all components (preconditions, postconditions, triggers, exceptions, etc.) | Compliance, audit requirements, complex features, handoffs |
By Scope
| Scope | Description | Example |
|---|---|---|
| System Use Case | Interaction with a specific system | ”User logs into the firewall management portal” |
| Business Use Case | Business process that may span multiple systems | ”Onboard a new employee’s network access across all platforms” |
By Actor Type
| Actor | Description | Example |
|---|---|---|
| User-Driven | Initiated by a human | Admin configures a firewall rule |
| System-Driven | Initiated by another system or automated process | IDS detects a threat and triggers a block rule |
By Purpose
| Purpose | Description | Example |
|---|---|---|
| Functional | What the system does | Authenticate user, push a config, export a report |
| Non-Functional | How the system performs | Must respond within 2 seconds, must handle 500 concurrent sessions |
Writing a Use Case
Brief Format
Reset Password: A registered user requests a password reset. The system sends a reset link to their email. The user clicks the link and enters a new password. The system validates the password and updates the account.
Casual Format
Use Case: Reset Password
Main Flow:
- User clicks “Forgot Password” on the login page
- User enters their email address
- System verifies the email exists
- System sends a reset link (valid for 24 hours)
- User clicks the link in their email
- User enters and confirms a new password
- System validates the password meets requirements
- System updates the password and logs the user in
Alternate Flows:
- Step 3: If email not found, show generic “If an account exists, a link was sent” message (don’t reveal whether the email exists)
- Step 6: User can request a new link if the first one expired
Exceptions:
- Step 4: Email delivery fails — log error, display “try again later”
- Step 7: Password doesn’t meet requirements — show specific validation errors
Fully Dressed Use Case Template
# Use Case: [Name]
**ID:** UC-001
**Actor(s):** [Primary actor, secondary actors]
**Trigger:** [What initiates this use case]
**Priority:** [High / Medium / Low]
## Preconditions
- [What must be true before this starts]
## Main Success Flow
1. [Step 1]
2. [Step 2]
3. [Step 3]
4. [Step 4]
## Alternate Flows
- **2a.** [Variation at step 2]
1. [Alternate step]
2. [Return to main flow at step X]
## Exception Flows
- **3a.** [Error condition at step 3]
1. [Error handling]
2. [Use case ends / retries]
## Postconditions
- **Success:** [What's true after happy path]
- **Failure:** [What's true after exception]
## Business Rules
- [Rule 1: e.g., "Password must be at least 12 characters"]
- [Rule 2: e.g., "Reset link expires after 24 hours"]
## Notes
- [Additional context, assumptions, open questions]When to Use Use Cases
| Purpose | How Use Cases Help |
|---|---|
| Gathering requirements | Forces you to think through the full interaction, not just the happy path |
| Guiding test cases | Each flow (main, alternate, exception) maps directly to a test scenario |
| Stakeholder alignment | Non-technical people can read and validate: “Yes, that’s how it should work” |
| Scoping features | Reveals hidden complexity — alternate and exception flows often surface work you didn’t plan for |
| Estimating work | More flows = more complexity = more effort. Helps avoid underestimation. |
| Compliance / audit | Formal documentation trail showing what the system is designed to do |
When NOT to Write Full Use Cases
- Simple CRUD operations — a user story with acceptance criteria is enough
- Internal utilities — if the audience is just you, a brief format suffices
- Early exploration — don’t over-document before you’ve validated the idea (see Project Planning - PRDs and Requirements)
Practical Tip
Start brief, go casual when the team needs clarity, and go fully dressed only when the situation demands it (compliance, complex multi-system flows, or handoffs to other teams). Most features land somewhere in the casual range.