A Step-by-Step Guide to Building the Use-Case Model


An individual use case describes how a particular actor interacts with the system to achieve a result of value for that specific actor. The set of all use cases together describes the complete behavior of the system. However, we don't determine the behavior of the system by first writing individual use cases and then adding them all up. Instead, we first build a context model of the system and then successively refine this model until the detailed behaviors are understood , but each of these behaviors (use cases) is refined only within the overall context of the system. The complete set of use cases, actors, and their interactions constitutes the use-case model for the system.

Building the use-case model for the system is an important analysis step, one that will become the basis for understanding, communicating, and refining the behavior of the system over the course of the entire project. Building and refining the use-case model is not a one-time project event. A fundamental premise of iterative development is that "you don't know what you don't know," and this drives a process of continuous refinement wherein each phase of development advances the model to the next level of detail. In addition, as this happens, the model is refactored, new use cases are discovered , they in turn are refined, and the process continues until your model is fully refined.

By then, much of it will already be implemented in code! While there is no one perfect process for developing the model, we have found a simple five-step approach to be effective. However, as we've said earlier, these steps do not all happen at the same point in the project lifecycle, and the iterative nature of development dictates that some steps will be revisited over time.

Step 1: Identify and Describe the Actors

The first step in building the use-case model is to identify all the actors that interact with our system. After all, since a use case provides a result of value to an actor, there can be no use case that doesn't interact with something. As we described in Chapter 7, this is a matter of dividing the world into two classes of interesting things: our system and those things (actors) that interact with our system. Returning to our HOLIS case study, in Chapter 7 we identified six different actors that interacted with the HOLIS Central Control Unit.

To find the actors that interact with your system, think about the following questions.

  • Who uses the system?

  • Who gets information from this system?

  • Who provides information to the system?

  • Where in the company is the system used?

  • Who supports and maintains the system?

  • What other systems use this system?

Step 2: Identify the Use Cases and Write a Brief Description

Once the actors are identified, the next step is to identify the various use cases that the actors need to accomplish their jobs. We can do this by determining the specific goals for each actor in turn.

  • What will the actor use the system for?

  • Will the actor create, store, change, remove, or read data in the system?

  • Will the actor need to inform the system about external events or changes?

  • Will the actor need to be informed about certain occurrences in the system?

In our case study, we might discover use cases such as "program vacations settings" and "set clock" since these are important things that a resident (actor) might want to do with the system. If we place these in a simple diagram, it might look like Figure 14-2.

Figure 14-2. Use cases for the Homeowner /Programmer actor


You should consider the use-case name carefully . Typically, the name is a few words or a short phrase that starts with an action verb and communicates what the actor achieves with the use case. The use case names by themselves help communicate what the system does and quickly become a part of the project "lingo."

Along with the name, you should provide a brief description that elaborates the intent of the use case. For example, at this point, you might have the following mini-template for an identified use case.


Step 3: Identify the Actor and Use-Case Relationships

While we've noted that only one actor can initiate a use case, you'll also discover that many use cases involve the participation of multiple actors. When the actors and use cases interact in concert, that's when the system becomes a system. In this step in the process, each use case is analyzed to see what actors interact with it, and each actor's anticipated behavior is reviewed to verify that the actor participates in all the necessary use cases and thereby achieves all the results the actor needs to be successful with the system. In a system of any scope, this can become complex fairly quickly with a large number of use cases and actors, so you'll almost certainly want to represent this part of the model pictorially. That way, a user , analyst, or other reviewer can "see" the overall system behavior at one time and thereby better understand what is being proposed.

Step 4: Outline the Individual Use Cases

The next step is to outline each use case so you can start to gain an understanding of required system behavior at the next level of detail. As you do so, you also start to understand various alternatives and events that can occur as part of the systems operation. Of particular interest at this time is the flow of events, including the basic and alternate flows.

Typically, you will outline the basic flow first. There is only one basic flow (the straight line path on the diagram to the left), the flow that represents the most common path from start to finish through the system. (Some call this the "happy day" flow since there are no problems and no exceptions on this path .)


In addition to the basic flow, you will also typically have a number of alternate flows (the curved paths on the diagram) based on both regular circumstances (the homeowner chooses a factory default vacation program) and exceptional events (the homeowner cancelled the programming effort in order to respond to the doorbell). In order to discover these paths, ask the following questions.

Basic flow :

  • What event starts the use case?

  • How does the use case end?

  • How does the use case repeat some behavior?

Alternate flow :

  • Are there optional situations in the use case?

  • What odd cases might happen?

  • What variants might happen?

  • What may go wrong?

  • What may not happen?

  • What kind of resources can be blocked?

Step 5: Refine the Use Cases

At some point later in the project lifecycle, the time will be right to refine the use cases to the next and last level of detail. At that time, there are a number of additional factors to be considered , and each will play a role in the refinement process.

  • All alternate flows, including exception conditions : It is fairly straightforward to identify the primary alternate flows of a use case since these are mostly driven by explicit user choices. However, in software development, the "what ifs" become a primary source of concern, and these must be fully explored in alternate flows. "What if the remote server is down?" "What if the resident is programming the system when an intrusion alarm occurs?" All these exceptions must be documented in the use case or the application may not behave as expected.

  • Pre- and post-conditions : The refinement process will start to identify state information that controls the behavior of the system. This state information is captured in the pre- and post-conditions for the use case. Pre-conditions describe the things that must be true before a use case starts. For example, a pre-condition to programming vacation settings might be that the user has set the calendar clock. If that has not been done, the use case cannot be called on to be executed. Post-conditions describe the persistent states the use case leaves behind. For example, the programmed vacation schedule, which reflects that actual input by the homeowner, must be saved by the system so as to be recalled for later use.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net