The Unified Modeling Language (UML1) defines an Actor (from
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
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
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:
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)
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?
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.
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.
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 LanguageTM (OMG UML), Superstructure Version
(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