When to Use Use Cases

I can't imagine a situation now in which I would not use use cases. They are an essential tool in requirements capture and in planning and controlling an iterative project. Capturing use cases is one of the primary tasks of the elaboration phase.

Most of your use cases will be generated during that phase of the project, but you will uncover more as you proceed. Keep an eye out for them at all times. Every use case is a potential requirement, and until you have captured a requirement, you cannot plan to deal with it.

Some people list and discuss the use cases first, then do some modeling. I've also found that conceptual modeling with users helps uncover use cases. So I tend to do use cases and conceptual modeling at the same time.

It is important to remember that use cases represent an external view of the system. As such, don't expect any correlations between use cases and the classes inside the system.

How many use cases should you have? During a recent OOPSLA panel discussion, several use case experts said that for a 10-person-year project, they would expect around a dozen use cases. These are base use cases; each use case would have many scenarios and many variant use cases. I've also seen projects of similar size with more than a hundred separate use cases. (If you count the variant use cases for a dozen use cases, the numbers end up about the same.) As ever, use what works for you.