Finding actors is one of the first steps in defining system use. Each type of
external phenomenon with which the system must interact is represented by an
actor. To find the actors, ask the following questions:
Which user groups require help from the system to perform their tasks?
Which user groups are needed to execute the system's most obvious main
functions?
Which user groups are required to perform secondary functions, such as
system maintenance and administration?
Will the system interact with any external hardware or software system?
Any individual, group or phenomenon that fits one or more of these categories
is a candidate for an actor.
To determine whether you have the right (human) actors, you can try to name
two or three people who can perform as actors, and then see if your set of
actors is sufficient for their needs. For more on what constitutes an actor, see
Guidelines: Actor.
It may be difficult at first to find the most suitable actors, and you are
not likely to find all of them immediately because you have not found all the
use cases. Working with the use cases is the only thing that gives you a deeper
understanding of the system's environment and how it interacts with the system.
When you have progressed that far, you may want to revise your original model,
because there is a tendency at first to model too many actors. Be careful when
you change actors; changes that you introduce can affect the use cases as well.
Remember that any modification to the actors constitutes a major alteration in
the system's interfaces and behavior.
Name and Briefly Describe the Actors You Have
Found
The actor's name must clearly denote the actor's role. Make sure there will
be little risk at a future stage of confusing one actor's name with another.
Define each actor by writing a brief description that includes the actor's
area of responsibility, and what the actor needs the system for. Because actors
represent things outside the system, you need not describe them in detail. See
also the section Brief Description in Guidelines:
Actor.
Find Use Cases
When your first outline of the actors is complete, the next step is to look
for the system's use cases. The first use cases are very preliminary, and you
will doubtless have to change them a few times until they are stable. If the
system's vision or requirements are deficient, or if the system analysis is
vague, the system's functionality will be unclear. Therefore, you must
constantly ask yourself if you have found the right use cases. Furthermore, you
should be prepared to add, remove, combine, and divide the use cases before you
arrive at a final version. You will get a better understanding of the use cases
once you have described them in detail.
The best way to find use cases is to consider what each actor requires of the
system. Remember the system exists only for its users, and should therefore be
based on the users' needs. You will recognize many of the actors' needs through
the functional requirements made on the system. For each actor, human or not,
ask yourself the following questions:
What are the primary tasks the actor wants the system to perform?
Will the actor create, store, change, remove, or read data in the system?
Will the actor need to inform the system about sudden, external changes?
Does the actor need to be informed about certain occurrences in the
system?
Will the actor perform a system start-up or shutdown?
The answers to these questions represent the flows of events that identify
candidate use cases. Not all constitute separate use cases; some may be modeled
as variants of the same use case. It is not always easy to tell what is a
variant and what is a separate and distinct use case. However, it will become
clearer when you describe the flows of events in detail.
A system can have several possible use-case models. The best way to find the
"optimal" model is to develop two or three models, choose the one you
prefer, and then develop it further. Developing several alternative models also
helps you to understand the system better.
When you have outlined your first use-case model, you should verify that the
use-case model addresses all functional requirements. Scrutinize the
requirements carefully to ensure that all the use cases meet all the
requirements.
For more information on what a use case is and how to find them, see Guidelines:
Use-Case Model and Guidelines: Use Case.
Name and Briefly Describe the Use Cases You Have Found
Each use case should have a name that indicates what is achieved by its
interactions with the actor(s). The name may have to be several words to be
understood. No two use cases can have the same name. See also the section Name
in Guidelines: Use Case.
Define each use case by writing a brief description of it. As you write the
description, refer to the glossary and, if you need to, define new concepts. See
also the section Brief Description in Guidelines:
Use Case.
Outline the Flow of Events
At this point, you should also write a first draft of the flow of events of
the use case. Describe each use case's flow of events as brief instants of
performance, but do not go into detail. The person who will later specify the
use caseâeven if it is youâwill need this step-by-step description. Start by
outlining the basic flow of events, and once you have agreed on that, add
alternative flows.
Example:
The initial step-by-step description of the flow of events of
the use case Recycle Items in the Recycling-Machine System might look like this:
The customer presses the "Start" button.
The customer inserts deposit items.
The system checks the type of the inserted deposit items.
The system increments the day's total of the types of items received.
The customer presses the "Receipt" button.
The system prints out the receipt.
Collect Additional Requirements
Some of the system's requirements cannot be allocated to specific use cases;
collect these in the Supplementary Specifications (see Artifact:
Supplementary Specifications).
Describe How Actors and Use Cases Interact
Because it is important to show how actors relate to the use case, you
should, on finding a use case, establish which actors will interact with it. To
do this, you must define a communicates-association that is navigable in the
same direction as the signal transmission between the actor and the use case.
Signal transmissions usually go in both directions. When this is the case,
you must let the communicates-associations be navigable in both directions.
Define, at the most, one communicates-association for each actor-and-use-case
pair.
You should also briefly describe each communicates-association you define.
Present the Use-Case Model in Diagrams
You can illustrate relationships among use cases and actors, as well as among
related use cases, in diagrams of the use-case model. These diagrams might
contain any of the following:
Actors belonging to the same use-case package.
An actor and all the use cases with which it interacts.
Use cases that handle the same information.
Use cases used by the same group of actors.
Use cases that are often executed in one sequence.
Use cases that belong to the same use-case package.
The most important use cases. A diagram of this type can function as a
summary of the model, and is likely to be included in the use-case view.
The use cases developed together (within the same increment).
Each diagram should be owned by an appropriate package in the use-case model.
For more information on use-case diagrams, see Guidelines:
Use-Case Diagram.
Develop
a Survey of the Use-Case Model
In your description of the Survey Description of the use-case model, include
the following:
Typical sequences in which the use cases are employed by users.
Functionality not handled by the use-case model.
See also the section on Survey Description in Guidelines:
Use-Case Model.
Evaluate Your Results
You should check the use-case model at this stage to verify that your work is
on track, but not review the model in detail. You should also consider the
checkpoints for the use-case model while you are working on it. See especially
checkpoints for Actor, Use Case and Use-Case Model in Activity:
Review Requirements.
It is important that people outside the development team (for example, users
and customers) approve the use-case model at this stage. Therefore, you must
involve the users and the customer in reviewing the use-case model before you
finish this activity. You can use the Use-Case-Model Survey report and its
use-case diagrams as a guide in your discussions.
The interested parties will have to determine:
If all necessary use cases are identified.
If any unnecessary use cases are identified.
If the behavior of each use case is performed in the right order.
If each use case's flow of events is as complete as it could be at this
stage.
If the survey description of the use-case model makes it understandable.
For more issues to review, see checkpoints for actor, use case and use-case
model in Activity: Review Requirements.