Chapter 3. Use Cases

Use cases are interesting phenomena. For a long time, in both object-oriented and traditional development, people used typical interactions to help them understand requirements. However, these scenarios were treated very informallyalways done but rarely documented. Ivar Jacobson is well known for changing this with his Objectory method and associated book (his first one).

Jacobson raised the visibility of the use case to the extent that it became a primary element in project development and planning. Since his book was published (1992), the object community has adopted use cases to a remarkable degree. My practice has certainly improved since I started using use cases in this manner.

So what is a use case?

I won't answer this question head-on. Instead, I'll sneak up on it from behind by first describing a scenario.

A scenario is a sequence of steps describing an interaction between a user and a system. So if we have a Web-based on-line store, we might have a Buy a Product scenario that would say this:

The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up email.

This scenario is one thing that can happen. However, the credit card authorization might fail. This would be a separate scenario.

A use case, then, is a set of scenarios tied together by a common user goal. In the current situation, you would have a Buy a Product use case with the successful purchase and the authorization failure as two of the use case's scenarios. Other, alternative paths for the use case would be further scenarios. Often, you find that a use case has a common all-goes-well case, and many alternatives that may include things going wrong and also alternative ways that things go well.

A simple format for capturing a use case involves describing its primary scenario as a sequence of numbered steps and the alternatives as variations on that sequence, as shown in Figure 3-1.

Figure 3-1. Example Use Case Text

There is a lot of variation as far as how you might describe the contents of a use case; the UML does not specify any standard. There are also additional sections you can add. For example, you can add a line for preconditions, which are things that should be true when the use case can start. Take a look at the various books that address use cases, and add the elements that make sense for you. Don't include everything, just those things that really seem to help.

An important example of this is how you divide up use cases. Consider another scenario for on-line purchase, one in which the purchaser is already known to the system as a regular customer. Some people would consider this to be a third scenario, whereas others would make this a separate use case. You can also use one of the use case relationships, which I'll describe later.

The amount of detail you need depends on the risk in the use case: The more risk, the more detail you need. Often I find that I go into details only for a few use cases during elaboration, and the rest contain no more than the use case in Figure 3-1. During iteration, you add more detail as you need it to implement the use case. You don't have to write all of the detail down; verbal communication is often very effective.