A use case describes a complete interaction between a user (called an "actor") and a system, aimed at achieving a specific goal. Where a flowchart shows a business process, a use case zooms into one goal and describes every way it can play out — the success path, the alternatives, and the failures.
The key parts of a use case
- Actor — who is trying to achieve the goal. Be specific: not "user" but "registered customer" or "branch manager."
- Goal — what the actor wants to accomplish, stated as an outcome. "Withdraw cash," "Submit a leave request."
- Preconditions — what must be true before the use case can start. "The customer is logged in."
- Main success scenario — the step-by-step happy path where everything goes right.
- Alternative flows — other valid ways the goal can be reached.
- Exception flows — what happens when something goes wrong. This is where use cases earn their value.
- Postconditions — what is true after the use case completes successfully.
The power of a use case is in the exceptions. Anyone can describe what happens when things go right. The use case forces you to think through what happens when the card is declined, the network drops, or the data is missing — exactly the situations where poorly-specified systems fail.
Use case vs user story — which to use
Both describe what a user needs, but at different levels of detail:
- A user story is short and lightweight: "As a customer, I want to reset my password so I can regain access." It is a placeholder for a conversation, used in agile teams.
- A use case is detailed and comprehensive, spelling out every flow and exception. It is used when the interaction is complex or when precise specification matters, such as in regulated industries.
Use a user story when the feature is simple and the team will fill in detail through conversation. Use a use case when the interaction is complex, high-risk, or must be documented precisely.
Use case in miniature
Actor: Registered customer · Goal: Withdraw cash · Precondition: Logged in with sufficient balance.Main path: Customer selects amount → system checks balance → dispenses cash → updates balance → prints receipt.
Exception: Insufficient balance → system shows message → offers a lower amount → returns to amount selection.
Practice pointer: for any feature, write the happy path first, then ask "what could go wrong at each step?" Each answer becomes an exception flow. This single habit dramatically improves the quality of your specifications.