Writing Use Case Scenarios

Writing Use Case Scenarios

A use case diagram tells you what the system does and who interacts with it. A use case scenario tells you how it does it — step by step, under specific conditions, from the actor's point of view. Together, the diagram and its scenarios form the complete use case model that drives design, testing, and validation.

This lesson focuses on the industry-standard fully-dressed template, introduced by Alistair Cockburn. It is the format you will produce for every significant use case in a professional project. You will learn each section, why it exists, and how to write it with precision using a clinic booking system as a running example.

Why the Fully-Dressed Format?

Brief use case descriptions (one or two sentences) work for initial scoping. But development teams, testers, and acceptance reviewers need much more:

• Exactly what state the system must be in before the use case starts (preconditions).
• A numbered sequence of interactions — the main success scenario (MSS) — that describes the ideal, happy-path outcome.
• All the ways things can deviate — extensions (also called alternate and exception flows) — each tied to a specific step in the MSS.
• The guaranteed postconditions (what is true at the end).

Without these details, developers make assumptions, tests miss edge cases, and the finished system surprises its stakeholders.

The Fully-Dressed Template

The standard sections and their purpose:

Walking Through a Complete Example: Book Appointment

Imagine a private clinic. A patient calls the reception desk, and the receptionist uses the Clinic Booking System to record the appointment. Let us build the full scenario.

Now, here is the complete fully-dressed scenario for Book Appointment:

Reading the Scenario: Key Observations

Study how the scenario is constructed:

• Each MSS step is one observable interaction — either the actor does something, or the system responds. Steps are never compound actions (never "actor does X and Y and Z"). If you need three things to happen, write three steps.
• Extensions use compound numbering — 3a, 5a, 7a, 7b. The first digit is the MSS step where the deviation can occur. The letter distinguishes multiple conditions at the same step. Nested actions within an extension are 3a.1, 3a.2, etc.
• Every extension resolves explicitly — it either resumes at a named MSS step ("resume at step 5") or ends with a success/failure outcome. Leaving an extension hanging is a common defect in amateur scenarios.
• Postconditions are guaranteed outcomes, not steps — they describe the state of the world after success, not what the system does. "A confirmation SMS is sent" is a postcondition, not "the system sends an SMS" (that is step 9).

A Second Example: Return Book (Library System)

Here is a shorter but complete scenario to reinforce the pattern with a different domain:

Common Mistakes to Avoid

• Writing UI steps instead of logical steps. "Receptionist clicks the blue Save button" is a UI specification, not a use case step. Write "Receptionist saves the appointment." The design will determine which button to use.
• Skipping preconditions. Developers assume they can call a use case from any state. Explicit preconditions prevent that assumption and expose missing authentication/authorisation requirements.
• Incomplete extensions. An extension that says "system shows an error" with no resolution is not complete. Every extension must state where execution resumes or confirm the use case ends.
• Conflating alternate flows with exception flows. An alternate flow is a valid variation that still achieves the goal (e.g., patient pays cash instead of card). An exception flow is an error condition that prevents normal completion (e.g., payment gateway timeout). Both use the same extension notation, but understanding the distinction helps you write more complete postconditions.