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.
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
Supporting Actors: a user who provides a service (e.g., information) to the system.
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:
Here are the tips to help identify actors, they are typically external objects of the system that produce/consume data:
In the example below, the Visa Card Holder and Bank Customer are Primary Actors, while the Visa AS and Bank IS are secondary actors.
A bank provides common banking services to retail customers which include: Deposit, Withdraw, Loan or Mortgage payment and other account management services:
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.