Types of Actor in a Use Case Model

Actors can be people, other systems, time triggers, or event triggers.

An actor specifies a role played by a user or any other system that interacts with the subject. It may represent roles played by human users, external hardware, or other subjects. Actors are always outside the system and interact directly with it by initiating a use case, provide input to it, and/or receive outputs from it. While a single physical instance may play the role of several different actors, an actor does not necessarily represent specific physical entities, i.e. a timer that triggers sending of an e-mail reminder.

Primary vs Supporting Actors

In Alistair Cockburn’s book “Writing Effective Use Cases” Actors are further defined as follows:

Primary Actor: a user whose defined user goal and is fulfilled by the system

• The 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 user who provides a service (e.g., information) to the system.

• A supporting actor (also known as a secondary actor) in a use case in an external actor that provides a service to the system under design. It might be a high-speed printer, a web service, or humans that have to do some research and get back to us.

Another Way for Classifying Actors

Many analysts miss key actors during the use case diagramming process because they only identify human actors.  Categorizing use case actors in this way helps the analyst ensure they haven’t overlooked any critical actors within the use case diagram.

There is another way to classify actors, they can be:

• Human
• Systems / Software
• Hardware
• Timer / Clock

Note That:

Here are the tips to help identify actors, they are typically external objects of the system that produce/consume data:

• Must serve as sources and destinations for data
• Must be external to the system

Use Case Example – ATM

In the example below, the Visa Card Holder and Bank Customer are Primary Actors, while the Visa AS and Bank IS are secondary actors.

Use Case Diagram Example – Banking System

A bank provides common banking services to retail customers which include: Deposit, Withdraw, Loan or Mortgage payment and other account management services:

Summary

Use cases are usually referred to as system functionalities that a system should perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable results to the actors or other stakeholders of the system.