Cockburn's Three Named Goal Levels
In short Every use case is written at some level of goal, and mixing levels is the most common reason use cases come out either too vague or too detailed. Alistair Cockburn gives the levels names, colours and icons so that writers and readers can say explicitly which level they are working at.
Based on: A. Cockburn, Writing Effective Use Cases, ch. 2 and 5.
On this page
Key ideas#
Goals have altitude#
Cockburn treats goals as a landscape with height. The reference point is sea level: the user goal. Everything else sits above or below it.
- Summary goals (white, shown as a kite, or a cloud for the very highest level). They group several user goals and show their context and life cycle. Cockburn marks them with a “+” after the name when icons are not available.
- User goals (blue, sea level, shown as a wave). What a primary actor actually wants to get done in one sitting, typically a few minutes up to about twenty. Marked with “!” if needed. This is the level that matters most.
- Subfunctions (indigo, below the surface, shown as a fish). Steps needed to achieve user goals and reused by several use cases. Marked with “-“.
- Too low (black, shown as a clam). Too small to be a use case at all; fold it into the use case that calls it.
So there are three named working levels, summary, user goal and subfunction, plus a very-high level you rarely need and a too-low level you should avoid.
Testing for sea level#
The user-goal level corresponds to an elementary business process. Cockburn’s tests:
- Would the primary actor go away satisfied after doing this?
- The coffee-break test: having finished this, would I take a break?
“Log in” fails: nobody logs in for its own sake. “Buy an item at an online auction” also fails, because it stretches over days and many sessions; it is a summary goal.
Occasionally one user-goal use case calls another in the middle of its flow. For example, renting a video may involve registering a new customer first. Both are at sea level; this is unusual but legitimate.
Moving up and down: “why?” and “how?”#
To find the goal one level up, ask why the actor is doing this. To find the goals one level down, ask how it is done. Walking up and down this chain is the quickest way to place a use case correctly.
Length as a level check#
A well-levelled use case has a main success scenario of about 3 to 10 steps. Cockburn reports that longer ones almost always improve when shortened; extra steps usually mean interface details or steps from a lower level have crept in.
Finding the outermost use cases#
To see the boundary of the work, Cockburn suggests:
- Start from a user goal.
- Ask which external actor this goal ultimately serves.
- Find the outermost design scope in which that actor is still outside, usually the company, a set of integrated systems, or the system being built.
- List all the user goals for which that actor is primary.
- Name the actor’s summary goal with respect to that scope.
- Write a summary use case for it, linking all the sea-level use cases.
A large system usually ends up with only four or five such outermost use cases. They show the boundary but do not replace the functional requirements, which live in the sea-level use cases.
Two outcomes for every scenario#
Cockburn’s “striped trousers” image (ch. 2) shows each scenario as a stripe leading to one of two legs: the goal succeeds or it fails. Every scenario, not only the main one, is just one path to one of those two outcomes. This keeps failure handling in view from the start.
How to apply it#
- List the goals of each primary actor in one sitting, without judging levels.
- Run the coffee-break test on each one and mark it summary, user goal or subfunction.
- Ask “why?” of each user goal to find the summary goals; ask “how?” to find subfunctions worth sharing.
- Write sea-level use cases first. They carry most of the functional requirements.
- Count the steps. More than about ten means you should lift detail out into subfunctions or remove interface specifics.
- Add summary use cases last to tie the sea-level ones together and to show the outer boundary.
- Label every title with its level marker or icon, so reviewers know what to expect.
Example#
For The Workshop (a fictional bike-repair chain), with the customer as primary actor:
| Level | Use case | Why it sits there |
|---|---|---|
| Summary (+) | Get my bike repaired | Spans booking, drop-off, waiting and collection over several days |
| User goal (!) | Book a repair slot | Done in one sitting; the customer is satisfied afterwards |
| User goal (!) | Check repair status | A short, self-contained visit |
| Subfunction (-) | Find free slots at a workshop | Needed by booking and by rescheduling |
| Too low | Enter phone number | A single step inside booking |
Asking “why does the customer book a slot?” leads up to “get my bike repaired”. Asking “how?” of booking leads down to “find free slots” and “identify customer”.
Pitfalls#
- Writing “Log in” or “Enter details” as use cases. They are steps or subfunctions; fold them in.
- Summary use cases full of detail. Keep them as a short sequence of sea-level goals.
- Twenty-step scenarios. Lift repeated parts into subfunctions and remove screen-level wording.
- Unlabelled levels. Reviewers then argue about detail when the real disagreement is about level.
Sources and further reading#
- A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000, ch. 2 (use case as a contract for behaviour; success and failure scenarios) and ch. 5 (three named goal levels).