Skip to main content

OpenUP (with RACI and Entry_Exit criteria)

Go Search
Home
  
OpenUP (with RACI and Entry_Exit criteria) > Wiki Pages > Guidance - Actor  

Guidance - Actor

Online Process Main Page

Actor

Description

Overview:

An Actor is a role that a person or external system plays when interacting with a system. Instances of an Actor can be an individual or an external system.

 

Explanation:

To fully understand the system's purpose, you must know who the system is for, that is: Who will use the system? The answer to this question is: the Actors.

 

An Actor is a role that a person or external system plays when interacting with the system. Instances of an Actor can be an individual or an external system, however each Actor provides a unique and important perspective on the system that is shared by every instance of the Actor.

 

This difference between an actor and an instance of an actor is illustrated below. Figure 1 shows a case in which Ivar and Mark are operators of a recycling machine. When they are using the machine in this capacity, each is represented by an instance of the actor called Operator that expects certain functionality of the system (Print Daily Reports in this example).

 

 

Figure 1: Example Actor with multiple instances 

Conversely, the same user can act as several actors (that is, the same person can take on different roles). In Figure 2, Charlie uses the Depot-Handling System primarily as Depot Manager, but sometimes he also uses the Depot-Handling System as an ordinary Depot Staff member. Each of these actors expects different functionality of the system.

 

Figure 2: Example of user playing different roles

Actors help you to identify external interfaces and to determine the scope the system (what is in the system, vs. what is outside the system boundary). Each Actor has associated use cases which describe what that particular actor expects of the system. It will be very difficult, if not impossible, to assess the completeness of the set of Use Cases without the context provided by the associated Actors. Furthermore, missing an actor may result in missing important stakeholder perspectives, resulting in a solution that does not meet all stakeholder needs.

 

Hence, identifying the Actors for the system should be done early in the lifecycle. Actors are captured, including their names, brief descriptions, and relationships to use cases, in the Use-Case Model.

 

Properties of Actors:

  • Name: Each actor should have a name that clearly describes the role played by the user.
  • Brief Description: Each actor should have a brief description that clearly describes:
    • What or who the actor represents.
    • Why the actor is needed.
    • What interests the actor has in the system
    • Major characteristics of the actor.
  • The major characteristics of the actor are important as they may influence how the system is developed, for example characteristics of the user interface such as accessibility or globalization. Examples of important characteristics include:
    • The actors level of domain knowledge
    • The actors level of computer experience
    • The actors abilities and disabilities
    • The actors native language

 

Check Items:

  • Have you found all the actors?
    • Have you accounted for all roles in the systems environment? See Guideline: Find and Outline Actors and Use Cases for some questions that may help identify actors.
  • Is each actor involved with at least one use case? 
    • If you cannot identify a use case associated with a given actor perhaps the actor should be removed, or perhaps you are missing a use case.
  • Can you identify at least two people, or external systems, that would play the role of a particular actor? 
    • If you cannot, check if the role that the actor represents is part of another actor. If that is the case, you should merge the actors.
  • Will a particular actor use the system in several completely different ways? 
    • If true, you should probably have more than one actor. 
  • Does the actor have several completely different purposes for using the system? 
    • If true, there may be more than one actor.
  • Have you considered maintenance and administrative roles? 
    • It is common to focus on the daily users of the system, and forget about administrative and maintenance roles such as setting up user accounts, managing access rights, performing backups, etc. Ensure you have captured these actors.
  • Does each actor have a clear description of its role? 
    • Each actor should have a short description of the role and the main goal the actor has in using the system.

Attributes

GuidanceKindChecklist

Last modified at 2/4/2008 4:51 AM  by Administrator