The guidance here is from the book Writing Effective Use Cases by Alistair Cockburn. The intent is to provide guidance to produce the smallest, essential parts of a use case.
|Table of Contents|
Reminders for Use Case Writers
The use case style is oriented to text descriptions of how the system behaves with respect to a list of Actors.
- A use case is a prose essay
- Make the use case easy to read
- Sentences should be present tense; with an active verb in active voice; describing an actor successfully achieving a goal that moves the process forward.
- Incude sub-use cases where they make sense
- Each sentence must have an actor acting
- Get the goal level right - the use cases should have no more than 10 steps in them
- Keep the GUI out of the use case
- Each use case should describe the successful ending and the failure ending
- Stakeholders (of which the primary actor is one) have expectations that must be met by the system
Recommended Sequence for Writing
The book recommends the following order when writing:
NOTE: We expect to collect existing use case documents whenever possible rather than directly analysing organization processes, so this list can be viewed as an analysis appraoch when translating the contributions into a common style.
- Step 1: Find the boundaries of the system (Context diagram, In/out list).
- Step 2: Brainstorm and list the primary actors. (Actor List)
- Step 3: Brainstorm and list the primary actors' goals against the system. (Actor-Goal List)
Describe the highest-level summary use case that covers all of the actors and their goals
- Step 4: Write the outermost summary level use cases covering all the above.
- Step 5: Reconsider & revise the strategic use cases. Add, subtract, merge goals.
Select and write a use case document
- Step 6: Pick a use case to expand or write a narrative to get acquainted with the material.
- Step 7: Fill in the stakeholders, interests, preconditions and guarantees. Double check them.
- Step 8: Write the main success scenario. Check it against the interests and the guarantees.
Extend to cover failure conditions
- Step 9: Brainstorm and list possible failure conditions and alternate success conditions. (these become the 'extensions')
- Step 10: Write how the actors and system should behave in each extension.
Repeat with sub-use cases if needed and refine
- Step 11: Break out any sub use case that needs its own space.
- Step 12: Start from the top and readjust the use cases. Add, subtract, merge. Double check for completeness, readability, failure conditions.
To figure out what the success gaurantees might be for each stakeholder, ask the question 'what would make the stakeholder unhappy at the end of a successful run?' then use the negative of the answer.
Suggested Template for a Use Case
To reduce the burden and processing load on contributors, we will use a casual format.
|Use Case Name||A short name|
|Scope||The name of the system or business area or business function operated|
|Context||Text about the goal in its operational context|
|Primary Actor||The primary actor name or role|
|Stakeholders & Interests||List of all the stakeholders and their interests in the system operation. Stakeholders include actors that interact with the system and others who do not interact with the system.|
|Minimal Guarantees||An optional section listing the minimal guarantees|
|Success Guarantees||An optional section listing the success guarantees|
|Preconditions||What must be true before this use case can be triggered|
|Triggers||What causes the main scenario to start|
|Main Success Scenario|
A brief list of what the actors do which results in the goal being successfully achieved.
A second brief list of what the actors do when things don't go down the main path - includes alternative paths and major failure conditions.