Cockburn Use Cases

Details
Full Name

Cockburn Use Cases (Writing Effective Use Cases)

Also known as

Fully Dressed Use Cases, Goal-Level Use Cases, Cockburn Format

Core Concepts:

Fully Dressed Format

A structured textual template for describing system behavior from the actor’s perspective. Each use case includes: Primary Actor, Stakeholders & Interests, Preconditions, Trigger, Main Success Scenario (numbered steps), Extensions (alternative/failure paths with step references), Postconditions (success guarantee and minimal guarantee), and Technology & Data Variations.

Goal Levels

Three abstraction levels that organise use cases into a hierarchy:

  • Summary (Kite/Cloud) — business-process-level goals spanning multiple user sessions. Example: "Manage customer lifecycle."

  • User Goal (Sea Level) — the sweet spot: one actor, one sitting, one measurable outcome. Example: "Place an order." Most use cases live here.

  • Subfunction (Fish/Clam) — steps that support a user goal but are not goals in themselves. Example: "Authenticate user." Extract only when reused across multiple user-goal use cases.

Scope

Defines the system boundary — what is inside the "design scope" and what is an external actor. Cockburn uses icons (a box for the system, a person for actors) to make the boundary visual. Getting scope right prevents use cases from being either too vague (organisational scope) or too detailed (component scope).

Actor-Goal List

The discovery technique: list every actor and every goal they have against the system. This produces a candidate use case list before writing any prose. The goal level test: "Does the actor go home happy if this goal is achieved?" filters out subfunctions masquerading as user goals.

What Cockburn does not prescribe

Cockburn’s format is deliberately prose-based and notation-agnostic. It does not mandate Activity Diagrams, Gherkin, EARS, or any formal syntax. Those are complementary representations that can be layered on top — Activity Diagrams for visual flow, Gherkin for executable acceptance criteria, EARS for structured requirement statements.

Key Proponents

Alistair Cockburn (Writing Effective Use Cases, Addison-Wesley, 2001). The book remains the canonical reference; Cockburn also contributed to the Agile Manifesto and Crystal methodologies.

When to Use:

  • Discovering what a system needs to do before deciding how to build it — the Actor-Goal List is a fast, structured brainstorm

  • Structuring requirements conversations with stakeholders who think in scenarios, not features

  • Decomposing a large system into manageable behavioural units at the right granularity (goal-level test)

  • Brownfield theory recovery: reconstructing what a system does by writing use cases from observed behaviour

  • Feeding downstream artifacts: each use case becomes a natural unit for Activity Diagrams, Gherkin scenarios, and test plans

  • Complementing arc42: use cases populate Section 6 (Runtime View) and inform Section 3 (Context and Scope)

  • Gherkin - Executable acceptance criteria that can be derived from each extension path in a use case

  • BDD Given/When/Then - Formalises the scenario steps that Cockburn describes in prose

  • EARS Requirements - Structured syntax for individual requirement statements; complements Cockburn’s scenario-level structure

  • arc42 - Use cases feed Section 6 (Runtime View) and inform Section 3 (Context and Scope)

  • ISO 25010 - Quality goals that use case extensions should address (error handling, performance, security)

Further Reading:

  • Anchors and Training Data - why this anchor reflects Cockburn’s craft rather than Jacobson’s later Use-Case 2.0/3.0, and what that reveals about how anchors depend on training data.

Current Status:

  • Writing Effective Use Cases (2001) never had a second edition and remains the canonical craft text — and the densest, most reliably activated LLM prior for use-case writing

  • Jacobson’s successor exists and works as an anchor of its own: Use-Case 2.0 (Jacobson, Spence & Bittner, free ebook, 2011) adapts use cases to iterative delivery via use-case slices

  • Use Case 3.0 (de Mendonca & Jacobson, v1.0, 2024) does exist — but it is too young to be an anchor: LLMs hold no dense prior for it (see Further Reading above), so supply its definition in the prompt if you want 3.0 semantics. Jacobson and Cockburn realigned their craft in "Use Cases are Essential" (ACM Queue, 2023)