Developing Use Case Diagrams
The primary use case consists of a standard flow of events in the system that describes a standard system behavior. The primary use case represents the normal, expected, and successful completion of the use case.
When diagramming a use case, start by asking the users to list everything the system should do for them. This can be done using interviews, in a joint application design session (as described in Chapter 4), or through other facilitated team sessions. The analyst may also use agile stories sessions (described in Chapter 6) to develop use cases. Write down who is involved with each use case, and the responsibilities or services the use case must provide to actors or other systems. In the initial phases, this may be a partial list that is expanded in the later analysis phases. Use the following guidelines:
- Review the business specifications and identify the actors involved.
- Identify the high-level events and develop the primary use cases that describe those events and how the actors initiate them. Carefully examine the roles played by the actors to identify all the possible primary use cases initiated by each actor. Use cases with little or no user interaction do not have to be shown.
- Review each primary use case to determine the possible variations of flow through the use case. From this analysis, establish the alternative paths. Because the flow of events is usually different in each case, look for activities that could succeed or fail. Also look for any branches in the use case logic in which different outcomes are possible.
If a context-level data flow diagram has been created, it can be a starting point for creating a use case. The external entities are potential actors. Then examine the data flow to determine if it would initiate a use case or be produced by a use case.
Figure shown below is an example of a use case diagram representing a system used to plan a conference. The actors are the Conference Chair, responsible for planning and managing the conference, the conference Participant, Speakers, a Keynote Speaker, Hotel Reservations, and a Caterer. Actors represent the role the user plays, and the Caterer may be either a hotel employee or an external catering service.
Both the Conference Chair and the Caterer are involved in planning meals and banquets. The Conference Chair is also responsible for arranging speakers. The Participant registers for the conference. Notice that the Reserve Room use case is involved in an includes relationship with the Arrange Speaker and Register for Conference use cases, since both speakers and participants will need lodging. The Arrange Language Translation use case extends the Register for Conference use case because not all participants will require language translation services. The Speaker actor is a generalization of Keynote Speaker.
Developing Use Case Scenarios
Each use case has a description. We will refer to the description as a use case scenario. As mentioned, the primary use case represents the standard flow of events in the system, and alternative paths describe variations to the behavior. Use case scenarios may describe what happens if an item purchased is out of stock, or if a credit card company rejects a customer’s requested purchase.
There is no standardized use case scenario format, so each organization is faced with specifying what standards should be included. Often the use cases are documented using a use case document template predetermined by the organization, which makes the use cases easier to read and provides standardized information for each use case in the model.
