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:
Types of actors include:
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:
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.
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.
Here are a few questions to guide the identification of primary and secondary actors:
Who are the primary actors?
Who are the secondary actors?
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|
|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:
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.