Telling the Use-Case Story
In Chapter 8, we give a basic definition of a use case as an actor-initiated, complete, system behavior that brings value to the actor. Chapter 8 also presents some techniques to help you find and identify these use cases, culminating in naming your use cases and placing them on use-case diagrams, as shown in Figure 9-1. However, just naming the behavior does not tell the whole story; you need more.
Figure 9-1: A use-case diagram for the use case Make Room Reservation.
All approaches to defining a use case’s behaviors are more or less the same as detailing how the system responds to actor-initiated triggers—and ultimately delivers the value back to the actor. That plot and theme bind the use case together.
Describing the use case
The simplest way to describe a use case (and normally the first one tried) is to identify the theme of the use case in a simple sentence or two—the use-case description. Given the use case Make Room Reservation, you might describe the plot and theme as follows:
Use-case name: Make Room Reservation
Description: The actor Potential Guest uses a Web browser to specify desired room features and dates, in order to obtain from the system a confirmed room reservation.
The use-case description you write is, in essence, a simple synopsis or abstract of the use-case story. It explains the goals, plot, and theme of the use case when just the use-case name will not. But, it is not the full story; an abstract needs a body. An abstract may stand for the body under some circumstances. As with any abstract, the use-case description may stand in lieu of the use-case story when there is no room for the full version—or during iterative development (before the full story has been written)—but the full story must also be done.
 |
While there are many templates and guidelines that give overall good sample formats of the use-case description, they often suggest a simple miswording that may lead you down the wrong path. You may see samples that start something like, “This use case describes how the system . . . .”
This leads you to think that a use case is a document as it describes a behavior. I believe that this is confusing on several levels. In a typical iterative development, you have several different documents that describe the same use case—each made at a different level of detail. The documents describe the use case; they are not the use case itself.
This simple confusion between the use case itself and the use-case description sometimes leads to a more fundamental error. Use cases are primarily artifacts of analysis and discovery. By looking at your system, you can discover or uncover the existing use cases—the ones that are there whether you notice them or not. However, when you talk about them as documents or descriptions, they may lead you to think that use cases are artifacts of design, subject to the arbitrariness of ingenuity and creativity and convenience, and that any use-case arrangement will suffice. A word to the wise: While there is certainly room for leeway in naming and organizing your use cases, it doesn’t justify sloppy use cases.
|
Recounting the use-case narrative
You have many choices and techniques to capture the full behavior of the use cases. Most developers use a combination of approaches to show all the aspects of the required behavior in the use case, and do so incrementally, starting with less formal textual approaches and iteratively use more formal specification approaches. You can choose a mix of formal statements-of-requirements (such as, “The system shall provide the capability to reserve rooms up to one month in duration”) or employ UML functional modeling techniques (such as the interaction diagrams and textual behavioral specifications outlined in Chapter 11).
The level of formality you stop at depends on the level of formality that your development needs or wants. Not every organization needs the full treatment (which can, after all, be time-consuming).
The most basic approach you can take to capture the use-case behavior is a narrative paragraph form where you describe the interaction between the actor and the system as if it were a story.
First, identify the actor’s triggering behavior, and then describe the system’s response. Repeat this for every future action by the actor and follow it by the system’s response. Describe alternatives or exceptions as they can occur, though significant variations can be described in other paragraphs. End the narrative when the actor achieves his/her goal.
Separating analysis from design
Most developers use use cases as artifacts of analysis. Use cases should be used to specify the required behaviors of your system not to capture design of your system. Design decisions change often; implementations change even oftener. By separating the requirements from the design, you allow the use cases to be a stable definition of what your system must do to be successful. They become part of your agreement with your stakeholders—that if you produce a system that delivers these use cases, they will be happy (and pay for it). You can then do whatever you want to design and implement the system—knowing that if you make the use case work, you’re okay. Putting design details in the use case, however, means that if you change your mind about the design, you have to change the use case—and go back to your stakeholders for approval.
Separating analysis from design also frees your test team to start developing their test plans directly from the use cases—knowing that the use case will be (relatively) stable, knowing that they will be able to test the functionality of the system directly from the use case.
To concentrate on the required visible, testable behavior of the system, we recommend you follow these guidelines in your use cases:
-
Tell what happens and when, but ignore the how.
-
Use the actor’s terminology and perspective.
-
Don’t describe any internal workings of the system, unless they are ultimately visible to an actor. Treat the system as a black box whose inside is hidden.
-
Cover the major alternatives, exceptions, and looping in activity of the interaction with the actor and system.
-
Start with “This use case starts with the actor performs X,” where X is the triggering action.
-
End with “This use case ends when the actor is satisfied with the behavior of the system or is unable to continue.”
You should have the goal to describe the required behavior of the system without saying how it is to be done, as in the following use-case narration:
Use-case name: Make Room Reservation
Description: This use case allows the actor, Potential Guest, to use a Web browser to specify the desired room features and dates and to obtain from the system a confirmed room reservation.
Narration: This use starts when the actor, Potential Guest, visits the opening Web page. The system responds by prompting for the span of reservation days and the room type. The actor identifies the type of room that is desired (bed size, is-smoking allowed) and the desired reservation day span. The system validates the inputs and prompts for re-entry if incorrect. The system then checks to see if a room matching the actors request is available during the day span specified and returns this to the actor. If several different classes of rooms are available, they are all returned to the actor. If none match the actor’s criteria, the actor may re-specify or may exit the use case. If one or more rooms meet the actor’s criteria, the actor selects the room desired. The system prompts for payment information. The actor supplies name, billing address, credit card number, and expiration date. The system contacts the other actor, Credit Card Authorization System, to validate the credit card and available credit. If the credit card transaction is rejected, the System informs the Potential Guest, who may then change the card or cancel the use case. If the credit card transaction is accepted, the System marks the room as reserved over this time period to prevent subsequent reservations, calculate a unique reservation number, and informs the Potential Guest. The use case ends when the actor reviews the successful reservation and leaves the System. If the actor cancels before submitting acceptable credit card information, the use case ends without a successful reservation.
This narration form is often the first approach used to specify the behavior of a use case. However, many ultimately prefer an approach that breaks the flow of events into individual numbered actions so that they are easier to see and refer to when necessary. A typical approach that works this way is called the use-case flow of events. This approach allows you to clarify whether an event is actor- or system-initiated, using indentation or numbering. The top-level statements describe the actions that the actor performs. The indented, lower-level statements describe the responses of the system. The following is a partial example of this technique:
Use-case name: Make Room Reservation
Description: This use case allows the actor, Potential Guest, to use a Web browser to specify the desired room features and dates and to obtain from the system a confirmed room reservation.
Main course:
-
This use case starts when the actor visits the opening Web page.
1.1 The System prompts for the span of reservation days and room type.
-
The actor identifies type of room (bed size and smoking or non- smoking) and reservation day span.
2.1 The System validates inputs.
2.2 The System determines available matching room classes.
2.3 For each available room class, the System determines reservation costs.
2.4 The System displays possible reservations.
2.5 The System prompts for actor selection.
-
The actor identifies type of room (bed size and smoking or non- smoking) and reservation day span.
3.1 . . .
We generally recommend writing the narration first—and having that reviewed by your stakeholders before you construct the flow of events. Afterward you may be able to discard the narration.
One important consideration using this flow of events approach is that a flow captures only one path throughout the system. As you use the numbering and indentation to convey order and initiator, they are not available to you to indicate looping or decision. Therefore, when using the flow of events approach to documenting a use case, you will need to use multiple different flows or courses to document the entire use case. You start with documenting the main course. This is the course of events that is the most common and straightforward approach to achieve the actor’s goals with the use case. (You may also hear the main course called the main flow or main path through the use case.)
Setting pre- and postconditions
Most use case specification templates will ask you to supply pre- and postconditions for the course of events. The preconditions specify the state of the world that must hold before the course can be triggered. The postconditions specify the state of the world the will hold after the course has been successfully completed.
When documenting the main course of most use cases, we have found that the preconditions are often simple as they just tell where the actor must be to start the use case. Likewise, the postconditions of the main course may also be simple if they are just statements that the actor’s goals have been reached. However, sometime the conditions can be very complex, especially when describing the conditions for alternate or error flows. You can see some examples of not-too-complex pre- and postconditions in the section “Indicating Alternative Courses of Behavior.”
We normally use natural language statements to capture constraints on the world, but we often find it useful to be more formal if the English could be ambiguous. In these circumstances, you might use Object Constraint Language (OCL) to indicate formal relationships among objects and attributes from the domain model. (You can find more about using OCL in Chapter 11.) For even more clarity, you may consider drawing object diagrams. We discuss these diagrams as the underpinning of collaboration diagrams in Chapter 14.
|
Occasionally people will refer to the use-case main course as the Happy Path. We believe that the term Happy Path, despite its popularity, is often inappropriate and should be avoided. The adjective happy is a matter of opinion and has to do with interpretation of whether the actor’s desired goal is also desirable. There are many circumstances in which happy will be incongruous, such as Cancel Reservation, Close Hotel, or (more darkly) Execute Prisoner. Generally, you will be more professional if you avoid value judgments in your terminology.
|
EAN: 2147483647
Pages: 193