Use Case Analysis: How to Identify Actors?

Identifying actors is one of the first steps in use case analysis. Each type of external entities with which the system must interact is represented by an actor. For example, the operating environment of a software system consists of the users, devices, and programs that the system interacts with. These are called actors which has the following characteristics:

• An actor in use case modeling specifies a role played by a user or any other system that interacts with the subject.
• An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject.
• Actors may represent roles played by human users, external hardware, or other subjects.
• Actors do not necessarily represent specific physical entities but merely particular facets (i.e., “roles”) of some entities that are relevant to the specification of its associated use cases.
• A single physical instance may play the role of several different actors and a given actor may be played by multiple different instances.

Types of actors include:

• Users
• database systems
• clients and servers
• cloud platforms
• devices

Identify Candidate Actors for Use Cases

Candidate actors include groups of users who will require help from the system to perform their tasks and run the system’s primary or secondary functions, as well as external hardware, software, and other systems.

Define each candidate actor by naming it and writing a brief description. Includes the actor’s area of responsibility and the goals that the actor will attempt to accomplish when using the system. Eliminate actor candidates who do not have any goals.

These questions are useful in identifying actors:

• 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.

Primary vs Supporting Actors

Primary actor of a use case is the stakeholder that calls on the system to deliver one of its services. It has a goal with respect to the system – one that can be satisfied by its operation. The primary actor is often, but not always, the actor who triggers the use case.

Supporting Actors: A supporting actor in a use case in an external actor that provides a service to the system under design.

Note That:

Supporting actors may or may not have goals that they expect to be satisfied by the use case, the primary actor always has a goal, and the use case exists to satisfy the primary actor. It might be an external server or a web service.

• A primary actor initiates an interaction with the system.
• The system initiates interactions with secondary actors.

Here are a few questions to guide the identification of primary and secondary actors:

Who are the primary actors?

• What roles do they play in the application domain?
• What are their roles? What tasks must they perform?
• How will they interact with the system? GUI? Telephone? Web?

Who are the secondary actors?

• What services do they provide?
• How will the system communicate with them? Network? Port?
• What specific APIs do secondary actors provide for communication and services?

Actor Identification Process

• To define what will be handled by the system and what will be handled outside the system (system scope, i.e. manual or automated procedure).
• To define who (actors) and what (the functionalities needed) will interact with the system.
• To outline the functionality of the system (help to identify use cases)

Actor Role Description

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. You can basically make list all your actors with their role description and their objectives in a tabular format as shown below:

Actor / Role Name	Role Description and Objective
Actor	Briefly describe the role of the actor to the system and how the actor will use the system What is the actor’s goal? What does the actor need from the system? What is the expected outcome of the system?
Customer	Customers will place food orders and may or may not order juice. When the order is served, the customer will eat his/her meal and pay the check.
Waiter	The waiter will receive the food order from the customer and confirm the order with the cook and serve food to the customer.

Use Case Description example:

A user clicks the search button on an application’s user interface. The application sends an SQL query to a database system. The database system responds with a result set. The application formats and displays the result set to the user.

In this scenario:

• The user is a primary actor because he initiates the interaction with the system (application).
• The database system is a secondary actor because the application initiates the interaction by sending an SQL query.

Once you have identified your actors and their goals, you have now created your initial list of high-level use cases. Remember, effective use cases must have understandable actors and goals.