Writing Effective Use Cases

Author: Alistair Cockburn
All Stack Overflow 9

Writing Effective Use Cases


Review Date:


by Peter Hilton   2017-08-20

This is a somewhat deep question, so I am hesitant to give a short answer. It is a good idea to read a few good books that describe different approaches, such as The Inmates Are Running the Asylum, which describes scenario-based function design. Another approach is to use high-level use-cases, as described in Writing Effective Use Cases.

Some guidelines:

  • Write what is required without constraining how this will be done.
  • Make each requirement a separate numbered list entry for cross-reference.
  • Split requirements into separate items until each one is 'atomic'.
  • Include a Security section, and be explicit about what security is required.
  • Include a Non-functional requirements section, for constraints like performance and availability.
  • Include a Non-requirements section to list things that are not requirements, so you can tell the difference between something you forgot, and something you do not need.
  • Specify external interfaces (to other systems) as well as user-interface requirements.
by anonymous   2017-08-20

When you are introducing someone new to your programming environment they need to understand the business problems as opposed to the technical. For the feature set under consideration, you need to identify the expected success paths and minimize the failure space before handing off to them. By this I mean clearly documenting how a particular piece of functionality is expected to behave and also what should happen when something is done incorrectly (e.g. bad data such as a string when a number's expected, clicking submit multiple times on a web-app, etc...). It's identifying and documenting how to deal with the failures that really take the most effort.

Then assuming a human facing piece of functionality, lead with user interface designs (e.g. wireframes) and written use cases. If this functionality is meant to exist in, or integrate with, another system UML diagrams are useful to show that interaction. At this point, are you hiring a glorified typist or someone who can think? If the former, then really get into the weeds and UML out the class hierarchy.


by anonymous   2017-08-20

One option is the format recommended in Alistair Cockburn's Writing Effective Use Cases:

2a-  User wants to do another thing:
2a1- The user does another thing
2a2- The system responds in some way, returns to step 3

Step 2a occurs after step 2 and before step 3. If the UC ends at step 2a2 then simply replace 'returns to step 3' with 'Use Case ends' or similar.