This may be a lot of review for seasoned use case writers, but for those of you who are not as familiar with this requirements model, here are some best practices to consider. I assume you already know what a use case is, why you would want to use them, and the components that make up a proper use case. I’ve included some helpful links at the bottom of the post for more information.

Use a Template
A bit of a no-brainer, but I’m surprised at how many different use cases I see across projects at the same company (or even within the same project). Templates make your job easier, but even more importantly they make it easier for your readers.

Make Pre & Post Conditions Verifiable
Pre and Post Conditions should be written as testable statements. “User has logged in” is much clearer than “Log in”. Also – if you have multiple conditions, they should be separated with an And or Or, as appropriate.

Adhere to Consistent Writing Standards
This is particularly important if multiple people are writing use cases on the same project – they should all use the same writing format, style, sentence structure, etc… Consider the following:

• Single statement per line
• Always have a subject – “User” or “System”
• Be concise – remember, use cases are not end requirements – you should be demonstrating the interaction between the system and user, but not detailed specifications
• Use an active voice

Do Not Include Design
Many use cases become less effective (or even un-readable) because the author attempts to put everything they can in the use case. Detailed specifications – particularly design elements such as button names – should not be in use cases unless there is a very good reason (and usually there is not).

Use an Appropriate Level of Detail
I can suggest some guidelines, but you will have to find what the “right” level of detail is for your own situations. Keep in mind these suggestions:

• Generally, use cases should be 10-15 steps in length
• If you find yourself repeating the same set of steps on multiple use cases, consider separating them out into their own use case
• If you have a use case with just a handful of steps, consider folding it into another use case(s)
• If you have many use cases that have essentially the same set of steps, make sure you are not writing different use cases for scenarios that describe the same interaction (e.g. if you have a use case for Purchase Music CD and Purchase DVD and they describe the same interactions, then you probably are capturing scenarios instead of unique use cases)

More Reading on Use Cases
Check out the following for more information:

• The Actor Factor
• Getting Started with Use Cases
• Levels of Abstraction
• Includes and Extends
• Agile Requirements and the Use Case Narrative