The Unified Modeling Language (UML¹) defines an Actor (from UseCases) as:

An actor specifies a role played by a user or any other system that interacts with the subject.

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

Primary Actor: 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 supporting 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.

In a 2006 article ⁽³⁾ Cockburn refined the definitions slightly to read:

Primary Actors: The Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor.

Secondary Actors: Actors that the system needs assistance from to achieve the primary actor’s goal.

Finally, the Oracle Unified Method (OUM) concurs with the UML definition of Actors, along with Cockburn’s refinement, but OUM also includes the following:

Secondary 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.

Now that we are on the same “page”, let’s consider two examples:

1. A bank loan officer wants to review a loan application from a customer, and part of the process involves a real-time credit rating check.
• Use Case Name: Review Loan Application
• Primary Actor: Loan Officer
• Secondary Actors: Credit Rating System
2. A Human Resources manager wants to change the job code of an employee, and as part of the process, automatically notify several other departments within the company of the change.
• Use Case Name: Maintain Job Code
• Primary Actor: Human Resources Manager
• Secondary Actors: None

The first example is quite straight forward; we need to define the Secondary Actor because without the “Credit Rating System” we cannot successfully complete the Use Case. In other words, the goal of the Primary Actor is to successfully complete the Loan Application, but they need the explicit “help” of the Secondary Actor (Credit Rating System) to achieve this goal.

The second example is where people sometimes get confused. Within OUM we would not include the “other departments” as Secondary Actors and therefore not include them on the Use Case diagram for the following reasons:

• The other departments are not required for the successful completion of the Use Case
• We are not expecting any response from the other departments (at least within the bounds of the Use Case under discussion)

Having said that, within the detail of the Use Case Specification Main Success Scenario, we would include something like:

“The system sends a notification to the related department heads (ref. Business Rule BR101)”

Now let’s consider one final example.

A Procurement Manager wants to place a “bid” for some goods using an On-Line Trading Community (B2B version of eBay)

• Use Case Name: Create Bid
• Primary Actor: Procurement Manager
• Secondary Actors: On-Line Trading Community

You might wonder why the Trading Community is listed as a Secondary Actor, i.e. if all we are going to do is place a bid for a specific quantity of goods at a given price and send that off to the Trading Community, then why would the Trading Community need to “assist” in that Use Case?

Well, once again, it comes back to the “User Experience” and how we want to optimize that when we think about our Use Case, and ultimately, when the developer comes to assembling some code.

In this final example, the Procurement Manager cannot successfully complete the “Create Bid” Use Case until they receive an affirmative confirmation back from the Trading Community that the Bid has been accepted. Therefore, the Trading Community must become a Secondary Actor and be referenced both on the Use Case diagram and Use Case Specification.

Any astute readers who are wondering about the “single sitting” rule will have to wait for a follow-up Blog entry to find out how that consideration can be factored in!!!

Happy Use Case writing!

⁽¹⁾ OMG Unified Modeling Language^TM (OMG UML), Superstructure Version 2.4.1

⁽²⁾ Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1

⁽³⁾ Cockburn, A, 2006 “Use Case fundamentals” viewed 20^th March 2012, http://alistair.cockburn.us/Use+case+fundamentals