Skip to content
Software Architecture Guide

Use Case Template

Explanation

Section titled “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

Section titled “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

Section titled “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

Section titled “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.
Section titled “Related”

Sources

Section titled “Sources”