To fully understand the system's purpose you must know who the system is for, that is, who will be
using the system. Different user types are represented as actors.
An actor is anything that exchanges data with
the system. An actor can be a user, external hardware, or another system.
The difference between an actor and an individual system user is that an actor represents a particular
class of user rather than an actual user. Several users can play the same role, which means they can be one
and the same actor. In that case, each user constitutes an instance of the actor.
Ivar and Mark are operators of a recycling machine. When they are using the machine each is represented by
an instance of the actor Operator.
However, in some situations, only one person plays the role modeled by an actor. For example, there may be
only one individual playing the role of system administrator for a rather small system.
The same user can also act as several actors (that is, the same person can take on different roles).
Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the
Depot-Handling System as ordinary Depot Staff.
What in the system's surroundings will become actors to the system?
Start by thinking of individuals who will use the system. How can you categorize them? It is often a good
habit to keep a few individuals (two or three) in mind and make sure that the actors you identify cover
their needs. The following set of questions is useful to have in mind when you are identifying actors:
-
Who will supply, use, or remove information?
-
Who will use this functionality?
-
Who is interested in a certain requirement?
-
Where in the organization is the system used?
-
Who will support and maintain the system?
-
What are the system's external resources?
-
What other systems will need to interact with this one?
There are several different aspects of a system's surroundings that you will represent as separate actors:
-
Users who execute the system's main functions.
Example:
For a Depot-Handling System, which supports the work in a depot, there are several categories of users:
Depot Staff, Order Registry Clerk, Depot Manager. All these categories have specific roles in the system
and you should therefore represent each one by a separate actor.
-
Users who execute the system's secondary functions, such as system administration.
Example:
In a recycling machine used for recycling cans, bottles, and crates, Customer is the main actor, the one
for whom the system is primarily built. Someone has to manage the machine, however. This role is
represented by the actor Operator.
-
External hardware the system uses.
Example:
A ventilation system that controls the temperature in a building continuously gets metered data from
sensors in the building. Sensor is therefore an actor.
-
Other systems interacting with the system.
Example:
An automated teller machine must communicate with the central system that holds the bank accounts. The
central system is probably an external one, and should therefore be an actor.
If you are building a internet-based application, your primary actors will in a sense be anonymous. You
don't really know who they are, and you cannot make any assumptions about their skills and background. But
you can still describe the role you expect them to play towards your system.
Example:
Systems that provide information (such as search engines) will have purely anonymous actors who access the
application only to find information about a particular topic.
Example:
Government-informational sites whose charter is to provide information to any citizen or 'netizen' about
laws and regulations, practices, forms, and so on. For example, in the US the Internal Revenue Service has
page that provides information around how to complete a tax return. This includes having all forms
available electronically, as well as allowing individuals to file their tax return electronically. The role
of the primary actor in this case is anyone interested in how you file a tax return in the US. Of course,
once the individual attempts filing the return, she can no longer be anonymous.
Finding the actors also means that you establish the boundaries of the system, which helps in understanding
the purpose and extent of the system. Only those who directly communicate with the system need to be
considered as actors. If you are including more roles than that in the system's surroundings, you are
attempting to model the business in which the system will be used, not the system itself.
Example:
In an airline booking system, what would the actor be? This depends on whether you are building a airline
booking system to be used by a travel agent, or whether you are building a system to which the passenger
can connect directly through Internet.
If you are building an airline booking system to be used at a travel agent, the actor would be travel
agent. The traveler doesn't interact directly with the system, and is therefore not an actor
If you are building a booking system that will allow users to connect via the Internet, the traveler will
interact directly with the system and is therefore an actor to it.
The brief description of the actor should include information about:
-
What or who the actor represents.
-
Why the actor is needed.
-
What interests the actor has in the system.
The brief description should be, at most, a few sentences long.
Example:
In the use-case model of the Recycling Machine, the three actors are briefly described as follows:
Customer: The Customer collects bottles, cans and crates at home and brings them back to the shop to
get a refund.
Operator: The Operator is responsible for maintenance of the recycling machine.
Manager: The Manager is responsible for questions about money and the service the store delivers to
the customers.
The characteristics of an actor might influence how the system is developed, and in particular how an
optimally usable user interface is visually shaped. Note that if business workers corresponding to the
actors are already described in a business-object model, some of the following characteristics may have
already been captured. The actor characteristics include:
-
The actor's scope of responsibility.
-
The physical environment in which the actor will be using the system. Deviations from the ideal case
(where the user sits in a silent office, with no distractions), might affect the use of such things as
sound, the choice of font, and the appropriate use of input device combinations (e.g., keyboard, touch
screen, mouse, and hot-keys.)
-
The number of users represented by this actor. This number is a relevant factor when determining the
significance of the actor, and the significance of the parts of the user interface that the actor uses.
-
The frequency with which the actor will use the system. This frequency will determine how much (of the
user interface) the actor can be expected to remember between sessions.
In most cases, a rough estimate of the number of users and frequency of use will suffice. A difference
between 30 and 40 will not affect how the user interface is shaped, but a difference between 3 and 30
might.
Other actor characteristics include:
-
The actor's level of domain knowledge. This level will help determine how much domain-specific help is
needed, and how much domain-specific terminology should be used in the user interface.
-
The actor's level of general computer experience. This level will help determine how appropriate
sophisticated versus simplistic interaction techniques are in the user interface.
-
Other applications that the actor uses. Borrowing user-interface concepts from these applications will
shorten the actor's learning time and decrease his memory load, since the actor is already familiar
with these concepts.
-
General characteristics of the actors, such as level of expertise (education), social implications
(language), and age. These characteristics can influence details of the user interface, such as font
and language.
These characteristics are used primarily when identifying the boundary classes and the prototype, to ensure
the best usability match between the user community and the user interface design.
Example:
The following is an example of characteristics of the Mail User actor. This is the actor that, amongst
other things, interacts with the Manage Incoming Mail Messages use case.
-
The mail user is an experienced PC user.
-
The work environment of the mail user is typically a quiet office.
-
The targeted number of mail users is 500,000.
|