Part 1: Defining Actors and Use Cases
When deciding to have a custom software application developed, there are several things needed that do not fall under the responsibility of the developers themselves. One of the most critical components is the Requirements Document. And it is your responsibility to create it. After all, the developers cannot see inside your head, yet. They do not know how your company functions, who does what and what you are trying to achieve. At some point during the development process, with enough communication, they will be able to anticipate your desires, but they need a starting point.
The Requirements Document has many components. It, in general, describes what your application “Should do” and “Shouldn’t do”. It defines the system, functional requirements, and user requirements along with several other aspects of the application. In another article, we address what should be covered in a complete Requirements Document. Two key components are the actors and the use cases. Actors are those individuals or systems that will interact with the application. Use cases are series of steps or related interactions that are performed by an “Actor” on the system in order to complete a goal.
Naming actors is not the first step you should take in deciding what your application should do, but it is definitely second or third. The first step is deciding what is the problem you are trying to solve with your application. Without that as the foundation, anything else is irrelevant.
Actors
Defining actors seems like an easy task. Who will use the system everyday? But many people just look at this from their perspective of who do I interact with through the system. So, for instance, if you are designing a banking application for online banking, you may think of just the perspective of the “bank” and the “bank customer” as the two actors. Yet there are several others that interact with the system from not just a software perspective, but also from an external software and hardware perspective. In addition, these actors should be broken down into two categories, primary and secondary. The primary actor is the actor that is directly interacting with the system to achieve a goal. The secondary actor is the actor is external to the system, but is called upon to help complete a goal. For instance, the secondary actor may be a printer needed to print an invoice or a CEO that may get reports delivered to him, but takes no action in the application.
Examples of actors
Primary
Administrator: Assigning roles in the system, creating account permissions, updating software
Project Manager: Schedule projects, define requirements, check project status, generate reports
Customer: search products, purchase products, create wish list, create profile
Secondary
Microsoft Outlook: Meeting schedules are exported to outlook
Picker in Warehouse: Orders are printed and received by picker
Database Server: provides or stores data
For each of the examples above, their interaction with the systems can change with each use case. A picker in the warehouse can become a primary actor if he is required to interact with the system to achieve a goal. So if he needs to be able to create a shipping label for orders picked, he then becomes a primary actor in that use case. Because of this, documenting the use case with the actor becomes key, since their role can change. Therefore, a single individual can be presented as multiple actors.
Use Cases
If you understand the actor’s roles, the use cases are not difficult to come up with. The challenge is making sure all the steps in an interaction are covered. The goal is not to consider the user interface or user interaction at this stage, but rather document what needs to happen to complete the goal of the use case by a particular actor.
The number of use cases associated with a single actor can be a single one or multiple. They may be simple or complex. The expectation is not for you, as the client, to come up with every step in the use case. It is to provide enough information to help the rest of the team assist in creating thorough use cases. Also, keep in mind, the use case to reach a particular goal for one actor may be different for the same goal for another actor. So, when creating use cases, the actor must be front and center in your mind.
When sitting down to write your use cases, keep in mind, there are several ways to do so. It is important to pick the way you are most comfortable with. Since your goal is to convey to the development team what the application needs to do, the mode of communication that you are best able to convey this should be the one to use.
If it is easiest for you to provide a narrative, which is a paragraph text description of the use case, you will need to include the pertinent information for the actor to complete their goal. These are, the intent of the user in performing the use case, the active steps that are needed to obtain the goal, and key outcomes of the steps that are needed to reach the goal.
If you prefer to write the use case as a scenario, you will need to identify the actor and the intent as an introduction. After that, all you will do is provide a step by step list of actions and responses of the actor and the system. This is a lateral description, without side interactions. So the scenario approach is a high level description with the key components listed out in a stepwise manner.
A third way that use cases can be written is through use of a Unified Modeling Language (UML) Use Case Diagram. These can be very simple diagrams to very complex. They can contain one actor with many use cases or to simplify, one actor and one use case. This is my favorite form for use case presentation if having to select, since it shows an easy to follow visual of how the actor interacts with the system and how the system responds. Combining the scenario format and the diagram format in the specification gives a clear understanding of what components, interactions and responses are in the use case.
Examples of Use Cases
Actor: Customer on Online Commerce site
Secondary Actor: Email system
Goal: create an account
Narrative: The customer on an online shoe store would like to create a new account. They must first provide their personal information in terms of name, shipping address, billing address, primary phone number with the ability to select the type of phone number it is, email address, username and password. These are all required fields. In addition, they may add a primary method of payment, which must be secure. The payment method should be able to be used to make quick payments. The password needs to be able to be reset by the customer via security answers once a validation email is sent. Before using the account, the customer must activate it via an activation email.
Scenario:
Actor: Customer on Online Commerce site
Secondary Actor: Email system
Goal: create an account
Customer opens online store home page
Customer clicks on Create an account hyperlink
Customer enters registration information
First Name (Required)
Last Name (Required)
Shipping Address (Required)
Billing Address (Required)
Primary Phone Number (Required)
Type of Phone Number (Required)
Work
Home
Cellular
Other
Alternative Phone Number
Type of Phone Number
Work
Home
Cellular
Other
Email (Required)
User Name (Required)
Password (Required)
Password Confirmation (Required)
Payment Method (Required)
Credit Card Number (Required)
CVC (Required)
Expiration Number (Required)
Security Question Selection (Required)
Security Question Answer (Required)
Customer clicks to activate the account
System checks for duplication in name, email and phone number
System checks for validity of phone number, email, credit card information
System sends an email to email address of customer entered with activation link
Email system of customer receives the email
Customer clicks on link to activate
System creates a profile and activates the account
System opens browser page with confirmation of activation and option to go to login page
UML Use Case Diagram:
Actor: Customer on Online Commerce site
Secondary Actor: Email system
Goal: create an account
Summary
Although there is much more detail needed in creating your design specification, providing clear use cases for each of your actors is critical to ensuring your team designs the application you need for your business. Since you are a team, everyone involved should contribute to the activity of defining the actors and use cases. In addition, the actors within your organization should also help define their individual use cases, keeping in mind that any individual could serve as multiple actors.
The best software systems are developed when the actual actors of the system are involved early on in the design phase of the project. This not only ensures that critical process steps aren’t missed but also enlists buy-in from the future users. So often software systems are built without consulting the users. And when presented with the final system they hate it because it doesn’t fit the way they work and worse, doesn’t give them the information they need to do their job. This can all be avoided by getting them involved early and often during the software development life-cycle.
To learn more about the importance of eliminating human error in your operations, please download the eBook titled "How to Automate Business Process in 7 Smart Steps."
