What Is a Quality Use Case?
This chapter is from the book
This chapter is from the book
This chapter is from the book
The hardest single part of building a software system is deciding precisely what to build.
—Frederick Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering"
1.1 Why Use Cases at All?
"I understand the requirements, but what does it actually do?" is a question often asked by systems analysts, business analysts, product managers, and programmers when confronted by two hundred pages of traditional IEEE-standard-style "The system shall . . ." functional requirements. After reading these convoluted documents, many of us have often gone back to the customers and pleaded, "What do you want this system to do? Tell me a story about how you are going to use this system."
People like stories, and from one point of view, use cases are simply stories about how people (or other things) use a system to perform some task. In this sense, use cases are nothing new; we have always had ways of telling stories about systems. We have used everything from flowcharts to message traces, to storyboards, to just plain prose. So what are the advantages of use cases?
First, use cases give us a semiformal framework for structuring the stories. Ivar Jacobson gave us the concepts of actors and use cases and rules for how actors and use cases communicate. It wasn't enough just to tell a story. The story had to have a purpose or, in Jacobson's words, "yield a result of measurable value to an individual actor of the system" (Jacobson 1995, p. 105).
Just as excessive structure and formality can make requirements unusable, so can the complete lack of structure. If everyone is free to tell stories about the system in any manner they choose, how can you determine if the requirements are correct? How do you find redundant stories? How do you spot holes in the stories? Some structure is necessary; otherwise, people's creativity will work at cross-purposes.
It is this semiformal structuring that liberates the creativity of people. Rigid formal requirement models can be stifling, and are unusable by most people because they have not been expertly trained in the appropriate modeling technique. This semiformal structuring makes it relatively easy for the end user of a system to read the document with very little training. End users may then actually read the requirements document, and be better able to substantiate the system proposal while it is still in the writing stage.
Second, use cases describe the system requirements for the error situations, in every use case and at every level of description. Since much or most of the system complexity lies in handling error situations, describing such requirements means that the associated difficulties are detected and discussed early, rather than late, in the development cycle.
Third, although use cases are essentially a functional decomposition technique, they have become a popular element of object-oriented software development. Several people, including Jacobson (1992) and Larman (2002) describe methodologies for realizing the objects necessary to implement the behavior described by the use case. One can write a set of use cases describing the system's functional behavior and then use these techniques to design the objects necessary to implement that behavior.
Finally, use cases provide good scaffolding on which to hang other project information. The project manager can build estimates and release schedules around them. Data and business rule specifiers can associate their requirements to the use cases in which they are needed. User interface designers can design and link their designs to the relevant use cases. Testers can construct test scenarios from the success and failure conditions described in the use cases. Many modern software development processes are built around use cases.