In Chapter 12, we described storyboarding and discussed how you can use storyboards to show the who, what, and how of system and user behavior. Use cases are another technique for expressing that behavior. We briefly introduced this technique in Chapters 2 and 5, where we used it to help us model the behavior of a business.
In this chapter, we'll develop the use-case technique further, describing how we can use it to understand the behavior of the system we are going to develop, as opposed to understanding the behavior of the business the system is going to operate within. In other words, we'll use use cases as an elicitation technique to understand the needed behavior of the application we are going to develop to solve a user's problem. Use cases are such an important technique for capturing and specifying system requirements that we'll be developing them further in Team Skill 5, Refining the System Definition, and Team Skill 6, Building the Right System.
The use-case technique is integral to the software methodology Object-Oriented Software Engineering, as described in the book Object-Oriented Software Engineering, A Use Case Driven Approach (Jacobson et al. 1992). This method for the analysis and design of complex systems is "use case driven," a way of describing a system's behavior from the perspective of how the various users interact with the system to accomplish their objectives. This user-centric approach provides an opportunity to explore system behaviors with early user involvement.
Also, as we mentioned earlier, use cases serve as the UML representation for the requirements of a system. In addition to capturing the requirements for the system, the use cases developed in the elicitation process will be of even further value during the analysis and design activities. Indeed, the use-case method is powerful throughout the software lifecycle, as the use cases can also play a significant role in the testing process. As later chapters develop the use-case technique more fully, for now we need understand only how we can apply use cases to capture the initial requirements for the system.
We'll start with a slightly more formal definition than we provided earlier.
A use case describes a sequence of actions a system performs that yields a result of value to a particular actor.
In other words, use cases describe the interactions between a user and a system, and they focus on what the system "does" for the user. In addition, as the actions are described in a sequence, it's easy to "follow the action" and to gain an understanding of what the system does for the user. In the UML, the use case is represented by a simple oval icon that contains the name of the use case.
In requirements elicitation, use cases can elicit and capture system requirements. Each use case describes a series of events in which a particular actor, such as "Jenny the Model," interacts with a system, such as the "Ad Lib Modeling Agency Client Scheduling System," to achieve a result of value to Jenny, such as downloading directions to the next modeling assignment.
The use-case model for a system consists of all of the actors of the system and all of the various use cases by which the actors interact with the system, thereby describing the totality of the functional behavior of the system. The use-case model also shows relationships among use cases, which furthers our understanding of the system.
The first step in use-case modeling is to create a system diagram that describes the system boundaries and identifies the actors of the system. This nicely parallels steps 3 and 4 of the five steps in problem analysis, wherein we identified the stakeholders of the system and defined the system boundaries. We also know from Chapters 4, 5, and 6 how to identify the actors that will interact with the system.
For example, in a warehouse management system (Jacobson et al. 1992), the system boundary might appear as in Figure 13-1.
You can see that the system is used by a number of users, each of whom interacts with the system to achieve a specific operational objective.
Further analysis of the system determines that certain threads of system behavior are necessary to support the user's needs. These threads are the use cases, or the specific sequences by which the users interact with the system to accomplish a specific objective. Examples of use cases for this system could include
Manual distribution of items within a warehouse
Insertion of a new item in a warehouse
Check items in a warehouse
The notion of use cases can be described very simply to a prospective user of a system. Use cases are written in the user's natural language. They are easy to describe and to document. This provides a simple, structured format around which the development team and the user can work together to describe the behavior of an existing system or to define the behavior of a new system. And, of course, each individual user will naturally focus on the system capabilities needed in order to do the job better. If, in addition, behavior is fully explored with all potential users, the team has gone a long way toward the objective of complete understanding of desired system behavior. There should be few undiscovered functionality ruins left at the end of the process.
Also, to the extent that the use-case method explores the user interfaces directly, early feedback can be obtained on this important and volatile aspect of system specification and design.
However, we must also understand that the users of the system represent only one class of stakeholders, albeit an important class, and that we may need to apply other elicitation techniques to gather the requirements from other stakeholders, such as nonuser customers, management, subcontractors, and so on. In addition, use cases are not as helpful in identifying the nonfunctional aspects of the system requirements, such as the requirements for usability, reliability, performance, and the like. We'll rely on other techniques to address these issues.
After all of the use cases, actors, and objects in the system have been identified, the next step is to further refine the detailed functional behavior of each use case. These use-case specifications consist of textual and graphical descriptions of the use case, written from the point of view of the user.
The use-case specifications can be thought of as a container that describes a series of related events, which in turn can be used to imply other requirements that will be developed further at a later time. Thus, a use case specification might include the step "The maintenance technician enters his or her first name (16 characters maximum), last name, and so on."
As use cases define the user/system interaction, it may be an appropriate time to define, at least in concept, the screens, displays, front panels, and so on that the user interacts with. If a windowing system is used to present the information, a high-level graphical depiction of the data to be displayed may be appropriate; details of formal graphical user interface (GUI) design, such as data definitions, colors, and fonts) should be left to later phases. Figure 13-2 shows portions of an example use-case specification.
Impressed by the power of use cases, the HOLIS development team decided to use this technique to describe the high-level system functionality of HOLIS. In order to do so, the team held a brainstorming session to define the significant use cases to be developed further in later activities. This "use-case model survey" identified 20 use cases to be elaborated in later activities, some of which are as follows.
| Name | Description | Actor(s) |
|---|---|---|
| Create Custom Lighting Scene | Resident creates a custom lighting scene | Resident, Lights |
| Initiate Emergency | Resident initiates emergency action | Resident |
| Control Light | Resident turns light(s) on or off or sets desired dim effect | Resident, Lights |
| Program Switch | Change or set the actions for a particular button/switch | Homeowner/programmer |
| Remote Programming | Lumenations service provider does remote programming based on request from resident | Lumenations Services |
| Go On Vacation | Homeowner sets vacation setting for extended away period | Homeowner/programmer |
| Set Timing Sequence | Homeowner programs time-based automated lighting sequence | Homeowner/programmer |
Use cases provide a structured and reasonably formal notation for capturing a very important subset of the requirements information: how the system interacts with the user to deliver its functionality. In many applications, this subset represents the majority of the workload, so use cases can be applied to express the majority of the requirements for the system. Each identified use cases defines the needed behaviors of the system from the perspective of a particular class of user. As such, the technique is very useful in eliciting user needs and helps the development team represent these needs in a manner that is readily understandable by the user.
Also, as the use cases can be used later in the design and the testing processes, they provide a consistent representation and a consistent thread through the requirements, analysis, design, and testing activities. In this way, the technique builds early, reusable project assets, which helps improve the overall efficiency of the software development process. In addition, with the consistency of representation and the support provided within the UML and various application development tools, use cases can help in automating many elements of the requirements management activity. For these reasons, use cases are such an important notion that we will apply them from this point forward as an integral part of the team's requirements management activities.