When Use Cases Aren't Enough

Use cases are recognized as a powerful technique for exploring user requirements. The great benefit they provide is to bring a user-centric and usage-centered perspective to requirements elicitation discussions. The analyst employs use cases to understand what the user is trying to accomplish and how he envisions his interactions with the product leading to the intended user value. Putting the user at the center is much better than focusing on product features, menus, screens, and functions that characterize traditional requirements discussions. And the structure that use cases provide is far superior to the nearly worthless technique of asking users, “What do you want?” or “What are your requirements?”

As with most new software development techniques, use cases have acquired a bit of a mystique, some misconceptions, overblown hype, and polarized camps of enthusiasts who will all try to teach you the One True Use Case Way. In this chapter, I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren’t a sufficient solution to the requirements problem.

The Power of Use Cases

I’m a strong believer in the use case approach. Use cases are an excellent way to structure the dialogue with users about the goals they need to accomplish with the help of the system. Users can relate to and review use cases because the analyst writes them from the user’s point of view, describing aspects of the user’s business. In my experience, once they get past the discomfort of trying a new technique, users readily accept the use case method as a way to explore requirements.

I’m often asked how to write requirements specifications so that users can read and understand them and also so that they contain all the detail that developers need. In many cases, one requirements representation won’t meet both of these objectives. Users can comprehend use cases, but they might balk at reviewing a more detailed functional requirements specification. Use cases give developers an overall understanding of the system’s behavior that fragments of individual functionality cannot. However, developers usually need considerably more information than use cases provide so that they know just what to build. In many circumstances, the combination of employing use cases to represent user requirements and a software requirements specification to contain functional and nonfunctional requirements meets both sets of needs.