What Is a Use Case? Definition, Structure & How to Write One

A use case is a description of how a user (or another system) interacts with a product to accomplish a specific goal. It defines the sequence of actions and system responses that make up a particular interaction — from the user’s initial trigger to the final outcome. Use cases are a requirements engineering technique that makes user-system interactions explicit, helping product and engineering teams align on what the product needs to do and how.

A use case is not a list of features. It’s a scenario — a story of user intent and system behavior that, when complete, delivers meaningful value to the user.

The Anatomy of a Use Case

Use Case Name

A clear, verb-noun label that describes the goal being achieved. Examples: “Submit Expense Report,” “Search for Products,” “Reset Password.”

Actor

The entity initiating the use case — typically a user type or persona (“Registered Customer,” “Admin User,” “External System”). Identifying the actor ensures the use case is designed from the right perspective.

Preconditions

The state the system must be in before the use case can begin. For example: “User is logged in” or “Payment method has been saved.”

Main Success Scenario (Happy Path)

The step-by-step sequence of actions and system responses that occur when everything goes as expected. Written as a numbered list of alternating user actions and system responses.

Example — Reset Password:

1. User navigates to the login screen and clicks “Forgot Password”
2. System displays a password reset form
3. User enters their registered email address and submits
4. System sends a password reset link to the provided email
5. User clicks the link within 24 hours
6. System displays a form to enter a new password
7. User enters and confirms a new password meeting complexity requirements
8. System updates the password and redirects the user to the login screen

Alternative Flows

Variations from the main scenario that still result in a successful outcome. For example, a user who enters an email not associated with any account — the system sends a generic “if an account exists” response to prevent account enumeration.

Exception Flows (Error Scenarios)

What happens when something goes wrong. The link has expired. The new password doesn’t meet complexity requirements. The server is unavailable. Each exception should be explicitly described with the system’s response.

Postconditions

The state the system is in after the use case completes successfully.

Use Cases vs. User Stories

Both describe user-product interactions, but at different levels of detail and formality:

	Use Case	User Story
Format	Structured narrative with flows and exceptions	Brief description (“As a [user], I want to [action] so that [outcome]”)
Detail level	High — includes alternatives and exceptions	Low — focuses on the desired outcome
Best for	Complex interactions requiring precise specification	Agile backlog items representing single units of value

User stories and use cases often coexist: a user story captures the high-level intent; use cases provide the detailed specification for complex stories that require it.

When to Write Use Cases

Use cases are most valuable when:

• Interactions are complex — Multiple paths, exception handling, and system states require explicit documentation
• Compliance or certification requires specification — Regulated industries often require formal use case documentation
• Multiple teams need shared specification — Use cases serve as a contract between product, design, and engineering
• Existing behavior needs to be documented — For legacy systems where institutional knowledge is at risk

Key Takeaways

Use cases transform vague product goals into precise, testable descriptions of user-system interaction. They surface edge cases and exception paths that informal requirements miss, create shared understanding across teams, and provide the basis for test cases that validate that the system actually does what was specified. For complex interactions, they remain one of the most effective tools in requirements engineering.