Use Case

A use case is a description of how an actor, usually a user or another system, interacts with a system to achieve a specific goal. It walks through the steps when everything goes well and the alternative paths when something goes differently, so stakeholders and the team agree on the system's behavior before it is built.

How Use Cases Work

The BABOK Guide defines a use case as a description of the observable interaction between an actor and a solution when the actor uses it to accomplish a goal. Alistair Cockburn, whose book Writing Effective Use Cases (2001) shaped modern practice, describes a use case as a contract between the stakeholders of a system about its behavior.

A fully written use case in Cockburn's style has these parts:

• Primary actor: the stakeholder who starts the interaction to reach a goal.
• Scope: the system under discussion.
• Preconditions and guarantees: what must be true before the use case runs and what the system promises afterward, including when it fails.
• Main success scenario: the numbered steps in which nothing goes wrong. Cockburn suggests 3 to 9 steps.
• Extensions: each condition that can occur at a given step, numbered against that step (for example 4a), and how the system handles it.

Use cases are fundamentally text. A UML use case diagram only shows actors and use case names as a map; the behavior lives in the written scenarios. Cockburn also advises describing the actor's intention rather than interface details, so "User enters payment details" rather than "User clicks the blue button".

Why Use Cases Matter

The extension list forces a team to think through failures and alternatives, so edge cases surface early instead of in testing. Use cases also present functional requirements in context, as one goal-driven story, rather than as a loose list. They suit complex flows with several actors, integrations or regulated steps, and they are readable by business stakeholders and testers alike. Each scenario path maps naturally to a test case.

Use Case Example

Use case: Withdraw cash. Primary actor: account holder. Precondition: a valid card is inserted.

Main success scenario:

1. Account holder enters their PIN.
2. System verifies the PIN.
3. Account holder selects an amount.
4. System confirms the balance and that the machine holds enough cash.
5. System dispenses the cash, debits the account and returns the card.

Extensions:

• 2a. PIN is wrong: the system asks again; after three failures it keeps the card.
• 4a. Insufficient funds: the system shows the available balance and asks for a lower amount.

Use Case vs. User Story

The two work together. One use case often splits into several user stories: one for the main path and others for the extensions worth building first.