17. Use Cases
Use cases are a wonderful idea that has been vastly overcomplicated. Over and over again, I have seen teams sitting and spinning in their attempts to write use cases. Typically, such teams thrash on issues of form rather than substance. They argue and debate over preconditions, post-conditions, actors, secondary actors, and a bevy of other things that simply don’t matter.
The real trick to use cases is to keep them simple. Don’t worry about use case forms; simply write them on blank paper or on a blank page in a simple word processor or on blank index cards. Don’t worry about filling in all the details. Details aren’t important until much later. Don’t worry about capturing all the use cases; that’s an impossible task.
The one thing to remember about use cases is: Tomorrow, they are going to change. No matter how diligently you capture them, no matter how fastidiously you record the details, no matter how thoroughly you think them through, no matter how much effort you apply to exploring and analyzing the requirements: Tomorrow, they are going to change.
If something is going to change tomorrow, you don’t need to capture its details today. Indeed, you want to postpone the capture of the details until the last possible moment. Think of use cases as just-in-time requirements.
Writing Use Cases
Note the title of this section. We write use cases; we don’t draw them. Use cases are not diagrams. Use cases are textual descriptions of behavioral requirements, written from a certain point of view.
“Wait!” you say. “I know UML has use case diagrams, I’ve seen them.”
Yes, UML does have use case diagrams. However, those diagrams tell you nothing at all about the content of the use cases. They are devoid of information about the behavioral requirements that use cases are meant to capture. Use case diagrams in UML capture something else entirely.
A use case is a description of the behavior of a system. That description is written from the point of view of a user who has just told the system to do something in particular. A use case captures the visible sequence of events that a system goes through in response to a single user stimulus.
A visible event is one that the user can see. Use cases do not describe hidden behavior at all. They don’t discuss the hidden mechanisms of the system. They describe only those things that a user can see.
Typically, a use case is broken up into two sections. The first is the primary course. Here, we describe how the system responds to the stimulus of the user and assume that nothing goes wrong.
For example, here is a typical use case for a point-of-sale system.
Check Out Item:
- Cashier swipes product over scanner; scanner reads UPC code.
- Price and description of item, as well as current subtotal, appear on the display facing the customer. The price and description also appear on the cashier’s screen.
- Price and description are printed on receipt.
- System emits an audible “acknowledgment” tone to tell the cashier that the UPC code was correctly read.
That’s the primary course of a use case! Nothing more complex is necessary. Indeed, even that tiny sequence might be too much detail if the use case isn’t going to be implemented for a while. We wouldn’t want to record this kind of detail until the use case was within a few days or weeks of being implemented.
How can you estimate a use case if you don’t record its detail? You talk to the stakeholders about the detail, without necessarily recording it. This will give you the information you need to give a rough estimate. Why not record the detail if you’re going to talk to the stakeholders about it? Because tomorrow, the details are going to change. Won’t that change affect the estimate? Yes, but over many use cases, those effects integrate out. Recording the detail too early just isn’t cost-effective.
If we aren’t going to record the details of the use case just yet, what do we record? How do we know that the use case even exists if we don’t write something down? Write the name of the use case. Keep a list of them in a spreadsheet or a word processor document. Better yet, write the name of the use case on an index card, and maintain a stack of use case cards. Fill in the details as they get closer to implementation.
Alternate Courses
Some of those details will concern things that can go wrong. During the conversations with the stakeholders, you’ll want to talk over failure scenarios. Later, as it gets closer and closer to the time when the use case will be implemented, you’ll want to think through more and more of those alternative courses. They become addenda to the primary course of the use case. They can be written as follows.
UPC Code Not Read:
If the scanner fails to capture the UPC code, the system should emit the “reswipe” tone, telling the cashier to try again. If after three tries the scanner still does not capture the UPC code, the cashier should enter it manually.
No UPC Code:
If the item does not have a UPC code, the cashier should enter the price manually.
These alternative courses are interesting because they hint at other use cases that the stakeholders might not have identified initially. In this case it, appears necessary to be able to enter the UPC or price manually.
What Else?
What about actors, secondary actors, preconditions, post-conditions, and the rest? Don’t worry about all that stuff. For the vast majority of the systems you will work on, you won’t need to know about all those other things. Should the time come that you need to know more about use cases, you can read Alistair Cockburn’s definitive work on the topic.1 For now, learn to walk before you learn to run. Get used to writing simple use cases. As you master them—defined as having successfully used them in a project—you can ever so carefully and parsimoniously adopt some of the more sophisticated techniques. But remember, don’t sit and spin.
Diagramming Use Cases
Of all the diagrams in UML, use case diagrams are the most confusing and the least useful. I recommend that you avoid them entirely, with the exception of the system boundary diagram.
Figure 17-1 shows a system boundary diagram. The large rectangle is the system boundary. Everything inside the rectangle is part of the system under development. Outside the rectangle are the actors that act on the system. Actors are entities outside the system and provide the stimuli for the system. Typically, actors are human users. They might also be other systems or even devices, such as real-time clocks.
Figure 17-1. System boundary diagram
Inside the boundary rectangle are the use cases: the ovals with names inside. The lines connect the actors to the use cases they stimulate. Avoid using arrows; nobody really knows what the direction of the arrowheads means.
This diagram is almost, but not quite, useless. It contains very little information of use to the programmer, but it makes a good cover page for a presentation to stakeholders.
Use case relationships fall into the category of things that “seemed like a good idea at the time.” I suggest that you actively ignore them. They’ll add no value to your use cases or to your understanding of the system and will be the source of many never-ending debates about whether to use «extends» or «generalization».
Conclusion
This was a short chapter. That’s fitting because the topic is simple. That simplicity must be your attitude toward use cases. If once you proceed down the dark path of use case complexity, forever will it dominate your destiny. Use the force, and keep your use cases simple.
Bibliography
[Cockburn2001] Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001.