Use case guidelines by Alistair Cockburn

Contents

These guidelines are taken verbatim from Writing Effective Use Cases, by Alistair Cockburn (pronounced "Coburn"), Addison-Wesley, 2001, ISBN 0-201-70225-8. Note that "SuD" stands for "System under Development" (sometimes referred to as System under Discussion).

Reminders

Write something readable.

Casual, readable use cases are still useful, whereas unreadable use cases won't get read.

Work breadth-first, from lower precision to higher precision.

Precision Level 1: Primary actor's name and goal
Precision Level 2: The use case brief, or the main success scenario
Precision Level 3: The extension conditions
Precision Level 4: The extension handling steps

For each step:

Show a goal succeeding.
Capture the actor's intention, not the user interface details.
Have an actor pass information, validate a condition, or update state.
Write between-step commentary to indicate step sequencing (or lack of).
Ask "why" to find a next-higher level goal.

For data descriptions (only put Precision Level 1 into the use case text):

Precision Level 1: Data nickname
Precision Level 2: Data fields associated with the nickname
Precision Level 3: Field types, lengths, and validations

(From inside front cover.)

The Writing Process

[NB: JDT has removed several of the steps that are irrelevant for the use case template used in 360]

Name the system scope.
Brainstorm and list the primary actors.
Find every human and non-human primary actor, over the life of the system.
Brainstorm and exhaustively list user goals for the system.
Select one use case to expand.
Consider writing a narrative to learn the material.
Write the main success scenario (MSS).
Use 3 to 9 steps to meet all interests and guarantees.
Brainstorm and exhaustively list the extension conditions.
Include all that the sytem can detect and must handle.
Write the extension-handling steps.
Each will end back in the MSS, at a separate success exit, or in failure.
Extract complex flows to sub use cases; merge trivial sub use cases.
Extracting a sub use case is easy, but it adds cost to the project.
Readjust the set: add, subtract, merge, as needed.

(From inside front cover.)

Pass/Fail Tests for Use Case Fields

All of them should produce a "yes" answer. [NB: JDT has removed several of the fields that are irrelevant for the use case template used in 360]

Field	Question
Use Case Title	1. Is it an active-verb goal phrase that names the goal of the primary actor? 2. Can the system deliver that goal?
Primary Actor	8. Does he/she/it have behavior? 9. Does he/she/it have a goal against the SuD that is a service promise of the SuD?
Preconditions	10. Are they mandatory, and can they be set in place by the SuD? 11. Is it true that they are never checked in the use case?
Main Success Scenario	15. Does it have 3-9 steps? 16. Does it run from trigger to delivery of the success guarantee? 17. Does it permit the right variations in sequencing?
Each Step in Any Scenario	18. Is it phrased as a goal that succeeds? 19. Does the process move distinctly forward after its successful completion? 20. Is it clear which actor is operating the goal--who is "kicking the ball"? 21. Is the intent of the actor clear? 22. Is the goal level of the step lower than the goal level of the overall use case? Is it, preferably, just a bit below the use case goal level? 23. Are you sure the step does not describe the user interface design of the system? 24. Is it clear what information is being passed in the step? 25. Does it "validate" as opposed to "check" a condition?
Extension Condition	26. Can and must the system both detect and handle it? 27. Is it what the system actually needs?
Overall Use Case Content	29. To the sponsors and users: "Is this what you want?" 30. To the sponsors and users: "Will you be able to tell, upon delivery, whether you got this?" 31. To the developers: "Can you implement this?"

(From inside back cover.)