Actors and Users

Software Development

Actors and Users

By |

Software products are created for users, be they human beings, hardware devices, or other software systems. A user is a stakeholder who will interact with a completed system either directly (that is, hands on) or indirectly (for example, using reports from the system but not generating those reports personally). Users can be grouped into user classes, communities of users who have similar characteristics and similar requirements for a system.

Discussions of use cases always involve the concept of actors. An actor is an entity outside the system boundary that interacts with the system for the purpose of completing an event, such as execution of a use case. Actors are related to—but are not precisely the same as—user classes. This distinction between user classes and actors is subtle. It doesn’t help that the books on use cases employ somewhat different terminology. Here are the key points:

  • User classes represent groups of actual people or non-human users. A human user is a member of one or more user classes. You need to identify your product’s user classes so you know which people to talk with about requirements. You also need to understand which user classes are “favored” over others. Satisfying the needs of a favored user class is more important from a business perspective than meeting the needs of other groups of users. This distinction helps when making priority decisions and resolving requirement conflicts.
  • An actor is an abstraction, a role performed by a member of a specific user class when he interacts with a product at a specific time. When you are talking with user class representatives, have them identify the various roles that members of each class can perform from time to time. If those user roles involve interacting with the system through a use case, the roles represent actor names. Consider developing personas, descriptions of representative actors who can execute certain use cases.

I like to imagine the members of each user class as having a stack of hats available, each of which is labeled with a particular actor or role name. Whenever a user needs to perform a specific use case with the system, he puts on the hat labeled with the name of the actor who initiates that use case. The system behaves as though it’s interacting with that actor, regardless of what user class that individual user belongs to.

Figure 1 illustrates the relationship between actors and user classes for a bank. Bank Customers constitute one class of users of banking services. A particular Bank Customer might perform various functions from time to time with the bank’s systems, perhaps as an indirect user working through a bank employee. When performing those functions, the Bank Customer is assuming the role of a particular actor. When he makes a cash withdrawal from an automated teller machine, the customer is performing the role of an Account Owner. This is more specific than calling him a generic Bank Customer. As far as the ATM is concerned, it’s performing a service for an Account Owner.

Figure 1. A member of one user class could take on multiple actor roles.

On another occasion, that same person might walk into the bank and apply for a loan. At that time, he’s wearing the hat of a Loan Applicant actor, not an Account Owner. The system the customer interacts with at that time thinks of the user as being a Loan Applicant. In a third situation, a bank customer might deposit a check into an account he doesn’t own, perhaps on behalf of his spouse or a business colleague. In that case, the customer is filling the role of the Depositor actor. Note how many actor names end in -er or -or, which indicates that the actor is a performer attempting to accomplish a particular objective.

There could also be a many-to-one relationship between user classes and actors, as Figure 2 illustrates. When I worked on a project called the Chemical Tracking System at one company, we had several important user classes: chemists, chemical technicians, members of the chemical stockroom staff, and laboratory managers. Each of these groups had largely different sets of requirements, but there was some overlap. For example, members of all these user classes might have to place requests for chemicals periodically. Now, no one at this company had a job title of “chemical requester.” The Chemical Requester actor is an abstraction that represents anybody who needs to request a chemical and is authorized to do so. The system doesn’t care whether the person requesting a chemical works as a chemist, a lab manager, or something else. All the system knows is that a Chemical Requester actor is executing certain use cases associated with chemical request activities.

Figure 2. Members of multiple user classes could all perform as the same actor.

Actors appear in use case diagrams drawn according to the convention of the Unified Modeling Language. Figure 3 shows a portion of a use case diagram for the Chemical Tracking System. The box represents the system boundary. Each oval inside the box represents a single use case, something a user would need to accomplish with the help of the system. The stick figures outside the box represent actors. The stick figure notation is a standard convention that’s used whether the actor is a human being or an inanimate entity.

Figure 3. Use case diagrams show primary and secondary actors for specific use cases.

An arrow drawn from an actor to a use case indicates that the actor can initiate the corresponding use case; this is called the primary actor for that use case. The Chemical Requester actor can initiate the use cases Request a Chemical, Receive Chemical, Check Order Status, and so forth. An arrow directed from a use case to an actor indicates a secondary actor. Secondary actors participate in the completion of a use case, but they don’t derive the benefit from the use case; the primary actor gets the benefit. The Training Database and Buyer actors are secondary actors with respect to the Request a Chemical use case. The Chemical Tracking System might have to rely on the Training Database to see whether a user is properly trained in how to handle a dangerous chemical. And, if someone submits a request for a chemical that needs to be purchased from a vendor, the system will route that request to a Buyer for handling. Note that actors are primary or secondary with respect to a specific use case, not with respect to the overall system.

As you begin your requirements exploration, be sure to identify your user classes so that you know who you’ll need to talk to in order to discover user requirements. Key representatives of user classes (product champions) can work with the business analyst during elicitation. The product champions identify the use cases that represent tasks or goals that members of their user class will need to accomplish with the system’s help.

As you explore each use case, think of an appropriate name to describe the actor who will initiate that use case. Try to select a name that reflects what the user is attempting to accomplish, such as Chemical Requester, Buyer, or Loan Applicant. Consider whether members of other user classes might also have occasion to perform that same use case—that is, whether they might have occasion to function in that same actor role. The analyst should consult representatives of those user classes to see if their stated needs enrich his understanding of the use case, perhaps by identifying additional alternative flows.

Consider developing catalogs that describe your common user classes and actors so that you can reuse these definitions in a consistent fashion across multiple projects. Any opportunities for requirements reuse will reduce errors, save time, and help you build a more cohesive set of integrated products.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Karl Wiegers
Latest posts by Karl Wiegers (see all)