Page 67 -

34 Part 1 • SyStemS analySiS FundamentalS

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 comple-
tion 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:
1. Review the business specifications and identify the actors involved.
2. 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 iden-
tify all the possible primary use cases initiated by each actor. Use cases with little or no
user interaction do not have to be shown.
3. 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 usu-
ally 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 2.15 is an example of a use case diagram representing a system used to plan a con-
ference. 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 par-
ticipants 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 men-
tioned, 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 speci-
fying 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.

Use Case Levels
You may want to create use cases for different levels. One method (defined by Alistair Cockburn)
uses the following altitude metaphors:

1. White is the highest level, like clouds. This is the enterprise level, and there may be only
four to five uses cases at this level for the entire organization. Examples might be to adver-
tise goods, sell goods to customers, manage inventory, manage the supply chain, and opti-
mize shipping.
2. Kite is lower than white but still a high level, providing an overview. The kite use case
may be at the business unit or department level and is a summary of goals. Examples