Use Case Actors - Primary versus Secondary

The Unified Modeling Language (UML1) 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” (2) 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 (3) 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!

(1) OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.4.1

(2) Cockburn, A, 2000, Writing Effective Use Case, Addison-Wesley Professional; Edition 1

(3) Cockburn, A, 2006 “Use Case fundamentals” viewed 20th March 2012, http://alistair.cockburn.us/Use+case+fundamentals

 

 

 

 

 

Comments:

Good article. Really helped

Posted by guest on October 09, 2012 at 10:52 AM GMT+05:00 #

As per definition, must the secondary actor somehow be linked with the system we are looking at or can a secondary actor be outside, meaning can the secondary actor be a completely independent system?
For example, a system publishes data somewhere and my system needs to get that data in order to support the successful completion of a use case.
Would the system that publishes data now be a secondary actor?

Thanks!

Posted by guest on November 15, 2012 at 09:33 PM GMT+05:00 #

Thanks for the question. Before I offer an answer, let's define some terms.

* A System Use Case relates directly to the System Under Discussion (SuD) any other Actors (be they Human, System other otherwise) will reside outside of the SuD

* A System Use Case must include one Primary Actor, and optionally any Secondary Actors that are required to complete the Use Case within a single "sitting"

* "Sitting" refers to a single set of interactions between the Primary Actor and the SuD. A "Sitting" might last 30 seconds, or 30 minutes, but it's generally thought of as a single self-contained session

In terms of your question, the first thing to do would be to ask yourself "what is the goal of my Use Case", and this will usually be the same as the Use Case name. For example, let's say our Use Case is called "Display Performance Metrics". The Primary Actor might be the HR Manager, and the SuD would be the HR System.

Now we must ask ourselves "Will any other Actors be required to complete this Use Case?"

Let's assume the SuD needs to retrieve the Performance Metrics from a separate (i.e. non SuD) system; could be something like a query to an external BI Database. In this example, the BI Database would indeed be a Secondary Actor because 1) The call, and subsequent return of the Metrics are accomplished within a single "Sitting" and 2) the Use Case cannot successfully complete without the information from the Secondary Actor.

Now let's assume that the BI System publishes Performance Metrics every evening, and then pushes that information directly into the HR System. There would probably be a separate Use Case called something like "Publish Performance Metrics" where the SuD would be the BI System. But if we now go back to our "Display Performance Metrics" Use Case, then we would no longer have a Secondary Actor. The details of the Use Case would simply request the Metrics to be displayed from "within" the SuD.

Hope this helps.

Posted by guest on November 16, 2012 at 07:39 AM GMT+05:00 #

Very good article, really helped! thx.

Posted by guest on August 13, 2013 at 09:21 PM GMT+05:00 #

Very good article! really helped.

Posted by guest on August 13, 2013 at 09:23 PM GMT+05:00 #

thank u

Posted by guest on October 15, 2013 at 08:49 PM GMT+05:00 #

thank u

Posted by guest on October 15, 2013 at 08:49 PM GMT+05:00 #

Helped me alot ...

Posted by Fazila Ashraf on October 29, 2013 at 08:48 PM GMT+05:00 #

Post a Comment:
  • HTML Syntax: NOT allowed
About

OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds