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.