Find Actors
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 Guideline: 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. If you have developed a business
use-case model and business analysis model, you can use them as sources for identifying the main actors.
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 Guideline: Actor.
|
Find Actors - Systems Engineering Note
When this task is performed in the context of systems engineering (with the expectation that the system under
scrutiny will decompose into further subsystems), the expectation is that business modeling (or some equivalent) will have
identified and characterized the boundary of the system to be developed (as a Business System in the case of
business modeling), and that the actors in the enterprise with which the system must interact to deliver business value,
have been identified. In this context then, this task is concerned mainly with the derivation of system use cases. If
business modeling is not performed, some equivalent mission modeling is needed to discover actors and use cases - in this
case the following steps may have value in this discovery. |
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.
Other than requirements, an enterprise model of your organization (also called a business model) is a valuable source
of input for determining use cases. The enterprise model describes how the information system might be incorporated
into existing operations and so gives you a good idea of the system's surroundings. You will also find concepts that
need to be defined in the enterprise model because it contains the "business objects" of the enterprise. If you have
followed the Business Modeling workflow, you will have a business use-case model and
a business analysis model to use as input.
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 Guideline: Use-Case Model and Guideline: 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 Guideline: 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 Guideline: 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 Work Product: Supplementary Specifications).
|
Find Use Cases - Systems Engineering Note
If analysis has proceeded at the enterprise level (using business modeling or some equivalent) then business use
cases and a business analysis model (with business use-case realizations and operations) will be available.
The business use-case realizations will have delineated the role the system will play in the enterprise and defined the
interactions between the system and other entities in the enterprise. These other entities are the actors. The use cases
for the system can be determined from a process of aggregation of the system's interactions with other entities, by looking
for similarities in the messages exchanged. This process can proceed from the business use-case realizations, or from the
'white-box' description of the business use-case. See the Concept: Use-Case Flowdown, for more information. The use cases so discovered may be
captured in diagrams (associated with the Work Product: Use-Case Model). Any performance or other constraints
(derived from the supplementary business specification or other source) that may be associated with the system use-cases
should be captured in the 'special requirements' property of the use case.
Outline the Flow of Events
This initial description of the interactions between the system's actors and the system is pure 'black box', that is,
it does not reveal anything about the internal structure of the system. It should be constructed as a sequence of steps
('black box steps' - see Guideline: Use Case), each of which represents a fine-grain interaction with the system. These black box steps will be used to
guide the identification of 'services' to be supported by the system (see Task: Define the System Context). Each black box step may be
annotated with performance or other resource constraints which are driven by external needs (for example in order to
achieve some overall response time). The allocation of such budgets has to be done carefully, recognizing the
complexity of each step, and will be refined as the use-case description is refined and realized. It may be the case
that the driving requirement itself has to be relaxed.
Collect Additional Requirements
For many systems, there may be:
-
physical requirements such as constraints on size, weight or power consumption
-
environmental requirements, such as heat tolerance, vibration resistance or contaminant resistance
-
additional product assurance requirements, such as safety, security, survivability
|
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.
For more information on communicates-associations, see Guideline: Communicate-Association.
|
Describe How Actors and Use Cases Interact - Systems Engineering Note
In this context we will delineate the input/output entities that flow between actor and system. In the general systems
case, these entities can include data, mass flow, energy or discrete physical objects. Later, outside this task, we will
also describe the interface protocols associated with their exchange. This is done in Task: Detail a Use Case and Task: Define the System Context. In this task (Find Actors and Use
Cases), you should include a broad description of what is exchanged in the actor-system use-case association (with each
association). Any interface constraints (because the system must communicate with an existing system or external hardware)
should be captured in Work Product: Supplementary Specifications. |
Package Use Cases and Actors
If the number of actors or use cases becomes too great, divide them into use-case packages to simplify the
maintenance of the use-case model. This also makes the use-case model easier to grasp, and simplifies the
assignment of responsibilities in the use-case model by letting developers be responsible for packages of
use cases or actors.
Some alternative ways of packaging use cases together is if they:
-
Interact with the same actor.
-
Have include- or extend-relationships between each other.
-
Are all optional, and are offered by the system together or not at all.
There are also other ways; however, to keep the model intuitive, it is important that you use a clear
strategy when you do the packaging.
For more information on use-case packages, see Guideline: Use-Case Package.
|
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 Guideline: Use-Case Diagram.
|
Develop a Survey of the Use-Case Model
In this step you develop the survey description of the use-case model. In your survey, be sure to include the
following:
-
Typical sequences in which the use cases are employed by users.
-
Functionality not handled by the use-case model.
For more information on the survey description of the use-case model, see the survey description section in Guideline: 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 checking the use-case model while you are working on it. For specific
recommendations on what to look for, see Checklist: Use-Case Model.
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 task. You can use the survey of the use-case model and its use-case diagrams created in the earlier step 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.
|
|