Use Cases Explained

What Is a Use Case?

A use case is a detailed description of how an actor (any entity — a person, system, or device) interacts with a system to achieve a specific goal. Where user stories capture intent in a sentence, use cases capture behavior across an entire interaction flow including alternative paths and error conditions.

Use cases were formalized by Ivar Jacobson in the early 1990s and became a cornerstone of the Unified Modeling Language (UML). They are particularly valuable for complex features with multiple paths, regulatory requirements, and systems integration.

User Stories vs Use Cases

Use stories when you need lightweight, conversation-starting descriptions. Use use cases when you need comprehensive, unambiguous documentation — especially for regulatory compliance, complex multi-step processes, or when handing off to external teams.

Core Use Case Elements

Actor: Any entity that interacts with the system to achieve a goal. Primary actors initiate use cases (users, external systems). Secondary actors are called upon by the system (payment gateway, email service).

System: The boundary of what you are building. Everything inside the boundary is what your code controls. Everything outside is an actor.

Goal: What the primary actor wants to accomplish. Should be a meaningful business result ("place an order") not a technical step ("click the submit button").

Preconditions: What must be true before the use case can begin. "User is registered." "Shopping cart has at least one item."

Postconditions: The state of the system after the use case completes successfully. "Order is stored in the database." "Confirmation email is queued."

Main Success Scenario: The numbered happy-path steps that lead from the precondition to the postcondition. No errors, no alternatives — just the most common successful path.

Extensions: Branches from the main scenario that handle alternatives and errors. Labeled with the step they branch from (e.g., 3a, 3b, 5a).

Complete Example: User Logs In

Use Case: User Authenticates with Email and Password

*Actor:* Registered User

*Goal:* Gain access to their account and protected content

*Preconditions:*

• User has a registered account with a verified email
• User is not currently logged in

*Postconditions:*

• User has an active session
• User is redirected to their dashboard

*Main Success Scenario:*

1. User navigates to the login page
2. User enters their email address
3. User enters their password
4. User clicks "Log In"
5. System validates credentials against stored hash
6. System creates a session token with a 24-hour expiry
7. System redirects user to their dashboard

*Extensions:*

• 2a. Email format is invalid: system shows inline error "Please enter a valid email address"
• 5a. Email not found: system shows "Invalid email or password" (deliberately vague for security)
• 5b. Password does not match: system shows "Invalid email or password"
• 5c. Account is locked (5 failed attempts): system shows "Account locked. Check your email for reset instructions." and sends reset email
• 5d. Account is not verified: system shows "Please verify your email before logging in" with resend option

When to Use Each

Stories only: Simple CRUD features, single-path interactions, features where the happy path is 95% of usage.

Both: Complex multi-path features, payment flows, user account management, anything with explicit error handling requirements.

Use cases mandatory: Healthcare data handling, financial transactions, legal compliance workflows, integrations with external regulated systems.

Key Takeaways

• Use cases document complete system behavior including all alternative and error paths
• The main success scenario is the numbered happy path — no alternatives
• Extensions handle everything that deviates from the main path, labeled by step number
• Use stories for simple features, use cases for complex multi-path or compliance-required features
• Both tools together give you intent (story) and behavior (use case) — they are complementary