Use Cases

Writing simple statements is an excellent way to capture and to prioritize performance, hardware, deployment, and usability requirements but is a little lacking for capturing functional ones. Functional requirements describe how the system behaves in response to user and external system input. They tend to be more dynamic and often require greater detail in order to clearly understand them. Use cases are a powerful technique for capturing and expressing detailed system behavior. Use cases were first put forward by Ivar Jacobson.[2] Other favorite resources of mine on use cases are Alistair Cockburn,[3] Larry Constantine and Lucy Lockwood.[4] Use cases are a formal way to capture and to express the interaction and the dialogue between system users, called actors, and the system itself. Because a full discussion of use cases is beyond the scope of this book, and I will concentrate on the highlights and most interesting points as they relate specifically to Web-based applications.

[2] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach (Boston, MA: Addison-Wesley, 1992).

[3] A. Cockburn, Writing Effective Use Cases (Boston, MA: Addison-Wesley, 2000).

[4] L. Constantine and L. Lockwood, Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design (Boston, MA: Addison-Wesley, 1999).

Jacobson uses the term actor to represent a generic role of user. The term user is reserved for instances of people using the system. Users may play the part of many actors of the system. An actor's name should represent the type of role it plays with the system. A typical actor of an e-commerce system might be Online Customer, or someone who uses the system to purchase items by using a browser and the Internet.

A use case is a textual description of the interaction between an actor and the system. A use case contains a narrative description of a specific usage scenario, one in which an actor supplies input and the system exhibits an observable output. A use case may contain more than one scenario; however, there is always one main scenario. The other scenarios are called alternative scenarios, or alternative paths.

A use case is written to express what a system should do, without constraining how it should do it. A use case describes the behavior of the system as viewed from the outside. All the behavior is in the form of observable results. Of course, the observable results don't have to be displayed on the user's screen; they could be in the form of a database change or the cutting of a bank check at the home office. The point is to maintain a focus on the input and output behavior of the system and to leave the details of applying the architecture and creating a workable design to the analysts and designers who will use the use case later on.

All use cases are named, and their names reflect their purposes, or goals. It is also helpful to number use cases for traceability because even use case names are subject to change. In addition to the required use case name and scenario description, most use cases capture other key information:

• Unique ID: Ideally, an automated number or a numbering system that will enable a use case name to evolve and yet maintain traceability throughout the process. The ID can be an intelligent key with the use case categorypackageor other understandable information.
• Goal statement: A simple, one-line, if possible, statement that summarizes the goal of the entire use case. This goal, like a vision statement, is a useful reference as the use case evolves. If actions in the use case don't support the goal, their inclusion in the scenario should be questioned.
• Authors: The names of the requirements team members who have directly contributed to the text in the use case. Depending on how cynical you are, it could mean the people to contact when clarification needs to be made or the people to blame when things go wrong.
• Assumptions: A textual description of things that are assumed, that is, the state of the system. The assumptions do not constrain the system but rather are things that the use case writers have assumed to be true while writing the use case.
• Preconditions: A textual description of conditions that must be met before this use case can be performed. Unlike assumptions, preconditions must be satisfied before the use case can begin.
• Postconditions: A textual description of conditions that must be met before this use case can be completed. Postconditions typically refer to a state the system must be in for the use case to end, such as no outstanding error conditions.
• Outstanding issues: A collection of items that need to be resolved before the use case can be elaborated in analysis and design. This section of a use case should be used only during its construction and should be blank by the time it is used in any downstream process.

The formatting of the scenario is flexible, and there is no one right way to do it. Use cases can be highly structured, with tightly controlled phrasing and numerous section headings and enumerations to identify ordering. At the other extreme, use cases can be relaxed, and appear more like a story. I have worked with use cases at both extremes, and I can't say that I favor one over the other. The right style of use case is usually related to the type of application being developed and the dynamics of the organization building it.

A use case is written in the language of the domain. Remember, use cases are simply a technique to express requirements, and a requirement is a contract between the stakeholders/users and the development staff. Both parties need to be able to understand what is captured and meant by a use case. Use cases are also used by the technical writers as the basis for a user manual. In a well-managed project, user documentation should be complete about the same time as the software is, since both the software and the user manual are directly based on the use cases. Some processes even stress that use case descriptions be written in the form of a user manual. The testing group also makes use of use cases as the basis for the majority of the test scripts. Nearly every member of the development team uses the use cases for one reason or another. Use cases are a central artifact and drive all other aspects of the process.

I had one experience in which the initial requirements team consisted mainly of an analyst/developer, a database-oriented developer, and a domain expert (end user). We constructed a use case model and use case descriptions that were more or less as they were presented in the original text by Jacobson. The style was a compromise between the two extremes, and we all seemed to be happy with their format.

About a month after we had begun, the testing team had finally been assembled. The team members looked at our use casessomething that every new member of a development team should doand determined that they needed a little more detail if automated test scripts were to be developed from them. We revised our use case descriptions, which became increasingly structured, to the extreme. The phrasing and terminology were so rigid and explicit that when one domain expert was asked if this use case was what she wanted the system to do, she had to say, "Well I think so; I'm not sure now since I really don't understand most of it anymore."

That raised a flag, and we immediately reassessed how structured we wanted our use cases to be. We made another compromise. We kept the general structurenumbered steps and simple sentencesbut dropped a lot of the technical phrases and references to specific user interface elements. In the end, we had use cases the domain experts could read and, with some help from the design artifacts, something the testing team could read and build test scripts around.

A use case often contains multiple scenarios. One of them is always the basic flow scenario, or "happy path." The other scenarios represent alternative paths through the use case. These alternative paths may be exceptions or infrequently used options in the scenario. An exception would be something like the actor's deciding to cancel a transaction partway through it. An infrequently used option might be the capturing of additional information, required only for international customers. The common theme among the scenarios is the intent of the actor to accomplish the goal statement. Even an actor canceling a use case started it with the intent mentioned in the stated goal. In a use case document, the alternative scenarios are clearly indicated as such, and when appropriate, additional information is supplied to connect them to the main scenario. Similarly, the main scenario may refer to the alternative scenarios when appropriate in the narrative.