Top Five Use Case Blunders

We all make mistakes. When we mess up use cases, it is most likely one of these five things.

1. Inconsistency. All the use cases we write need to be at the same level (macro-scopic, not microscopic or telescopic) and use the same format (narrative versus list, formal versus informal). Managing sub-use cases versus use cases is part of getting the level right.
2. Incorrectness. We must communicate with the users and business analysts to validate that we’ve captured the right steps and information. My experience has been that the alternate course and preconditions are toughest to get right (see formal use case).
3. Wrong priorities. We have to implement the right use cases, in the right order. The most important use cases need to be implemented first. Importance is driven by ROI. Balance this with implementation dependencies and change management constraints.
4. Implementation cues. We should not specify the implementation in our use cases. Avoid using language that implies implementation choices.
5. Broken traceability. Use cases enable goals (and therefore ROI). Functional requirements support use cases. We have to maintain the links from goals to use cases to functional requirements, or changes to any of them will not propagate their impacts.
6. We’ve added to this list – Top ten use case mistakes – which now includes items 6-10.

On the bright side – each of these blunders is very easy to identify, and easy to correct.

If you’re new to this blog, you may want to look at the use case series.

ObRelatedLink:
Also, here’s a nice article from IBM with some lower level techniques to improve your use case writing. These tips are along the lines of “write in the active voice” and “use a template” and other tactical guidelines.

[Update] Be sure to check out the full list for details of the other five blunders.