In Team Skills 1 and 2, we introduced use cases, another technique for expressing requirements for a system. This technique has achieved a degree of popularity and common use.
It can be argued that the use-case technique has certain inherent advantages over the traditional approach to defining individual, discrete (declarative) software requirements.
Use cases are relatively easy to write.
Use cases are written in the language of the user.
Use cases provide related, cohesive threads of behavior, or scenarios, that can be understood by both the user and the developer.
Because of the "thread of behavior" characteristic and the fact that the UML includes certain specialized elements and notations for use in modeling, use cases provide additional added value by linking the requirements activities to design and implementation. (We'll discuss this further in Chapter 30.)
The graphical representation of use cases within the UML and support by various modeling tools provide a visual means of expressing the relationships among use cases, which can improve understandability of a complex software system.
A scenario described by a use case can be used almost directly as a test script at validation time.
You should consider using them for capturing the majority of the requirements for the system if either or both of the following aspects apply to your application
The system is functionally oriented, with both varied types of users and functional behavior. Since use cases describe the behavior of the system for each type of user, they are most powerful when there are many types of system users and the system needs to deliver different types of functionality for each type of user.
Your project team is implementing the system, using the UML and object-oriented (OO) methods. Certain OO concepts, such as inherited behavior among actors and use cases, abstract actors, lend themselves well to the use-case method and deliver additional utility to the analyst or modeler. The UML notation for use cases also supports visual modeling of the system and provides a modeling paradigm that supports the representation of the needed behavior of the system (the use case) and how that behavior is implemented within the software (via use-case realizations).
However, use cases are not well suited for certain types of systems and some types of requirements. Specifically, you may need to augment or perhaps even abandon the use cases for systems with the following characteristics.
Systems with Few or No Users and Minimal Interfaces . Many classes of systems are functionally rich but have few external interfaces and few users and therefore do not lend themselves as well to the use-case technique. Consider, for example, systems designed primarily to perform scientific calculations or simulations, embedded systems, process control systems, a virus-checking system that runs without operator interaction, and software utilities such as compilers and memory management programs. Again, although you can apply use cases in these applications, and although they will probably be useful in augmenting the traditional approach, there may be easier ways to express the majority of the requirements.
Systems Dominated Primarily by Nonfunctional Requirements and Design Constraints . As mentioned earlier, use cases can be poor containers for nonfunctional requirements—the attributes of the system and of the system environment, special requirements, and design constraints we discussed earlier. In fact, use cases have a "special requirements" pigeonhole for inserting these types of requirements. This works well when you are applying these types of requirements to one or a few use cases, but in general, not all such requirements relate well to a specific use case.
Other, global nonfunctional requirements are generally not good candidates for use-case capture: legal and regulatory compliance requirements, operating environments, and software development standards. (For example, at Rational, one specification is used solely to define the requirements for globalization of software products. These requirements consist almost entirely of constraints that govern the design of the software so as to make translations into other languages feasible and cost-effective. Use cases are needed only to describe the limited patterns of usage implied, such as a "French-speaking person using the German OS.")
Use cases can also lead to a significant redundancy of expression that increases the size of the requirements documentation. The reason is that many use cases are very similar yet distinct enough to require separate expression. In addition, maintenance can then be a challenge when the common behavior, expressed in many use cases, must be changed. In this latter case, there are additional use-case relationships, such as generalization, include-relationships, and extends-relationships that you can use to reduce redundancy (Booch 1999).
However, the use of these relationships adds complexity in its own right, and there may be a point of diminishing returns if the behavior can be readily expressed in other ways. And yes, some relatively complex behaviors can be expressed more simply in natural language (for example, "When the system is in the ready state, and two officers each depress the launch button and hold it for more than 1 second, the missile will launch"). Yes, you can hammer the use cases into submission in these cases, but the goal is to pick the best technique for the circumstances, one that provides ease of expression and understandability, not to use them because you think you have to. In most projects, you will probably want to use a mix of use cases and traditional methods to create the optimum approach.
In this chapter, we'll build on what we learned in Chapters 2 and 13 and apply the use-case technique again to refine the system specification. This is convenient, as the use cases derived in the earlier activities can be revisited and elaborated on here. Depending on the level of specificity achieved in the elicitation process, the use cases developed earlier may be sufficiently detailed to drive design and implementation. It's more likely, however, and it is recommended, that an appropriately high level of abstraction in the elicitation process was maintained so you don't become bogged down in detail at that stage of the process. Also, you probably didn't define all of the use cases that would be needed or detail the exception conditions, state conditions, and other special conditions that are of less interest to the user but that may materially affect the design of the system. The time to add this additional level of specificity is now.
Note
It is not the intention of this book to provide a full course on use cases. If you are interested in becoming more fully versed in the methodology and its supporting tool technologies, two good books on the subject are Schneider and Winters (1998) and Jacobson (1999). Nevertheless, we will review a few basic principles of the use-case methodology.
To add specificity, we'll need to take a more rigorous approach to the use-case technique so you can gain a better understanding of some of the nuances. Let's look at the definition of use cases one last time, focusing on what the UML has to say about them: "A use case is a description of a set of actions, including variants, that a system performs that yields an observable result of value to a particular actor" (Booch 1999).
Whew! That looks like a bunch of lawyers wrote the definition![1] As we've described earlier, the use-case methodology identifies two elements that will be present in all use-case instances.
Use case. . The UML represents the use case with an oval. Even though the use case is a textual description, the icon serves as a shorthand aid that helps us model the system visually and show interactions between use cases and other modeling elements.
Actors. . An actor is someone or something that interacts with our system. There are only three types of actors: users ("Bill the technician"), devices ("the robot arm motor controller"), and other systems ("the HOLIS CCU controller"). Actors are not part of the system being described but live outside of the system boundary.
Let's look at some of the other key phrases in the UML definition: "A use case is a description of a set of actions, including variants, that a system performs that yields an observable result of value to a particular actor."
Variants. . A use case describes a basic flow, or thread, as well as variants, or alternative flows.
A set of actions. . The set of actions describes a function performed or perhaps an algorithmic procedure that produces a result; the set is invoked when the actor initiates the use case by providing some input to the system. An action is atomic; that is, it is performed either entirely or not at all. By the way, the atomicity requirement is a strong determinant in selecting the level of granularity of the use case. You should examine the proposed use case, and if the action is not atomic, then the level of granularity should be reduced to a finer level of detail.
System performs. . This means that the system provides the functionality described in the use case. It's what the system does, based on the input it is given.
An observable result of value. . It is important to note that the result of the use case must be "of value" to a user. Therefore, "the resident pushes the light button" is not a valid use case; (the system didn't do anything for the user.) But "the resident pushes the light button and the system turns the light on" is a meaningful use case and is more likely to motivate the resident to interact with the system!
A particular actor. . The particular actor is the individual or device (Linda the resident; the signal from the emergency button) that initiates the action (toggle the light or activate security alarm).
In the early iterations of Team Skill 3, Defining the System, most of the major use cases have been identified, but only a few—perhaps those considered architecturally significant or particularly descriptive of the system behavior—are well described. These use cases might typically be done as an elaboration of the Vision document, which describes how the features expressed are intended to be used.
The refining process completes all use cases needed to define the system. The test for "enough" use cases is that the complete collection of use cases describes all possible ways in which the system can be used, at a level of specificity suitable to drive design, implementation, and testing.
It's worth pointing out that use case elaboration is not system decomposition. That is, we don't start with a high-level use case and decompose it into more and more use cases. Instead, we are searching for more and more detailed actor's interactions with the system. Thus, use-case elaboration is more closely aligned with refining a series of actions rather than hierarchically dividing actions into subactions. Your model will often have use cases that are so simple that they do not need a detailed description of the flow of events; a simple outline is quite enough. The criteria for making this decision are that users don't disagree on what the use case means and that designers and testers are comfortable with the level of detail provided by the simple format.
It is often difficult to decide whether a set of user system interactions, or dialog, is one or several use cases. Consider the use of a recycling machine: The customer inserts cans and bottles into the recycling machine, presses a button, and received a printed receipt that can be exchanged for money.
Is it one use case to insert a deposit item and another use case to require the receipt? Or is it all one use case? Two actions occur, but one without the other is of little value to the customer. Rather, it is the complete dialog, with all of the insertions and getting the receipt, that is of value and makes sense to the customer. Thus, the complete dialog—from inserting the first deposit item, pressing the button, and getting the receipt—is a complete instance of use, a use case.
Additionally, you want to keep the two actions together, to be able to review them at the same time, modify them together, test them together, change them together when necessary, write user documentation that describes them, and, in general, manage them as a unit. This becomes particularly important in larger systems.
Let's look at a step-by-step procedure for defining a use case. We'll use a simple HOLIS example: a resident activating a light in a house, using the HOLIS home automation lighting system.
We first need to decide and to define exactly who is to interact with the use case. In many systems designed for users, we should first look to identifying the humans who will use the system. In our use case, the homeowner interacts with the system to control the light in a room. So only one actor is discovered, the user (Resident) pressing the switch.
Tip
As you work your way through the determination of actors in the project, it will be helpful to maintain an "actor list" so that you can readily refer to actors already defined and avoid accidentally creating an actor again, using a different name.
Each use case should have a name indicating what is achieved by its interaction with the actor(s). The name may have to be several words to be understood. No two use cases can have the same name.
You should consider the name carefully. It should be unique and easily distinguishable among the use cases defined for the project. Use-case names often begin with an action verb to indicate the intent of the use case. We will name our use case Control Light.
Also, you may want to structure the name in a formal method so as to group similar use cases into similarly named groupings. Or, you may want to incorporate a "serial number" or other unique identifier into the use-case name to facilitate managing a list of the use cases. For example, a designer might specify the name of this use case as "031 Control Light." But, although the spirit of this approach is laudable, our experience has shown that proper use-case naming, and perhaps application of tools that allow us to search, sort, and analyze use cases, are usually adequate to the task.
A brief description of the use case should reflect its role and purpose. As you write the description, refer to the actors involved in the use case and the glossary. If you need to, define new concepts.
This description is intended as an informal overview of the functionality. A later section, Flow of Events, will be the spot where you can write a detailed description of the full functionality. The use-case description is intended to give a "quick look" and nothing more. In our use case, we might describe the use case as follows:
Use Case Description for Control Light
This use case prescribes the way in which lights are turned on or off or are dimmed by how long the user presses a light switch in various manners.
The heart of the use case is the event flow, usually a textual description of the operations by the actor and the system's various responses. Therefore, the event flow describes what the system is supposed to do, based on the actor's behavior. By the way, it is not required that the flow be described textually. You can use UML interaction diagrams for this purpose, and many of the formal methods discussed in Chapter 28 might apply equally well to your use-case documentation, so be sure and select an appropriate technique. Remember, the goal is to convey understanding, and there is no "one-size-fits-all" approach. However, in most cases, you'll find that natural language works just fine.
The flow of events conveys the meat of the use case's purpose and is intended for viewing by a variety of audiences:
Customers, who approve the result and bless the functions
Users, who are the intended target for the system's actions
Use-case designers, who are interested in accurately capturing the system's intended behavior
Reviewers, who provide third-party perspective
Designers, who dissect the use cases, looking for design classes, objects, and so on
Testers, who need to construct test cases
Project manager, who needs to understand the entire project
Technical writer, who needs to document the system's functions in a user-friendly manner
Marketing and sales people, who need to understand the features of the product and explain its wonders to the outside world
You're probably saying to yourself, "I almost never find situations in which I can describe a simple flow of events that works every time. Many times, I need a way to describe some alternative flows." Fear not. The determination of a use-case flow allows for alternative flows. But first, let's create a basic flow for our example.
Basic Flow for the Control Light Use Case . Note that the following flow of events does not specify how the system does any of those things. It specifies only what happens.
Basic flow begins when Resident presses any button on the Control Switch. If Resident removes pressure on the Control Switch within the timer period, the system "toggles" the state of the light.
If the light was on, the light is turned off, and there is no illumination.
If the light was off, the light is turned on to the last remembered brightness level.
End of basic flow.
Alternative Flow of Events: . In many cases, the use case may have different flows, depending on conditions present. In some cases, these flows deal with error conditions detected during processing, or they may record optional ways of handling certain conditions. For example, a use case that prints a receipt for a credit card transaction may discover that the printer has run out of paper. This special case would be described within the use case as an alternative flow of events. When you record the alternative flows, don't forget to document the conditions giving rise to the flows. There is no set limit on alternative flows, so be sure and document all alternative flows, including possible error conditions.
In our example, an alternative flow of events will occur when Resident holds a button on the Control Switch down for more than 1 second. So, we need to add an alternative flow to the use case.
Alternative Flow of Events: Dimming
If Resident keeps pressure on the Control Switch for more than 1 second, the system initiates a dimming activity for the indicated Control Switch button.
While Resident continues to press the Control Switch button,
The brightness of the controlled light is smoothly increased to a systemwide maximum value at a rate of 10 percent a second.
When the maximum value is reached, the brightness of the controlled light is smoothly decreased to a systemwide minimum value at a rate of 10 percent a second.
When the minimum value is reached, processing continues at subflow step 1.
When Resident ceases to press the Control Switch button,
The system ceases to change the brightness of the light.
In some cases, you will need to identify preconditions that affect the behavior of the system described in the use case and to describe postconditions, such as system state or persistent data that is left when the use case is complete. However, you need to use pre- and postconditions only when necessary to clarify the behavior expressed in the use case.
It is important to distinguish between events that start the use-case flows and preconditions, which must be met before the use-case flow can be initiated. For example, a precondition to the Control Light use case is that the homeowner (Resident) has enabled a specific bank of lights for the dimming action. Another precondition is that the selected Control Switch (CS) button must be preprogrammed to control a light bank. (Presumably, other use cases describe how these preconditions are accomplished.) So we'll need to state the preconditions.
Preconditions for Control Light Use Case
The selected Control Switch button must be "Dim Enabled."
The selected Control Switch button must be preprogrammed to control a light bank.
Similarly, you will often need to identify and include postconditions in your documentation. Postconditions allow you to specify the exact state that on use case exit must be true even if alternative paths are taken.
In order for the brightness to come on to the proper level when Resident uses the switch the next time, the system must remember the previous brightness level that was set for a selected Control Switch button after a dimming action has occurred. So, this is a postcondition that we'll record in the use case.
Postconditions for Control Light Use Case
On leaving this use case, the current brightness level for the selected Control Switch button is remembered.
Now let's put it all together. Table 24-1 outlines what we have after filling in all of the important pieces of our use case. (Although many other pieces can be defined for a use case, they are not important to our needs now.) This use case is documented in the narrative style and may be found in the HOLIS artifacts in Appendix A.
Table 24-1. Defining a use case
| Item | Value |
|---|---|
| Use case name | Control light |
| Brief description | This use case prescribes the way in which lights are turned on or off or are dimmed by the user's pressing a light switch in various manners. |
| Flow of events | Basic flow for the use case begins when Resident presses a button on the Control Switch (CS).
If Resident removes pressure on the CS within the timer period, the system "toggles" the state of the light. This means:
|
| Alternative flow of events | If Resident keeps pressure on the CS for more than 1 second, the system initiates dimming for the indicated light.
The following actions occur while Resident continues to press the CS button:
|
| Preconditions |
|
| Postconditions | On leaving this use case, the brightness of the light is remembered by the system. |
| Special requirements | The systemwide minimum light level cannot be 0. It should be an acceptably low value such that the controlled lights are adequate for night use. |
When all use cases have been discovered and elaborated at about this level of detail, the refining process is complete for those portions of the system that we decide to elaborate in use cases. In the next chapter, we'll look at organizing the specifications.
[1] It was actually a bunch of methodologists. Ivar Jacobson tells the following joke: Question: Do you know what the difference is between a methodologist and a terrorist? Answer: You can negotiate with a terrorist.