How to Write a Use Case

A use case describes how a person or another system interacts with a product to achieve a specific goal. It turns a vague requirement such as “customers need to reset passwords” into a sequence that designers, developers, testers, stakeholders, and support teams can understand and verify.

A useful use case is not a screen design and not a list of technical tasks. It focuses on observable behavior: who wants something, what starts the interaction, what the system must do, what can go wrong, and what successful completion looks like.

Quick Answer

To write a use case, define one user goal, identify the primary actor, name the trigger, list preconditions, write the normal success path as numbered actor-and-system steps, add alternative and exception flows, define postconditions, connect the use case to business rules, and review it with users and delivery teams. Keep each step testable and avoid interface detail unless the interface itself is a requirement.

Step 1: Choose One Goal

Start with a goal that produces meaningful value for an actor. Good names use a verb and an object, such as “Submit Expense Claim,” “Schedule Appointment,” “Approve Purchase Order,” or “Reset Password.” Avoid broad names such as “Manage Customers,” which usually contain several independent goals.

If the use case cannot be completed in one recognizable interaction or transaction, split it. “Manage Account” might become Create Account, Update Profile, Change Password, Close Account, and Download Data.

Step 2: Identify the Actors

The primary actor initiates the use case to achieve the goal. Supporting actors may provide data, payment authorization, identity verification, notifications, or other services. Actors are roles, not individual names. “Customer” is an actor; “Sarah” usually is not.

Ask which actor receives the value and which external systems participate. A payment use case might involve the customer, payment gateway, fraud service, inventory service, and email provider, but the customer remains the primary actor.

Step 3: Write the Scope and Level

State the system boundary. Is the use case about the website, mobile app, internal platform, or an end-to-end business process? Also define whether it is a high-level business use case or a detailed system use case. Mixing levels causes confusion.

A business use case may say “The business verifies the claim.” A system use case should explain the required system behavior while leaving internal implementation choices to the technical design.

Step 4: Define the Trigger

The trigger is the event that starts the use case. Examples include a user selecting “Check Out,” a scheduled billing date arriving, a sensor reporting a threshold, or another system submitting a request.

Write one clear trigger. Do not confuse it with a precondition. “The customer has items in the cart” is a precondition; “The customer chooses Checkout” is the trigger.

Step 5: List Preconditions

Preconditions describe what must already be true before the interaction begins. Include only conditions the use case does not establish itself. Examples include:

• The user is authenticated.
• The account is active.
• The order contains at least one available item.
• The external payment service is configured.

Do not turn preconditions into a hidden requirements list. If authentication is optional or part of the interaction, describe it in the flow rather than assuming it.

Step 6: Write the Main Success Scenario

Describe the shortest normal path from trigger to successful outcome. Number the steps and alternate between actor action and system response where practical. Each step should state one observable event.

Use Case: Reset Password

1. The user requests a password reset.
2. The system asks for the account email address.
3. The user submits the email address.
4. The system creates a time-limited reset token and sends a reset link.
5. The user opens the link and submits a new password.
6. The system validates the token and password rules.
7. The system updates the password, invalidates the token, and confirms completion.

Write what must happen, not button colors, database tables, or programming methods. “The system verifies the token” is usually sufficient unless a specific verification behavior is externally required.

Step 7: Add Alternative Flows

Alternative flows still achieve the goal but take a different valid route. For example, a customer may pay by card, account credit, or approved invoice. Reference the main-flow step where the alternative begins and explain where it returns.

Use labels such as “4a. Customer chooses account credit.” Avoid duplicating the entire main flow. Write only the steps that differ.

Step 8: Add Exception Flows

Exception flows explain failure, rejection, timeout, cancellation, unavailable services, invalid data, or permission problems. For each exception, specify the system response and final state. A message alone is not always enough; the use case should explain whether data is retained, the user may retry, a payment is reversed, or the incident is logged.

Typical questions include:

• What happens if required data is missing?
• What if an external service is unavailable?
• What if the user loses authorization during the process?
• What if two users update the same record?
• What if the user cancels after a partial action?

Step 9: Define Postconditions

Postconditions describe the state after the use case ends. Write a success guarantee and, where useful, a minimum guarantee for failure.

For a successful payment, the order may be marked paid, inventory reserved, a receipt recorded, and confirmation queued. If payment fails, the minimum guarantee might be that no duplicate charge exists and the order remains unpaid.

Step 10: Link Business Rules and Data Requirements

Reference rules instead of burying them inside long steps. Examples include password complexity, credit limits, approval thresholds, tax treatment, retention periods, and eligibility criteria. Give each rule a stable identifier when rules are shared across use cases.

Identify important input and output data, but avoid turning the use case into a complete data dictionary. Detailed field definitions can live in a linked specification.

Step 11: Add Priority, Frequency, and Assumptions

Priority helps teams plan delivery. Frequency and volume help architects understand performance and capacity. Record assumptions that could materially change the design, such as expected transaction volume, supported countries, user roles, or service availability.

Replace assumptions with confirmed requirements as discovery progresses. An unreviewed assumption should not quietly become product behavior.

Step 12: Make the Use Case Testable

Review every step and ask whether a tester could verify it. Replace unclear words such as “quickly,” “appropriately,” “normally,” and “user-friendly” with measurable requirements or linked quality criteria.

Use cases support acceptance tests naturally. Each main, alternative, and exception path can become one or more test scenarios with defined data and expected results.

Recommended Use Case Template

Common Use Case Mistakes

• Writing a feature list: A use case should describe interaction toward a goal.
• Including implementation detail: Explain required behavior before choosing technical design.
• Skipping failure paths: Real systems spend significant effort handling exceptions.
• Combining many goals: Broad use cases become difficult to review and test.
• Using passive language: State who performs each action.
• Assuming the happy path is obvious: Number the sequence explicitly.
• Ignoring postconditions: Teams need to know what data and state remain after completion.
• Writing alone: Review with users, product, development, operations, security, and testing.

Writer’s Opinion

The best use cases are short enough to discuss but precise enough to test. I would not aim for maximum documentation. I would aim for maximum shared understanding of goals, boundaries, and exceptions. When a use case becomes dozens of pages, it often hides several goals that should be separated.

I also recommend writing exceptions early. Teams naturally agree on the happy path; the costly disagreements usually appear around permissions, failures, retries, cancellations, and partial completion.

Video Guide: How to Write a Use Case

Frequently Asked Questions

What is the difference between a use case and a user story?

A user story is a concise statement of user need, often supported by acceptance criteria. A use case describes the interaction sequence, including alternative and exception paths. Teams may use both.

Should a use case include screenshots?

Only when a screen is needed to clarify the requirement. Wireframes and design files are usually better maintained separately because interfaces may change while the user goal remains stable.

How detailed should the steps be?

Use enough detail to remove behavioral ambiguity and support testing. Avoid internal technical steps that users and external systems cannot observe unless they represent a required control.

Can another system be an actor?

Yes. An actor can be a person, organization, device, scheduled process, or external system interacting across the defined boundary.

Who approves a use case?

The appropriate business owner or product decision-maker should confirm the behavior, while delivery, security, operations, and testing teams review feasibility and completeness.

Final Checklist

• The use case covers one meaningful goal.
• The primary actor and system boundary are clear.
• The trigger and preconditions are not confused.
• The main flow is numbered and observable.
• Important alternative and exception paths are included.
• Success and failure states are defined.
• Business rules are linked rather than duplicated.
• Every step can support a test or review decision.

A well-written use case creates a common language between business and technology. It prevents teams from discovering essential behavior only after design or development has already begun.