This page is an excerpt from Chapter 3 of Use Case Driven Object Modeling with UML - Theory and Practice.
With an initial domain model in place, it’s time to begin writing use cases. Use cases give you a structured way of capturing the behavioral requirements of a system, so that you can reasonably create a design from them. They help you to answer some fundamental questions: What are the users of the system trying to do? What’s the user experience? A surprising amount of what your software does is dictated by the way in which users must interact with it.
The use case is written in the context of the domain model—that is, all the terms (nouns and noun phrases) that went into the domain model should also be used directly in your use case text. The ICONIX approach assumes that the initial domain model is wrong and provides for incrementally improving it as you analyze the use cases. That’s why you should spend only a couple of hours at most on domain modeling before you begin use case modeling.
How to Write a Use Case: The Three Magic Questions
When writing use cases, you need to keep asking the following three fundamental questions:
- What happens?
(This gets your “sunny-day scenario” started.) - And then what happens?
(Keep asking this question until your “sunny-day scenario” is complete.) - What else might happen?
(Keep asking this one until you’ve identified all the “rainy-day scenarios” you can think of, and described the related behavior.)
Elements of Use Case Style
Write your use cases:
- In the context of the domain model
Repeat this mantra at least a hundred times before breakfast:You can’t drive object-oriented designs from use cases unless you tie your use cases to objects.
In practical terms, this means that you need to reference domain classes that participate in the use case, and you need to name your screens and other boundary objects explicitly in the use case text. Otherwise, your behavior requirements will be completely disconnected from your object model, and (surprise!) you won’t be able to drive designs from the use cases.
- In active voice, present tense
To illustrate what can go wrong with a use case, here’s a passively worded example:The capability is provided for users to log in, using a password-protected authorization scheme.
The problem with passive sentences is that they hide the actor(s) and, more important, the software functions. The sentence just doesn’t tell you. See the active-voice rewrite further down this page. Active sentences make clear who does what, and they keep readers awake. Use active sentences and write from the user’s perspective, and your use cases will be sharper and less likely to be misconstrued.
- Using an event/response flow
A use case really describes a dialogue between a user and the system. You need to write about the user side of the dialogue to keep your behavior requirements firmly user-focused, but it’s not sufficient to just write down what the user does. Ultimately you’re trying to spec software, and software really consists of the system’s behavior. So it’s vitally important to describe both sides of the dialogue between the user and the system in every use case.
Here’s an active-voice rewrite of that passively-worded use case. Notice how this example also follows an event/response flow, triggered by a system-initiated event (i.e. the system displays the Login screen):
The system displays the Login screen. The user enters her username and password, and then clicks the Login button. The system looks up the user profile using the username and checks the password. The system then logs in the user.
Remember this is just the basic course—the sunny-day scenario that assumes everything goes correctly. You would also expect to see some alternate courses, e.g. describing what happens if the username or password weren’t found.
To sum up: You want to write the kinds of use cases that can be used to drive a software design. Use cases give you something that you can design from, and from which you can reliably estimate time and effort. While some use case books treat use cases as more of an abstract requirements specification technique, we see use cases as the first step toward doing a good object-oriented design and as a means to help you get quickly to high-quality code.
Once you’ve got your first-pass use cases in place, perform a requirements review to make sure the system as described genuinely matches up with the customer’s requirements. (We illustrate how to perform effective requirements reviews in our book). Then, you can safely move on to the preliminary design (robustness analysis), which bridges the chasm between analysis and detailed design.
