# Use Case Template

**In short:** A use case template is a fixed form for writing a use case as text. Every use case gets the same fields, so readers can compare and review them. Teams can use a full or a short version.

## Explanation

A use case describes how a user reaches a goal with a system (see the article Use Case). A use case template is the form you fill in to write one down. The text carries the value. One source notes that the value of use cases lies in the text, which UML does not standardize.

Most templates are variations of Cockburn's fully dressed template. His book *Writing Effective Use Cases* is the standard reference.

**Fields of the fully dressed form**

- **Precondition:** what must hold before the use case can run.
- **Trigger:** what starts it.
- **Primary actor:** the user from whose perspective the use case is written and started.
- **Scope:** how much of the system the use case covers. It ranges from a whole organization seen as a black box down to a single component.
- **Goal level:** how detailed the use case is. For API and service design, aim for user goal or subfunction level (see Use Case Goal Level).
- **Main success scenario:** a numbered list of steps. Each step is a simple statement of an interaction between actor and system.
- **Extensions:** conditions that lead to different interactions than the main scenario. They cover error handling and special cases.
- **Guarantees:** minimal and success guarantees. Postconditions state what changes in the system afterwards.
- **Stakeholders and interests:** who cares about the outcome and why.

**Casual version**

The casual format is lighter. The body is a paragraph or two of informal text that describes what happens. The fully dressed form can also be simplified when less detail is needed.

**Relations between use cases**

Fowler advises using include when steps repeat across use cases or form their own chunk. He advises ignoring extend.

## Example

A shop writes a use case called "Place order".

- Primary actor: customer.
- Precondition: the customer is signed in.
- Trigger: the customer presses "Checkout".
- Main success scenario:
  1. The customer reviews the cart.
  2. The customer enters payment details.
  3. The system confirms the order.
- Extension 2a: the payment is declined. The system asks for another payment method.
- Guarantees: the order is stored only if payment succeeded.

The extension number ties to step 2 of the main scenario. A casual version would describe the same story in one short paragraph.

## Trade-offs

The fully dressed form is precise but takes more effort to write and read. The casual form is quick but leaves out detail such as guarantees and stakeholders. Choose the level of detail that your readers need. The template can be simplified when less detail is enough.



## Checks

- Each use case names a primary actor, a trigger and the preconditions that must hold before it starts.
- The main success scenario is a numbered list of simple actor-system interaction steps.
- Extensions cover error handling and special cases, each as a condition that leads to different interactions.
- Each use case states its design scope and goal level.
- Postconditions or guarantees state what changes in the system after the use case runs.

## Related

- [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md)
- [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md)
- [Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md)
- [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md)
- [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md)
- [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md)
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)
- [Quality attributes in use case descriptions](https://arc.fuet.ch/concepts/quality-attributes/quality-attributes-in-use-case-descriptions.md)

## Sources

- [Use case - Wikipedia](https://en.wikipedia.org/wiki/Use_case) — en.wikipedia.org, accessed 2026-11-09
- [design-practice-repository | Summaries of artifacts, templates, practices, and techniques for agile architecting (DPR-mm) and service design (SDPR-nn).](https://socadk.github.io/design-practice-repository/artifact-templates/DPR-UseCase.html) — socadk.github.io, accessed 2026-11-09
- [Include And Extend](https://www.martinfowler.com/bliki/IncludeAndExtend.html) — martinfowler.com, accessed 2026-11-09
- [Use Case](https://martinfowler.com/bliki/UseCase.html) — martinfowler.com, accessed 2026-11-09