Use case template and example

Published 19 October 2026

A use case describes how someone uses a system to reach one goal: the steps when everything goes right, and what happens at each step where something can go wrong. Below are a template, a filled-in example, the parts of a use case, how to write one, and how a use case differs from a user story, a test case and a diagram.

A sequence of actions a system performs that yields an observable result of value to a particular user.

— Ivar Jacobson, Ian Spence and Brian Kerr, ACM Queue, 2016

Ivar Jacobson introduced use cases at the OOPSLA conference in 1987. The template below follows Alistair Cockburn’s book Writing Effective Use Cases (2001).

What goes in a use case

• Name: the goal, as a verb and an object — “Pay an open invoice by card”.
• Primary actor: the role whose goal it is. Actors can be people or other systems.
• Scope: the system being described.
• Level: a summary goal, a user goal (one person reaching one goal), or a subfunction.
• Stakeholders and interests: everyone who cares how it ends, and what each needs.
• Preconditions: what is already true before it starts.
• Trigger: what starts it.
• Success guarantee: what is true when the goal is reached.
• Minimal guarantee: what is true even when it fails.
• Main success scenario: the numbered steps when nothing goes wrong.
• Extensions: at each step, what else can happen, and what the system does then.
• Related: the requirements, stories and tests that come from it.

Cockburn’s fully dressed template has most of these fields (the full list); leave out the ones your project does not need.

Use case template

Copy it into Word, Google Docs or Confluence. Square brackets are yours to fill in.

USE CASE UC-[nn]  [goal: verb + object]

Primary actor:  [role]
Scope:          [system]
Level:          [summary / user goal /
                subfunction]
Stakeholders and interests:
  [role]:  [what they need from it]
Preconditions:  [what is true before]
Trigger:        [what starts it]
Success guarantee:
  [what is true when it succeeds]
Minimal guarantee:
  [what is true even if it fails]

MAIN SUCCESS SCENARIO
1. [actor or system does one thing]
2. [   ]

EXTENSIONS
[step][a]. [condition]:
    1. [what happens]
    2. [where it ends, or which step
       it returns to]

Related:  [requirements, stories, tests]
Version:  [x.y], [date]

Use case example

A customer portal where business customers see and pay their invoices:

USE CASE UC-03
Pay an open invoice by card

Primary actor:  Customer's finance clerk
Scope:          Customer portal
Level:          User goal
Stakeholders and interests:
  Finance clerk: pay quickly, get a
    receipt
  Accounts team: each payment matched to
    the right invoice, no manual work
  Portal owner: no card details on its
    servers
Preconditions:  The clerk is signed in;
                the company has an open
                invoice.
Trigger:        The clerk chooses to pay
                an open invoice.
Success guarantee:
  The invoice shows "Paid" with today's
  date; the payment is recorded against
  it; a receipt is emailed.
Minimal guarantee:
  The card is charged at most once; the
  invoice never shows "Paid" unless the
  bank approved the payment.

MAIN SUCCESS SCENARIO
1. Clerk chooses to pay an open invoice
   by card.
2. Portal shows the amount and the
   payment provider's card form.
3. Clerk enters the card details.
4. Payment provider asks the bank to
   approve the payment.
5. Bank approves.
6. Portal marks the invoice "Paid" with
   today's date.
7. Portal records the payment against
   the invoice.
8. Portal emails a receipt to the clerk.
9. Portal confirms the payment.

EXTENSIONS
1a. The invoice was paid by bank
    transfer in the meantime:
    1. Portal says it is already paid;
       no payment is taken. Ends.
5a. Bank declines the payment:
    1. Portal shows the bank's reason;
       the invoice stays open.
    2. Clerk tries another card (back
       to step 3), or leaves. Ends.
5b. Bank does not answer in 60 seconds:
    1. Portal asks the provider for the
       status before any retry.
    2. Status unknown: the invoice shows
       "Payment pending"; the clerk gets
       an email when settled. Ends.

Related:  FR-014, FR-015, NFR-007;
          UAT-01, UAT-02
Version:  1.2, 12 March

The functional requirements FR-014 and FR-015 say in one line each what steps 1–9 spell out. The extensions are where the questions are: 5b is the kind of case that is easy to miss until a card is charged twice.

Basic flow, alternative flows and exception flows

The names differ between books; the idea is the same:

Jacobson and his co-authors: “The simplest way of achieving the goal is described by the basic flow. The others are presented as alternative flows.” Cockburn calls them the main success scenario and extensions, and numbers each extension after the step it branches from — 5a, 5b.

In the example, 5a is an alternative flow when the clerk pays with another card, and an exception flow when they leave. 1a and 5b end without the goal reached.

Brief, casual and fully dressed use cases

Not every use case needs every field. Common names for the levels of detail:

• Brief: one paragraph — the goal and the main steps. Enough early in a project, or for a list of what the system will do.
• Casual: a few paragraphs — the main flow and the important alternatives.
• Fully dressed: every field in the template above. Worth it where mistakes are expensive: payments, data that cannot be lost, steps a regulator checks.

Use cases also come at different goal levels. Cockburn prefers the user-goal level, which he calls “sea level”: one person reaching one goal, like paying an invoice. Above it are summary goals (“get paid on time”); below it, subfunctions (“find an invoice”).

Use case template in Excel

A spreadsheet works when the team keeps requirements in rows. One commenter describes their layout: “For the use case, I try to organize in a table with the steps going down the rows. Alternate, optional, etc. steps go over in a new column.” And: “Then I put one or more user story into the row to provide the traceability to when it’s done.” (r/businessanalysis, 2025).

How to write a use case

1. Find the actors and their goals. Who uses the system, and what does each of them want to get done? Each goal is a use case.
2. Name the goal, not the function. One commenter: “Way back when use cases were a thing, I used to chide people for saying that Backup was a use case. No, Restore is a use case.” (Hacker News, 2023). For the same reason, signing in is rarely a use case of its own — it is a precondition.
3. Write the main success scenario first, in 3–9 steps. Each step is one thing the actor or the system does. Leave out screens and buttons; say what happens, not where to click.
4. Go through every step and ask what else can happen — declined, missing, late, duplicated, changed in the meantime. Each answer is an extension.
5. Write the guarantees: what is true when it succeeds, and what must stay true when it fails.
6. Read it through with the people who do the work, and with whoever will test it.
7. Link it to what comes from it: the requirements, the stories, the test cases.

What a use case does not cover goes elsewhere: response times, security and availability are non-functional requirements, usually written for many use cases at once.

Use case vs user story

Kent Beck, who wrote that he coined the term user story, explained why on the C2 wiki: “Use cases as I have seen them used are complex and formal enough that business doesn’t want to touch them.” Alistair Cockburn, on the same page: “After several years of debating this question and seeing both in use, I now think they have nothing in common other than their first three letters.” (C2 wiki).

When to choose which, according to Jacobson and his co-authors:

The sweet spot for user stories is achieved when there is easy access to a SME and the severity of errors is low. Use cases and use-case slices are more suitable when there is no easy access to a SME or when error consequences are high.

— ACM Queue, 2016

They are not either-or. One commenter decides by the question being answered: ““How does the user interact with the system?” → use case. “What small outcome should we deliver?” → user story.” (r/businessanalysis, 2026). The user story template has the story side.

Use case vs test case and scenario

A scenario is one path through a use case: the main flow, or the main flow with one extension. A test case checks one scenario with real data and an expected result — the test case template has the format.

From UC-03, the main success scenario becomes the UAT test case UAT-01 (pay an open invoice by card), and extension 5a becomes UAT-02 (a card the bank declines). A use case with nine steps and three extensions gives at least four scenarios to test.

For a client project, the same link works at acceptance. One commenter: “But whenever we have a vendor solution, use cases are created for each requirement in the RFP. This is to make sure the vendor understands exactly what needs to be delivered. During UAT we revisit the use cases to check if the delivery is as expected.” (r/businessanalysis, 2020).

Use case diagram

A use case diagram, in UML, shows the actors and their use cases on one page — the big picture, not the steps. Two relationships cause most of the questions:

• Include: a use case always uses another one. “Pay an open invoice” includes “Take card payment”. The arrow points to the included use case.
• Extend: a use case adds optional behaviour to another, under a condition. “Save card for next time” extends “Pay an open invoice”. The arrow points to the use case being extended.

The diagram is the index; the written use case is the content. A diagram without the text says who does what, but not what happens when it goes wrong.

Use cases in agile

Use cases and backlogs can work together. In Use-Case 2.0 (Jacobson, Spence and Bittner, 2011), a use case is cut into slices that fit a sprint: “A use-case slice is one or more stories selected from a use case to form a work item that is of clear value to the customer.” (ACM Queue, 2016). For UC-03, the main flow is one slice, the declined card another, the bank timeout a third.

Another way: the use case becomes an epic, and its steps become stories — as one commenter puts it, “usually a use case becomes an epic and the steps or Details of the use case User Stories of that epic” (r/businessanalysis, 2025).

The hard part comes after. In the same thread, the poster: “However they quickly get outdated and the requirements specified in the use case flows change with the varying sprints and iterations, due to user feedback.” And a reply: “However once everything is in Jira, then Nobody bothers anymore to the confluence documentation, but rather all changes are done in jira.” A use case that was right at sign-off and is wrong at UAT is a problem of its own: testers may check against it.

Where Specroot fits

This is the problem Specroot works on: use cases, the stories built from them and the tests that check them, on one version that was signed off — so that a change to a flow shows which stories and tests it touches. Specroot for agencies and consultancies.