Back to: Four Core Models for Scoping Requirements

Lesson Overview

In this lesson, we will look at five symbols used in a use case diagram:

  • System Domain Box
  • Actor Figure
  • Goal Oval
  • Actor Initiator Arrow
  • Actor Connector Line

SYSTEM DOMAIN BOX

The System Domain Box indicates the boundary of the system you want to highlight or focus on.

Referring to the Shopping Cart Project, we can view the relationship map and count the number of entities that are in the scope of the project. In this example, there are 7 entities.

Any entity in the relationship map may be used as the system domain. That is, you may draw a use case diagram to zoom in and focus on any entity on the relationship map. The system domain may be a business unit, department, computer application, and user role.

In the Shopping Cart Project, the RQ Website was an entity most affected by the project scope. Therefore, we’ll use the RQ Website as the system domain for our use case diagram examples.

ACTOR FIGURE

The Actor Figure, also called a stick figure, is used to represent a role that interacts with the system domain.

Actors may be primary or secondary. Primary actors initiate interaction with the system domain. Secondary actors are called upon by the system domain for assistance.

In the diagram shown, the Customer is an example of a primary actor. The customer initiates interaction with the RQ Website. Think of the primary actor as an entity that ‘knocks at the door’ of the system domain.

Other primary actors include the Accounting Department, RQ Admin, and Fulfillment Department. The Accounting Department knocks at the door of the RQ Website to view sales reports. The RQ Admin initiates interaction to add products. The Fulfillment Department initiates interaction to view purchase orders.

The Shipping Vendor is an example of a secondary actor. In order for the RQ Website to complete the functionality of the Customer’s action to purchase a book, the RQ Website calls upon the Shipping Vendor to acquire current shipping rates.

Similarly, the Payment Processor is a secondary actor. The RQ Website calls upon the Payment Processor to enable the Customer to pay for the book.

The Fulfillment Department is a secondary actor because the Customer’s action to purchase a book triggers the RQ Website to send a new-order notification to the Fulfillment Department.

Just as the entities in the Relationship Map should not be the name of a specific person, the name of an actor should not be a specific person. Rather, identify the role or business function they perform as the actor name.

GOAL OVAL

The Goal Oval represents the user’s goal or the reason for the primary actor’s interaction with the system domain. The label inside the oval names the use case or functionality that the actor wants from interacting with the system domain.

The goals are named in a verb-noun format to reflect the actions of the primary actor. Examples of this verb-noun format are shown in the RQ Website use case diagram: Add Products, Purchase Book, View Purchase Order, and View Sales Reports.

When naming user goals try to identify strong action verbs that best describe what the actor wants to achieve, as well as verbs that fit the context of the business operation. For example, Withdraw Funds is a better name for the ATM Customer’s goal than Get Money. The verb withdraw is stronger than the verb get, and better fits the banking scenario.

In the example shown, you can see that it is okay for a goal to have multiple secondary actors associated with it.

So is it okay for a primary actor to have multiple goals?

Yes, of course, a primary actor may have multiple goals. For example, the RQ Admin is interacts with the RQ Website to not only add products, but also to update and delete products.

Here’s a question for you. Is it okay to have two primary actors initiate the same goal?

I suggest that you avoid having two primary actors initiating the same user goal. In this example, it certainly is understandable that the RQ Admin and the Fulfillment Department would need to view a purchase order. And in reality, both roles do log into the RQ Website backend and view purchase orders. However, ideally we want to have only one primary actor initiate each goal. That is, identify the primary actor that has ownership of the goal.

ACTOR INITIATOR ARROW / ACTOR CONNECTOR LINE

The last two symbols are the Actor Initiator Arrow and the Actor Connector Line. These are used to connect the actors to the goals. The line with an arrowhead is used for primary actors. The arrowhead communicates that the primary actor initiates interaction (knocks at the door) with the system boundary to achieve the user goal. A line without an arrowhead is used for secondary actors.

The system domain box is similar to the boundary box in the relationship map. The lines from the primary and secondary actors should extend to the affiliated goals.

For best results, I recommend placing the primary actors on the left side of the system domain box, and placing the secondary actors on the right side as shown here. This way all of the actor initiator arrows will be on the left side of the domain box. This consistency makes it more likely that your audience will interpret the diagram correctly.

So did you notice that the Fulfillment Department is a primary actor and a secondary actor in my example? Perhaps you thought my example had a mistake in it?

Well, there’s no mistake. The Fulfillment Department is a primary actor when it initiates interaction with the RQ Website to View Purchase Orders. It is a secondary actor in connection to the Customer’s goal to Purchase a Book. The Customer’s action to purchase a book triggers the RQ Website to send a new-order notification to the Fulfillment Department.

Let’s close this lesson with a quick summary of the symbols used in a use case diagram. The system domain box represents the boundary of the entity or system that you want to focus on. Actor figures show the entities that interact with the system domain. Goal ovals communicate the reasons for interacting with the system domain, and summarize the functionality the primary actor wants to achieve through that interaction. Actor initiator arrows connect primary actors with goals. Finally, actor connector lines connect the secondary actors with affiliated goals.