First, define a list of “actors” for the project (or system). An actor is any object or person that has behavior associated with it. Generally, actors are the user roles but can be other systems, as well.
For example, the diagram below depicts actors involved in an online shopping system:
This list will likely grow as the use cases are identified and defined.
1.2 Define Basic Flows
Next, identify the primary activities, or business processes, that will need to be performed by the system. These are sometimes referred to as “Happy Path” or “Sunny Day” scenarios and represent the use cases that are most likely going to occur when all goes well. Always focus on these scenarios first because you can then use these to determine the “rainy day” scenarios (or edge cases) later.
Since these basic flows will form the basis for the use cases, you may want to identify them with the same naming convention that will be used for the use cases: <action> + <object> (e.g., “Create Account”) and indicate the actors involved.
Once you have identified the basic flows, they should be reviewed by the project team to ensure that none have been missed.
1.3 Define Alternate Flows
After the list of basic flows has been established, define the list of alternate flows (also called “rainy day” or “edge case”) scenarios for each.
Once the alternate flows have been defined, prioritize each in terms of likelihood to help during the development or selection of a solution with regards to how much emphasis to place on a scenario that is not likely to happen.
1.4 Create Visual Model
The purpose of a use case diagram is to provide a graphical representation of the interactions between users and the system and can include associations (connectors) to show dependencies between use cases, where applicable.
Because half of the human brain is directly or indirectly devoted to processing visual information, providing a diagram can result in better conceptual understanding and recall than words alone.
A graphical depiction of the uses cases and their actors can be a great tool to use for reviews to help ensure that all the use cases that need to be defined have been identified.
1.5 Create Index
After producing the initial list of basic flows, create a master inventory list to use for further definition of the use cases (requirements) for the project. Each use case will have various attributes relating both to the use case itself and to the project. These attributes typically contain information to identify and indicate the importance and effort of the use case (e.g., priority of the use case, actors involved, complexity to develop, whether the use case is in scope for the release or identification of the iteration/sprint, if using an Agile development methodology).
2. Use Case Documentation
After the Index has been created, begin documenting the actual use cases based on the attributes defined and the project team priorities.
Typically, a use case contains the following components:
Unique Identifier
Name
Description
Actors
Pre-Conditions
Basic Flow
Alternate/Exception Flows
Post-Conditions
Visual Model (optional)
2.1 Unique Identifier
Each use case should have a unique identifier that can be used for quick reference and traceability.
The naming convention used for this identifier should be simple and meaningful. The format is usually decided by the project team.
2.2 Name
The use case name should be simple but descriptive and indicate the activity that will be defined in the use case. Typically, the name takes the format of verb-noun or +<action>+<object> (e.g., “Create Account”).
The use case name has likely already been defined when the basic flows were outlined and are included in the Index.
2.3 Description
This should be a brief narrative (a sentence or two) about the use case goal and include information to frame the scope of the use case such as “This use case starts when…” and “This use case ends when…”. This is important because when defining the steps for the Basic Flow and Alternate/Exception Flows, it’s easy to get off track and stray from the steps that need to happen for the specific goal of that use case.
2.4 Actors
Define all the actors (user roles or systems) that will engage in the activities described in the use case. An actor is any person or external system that interacts with the system to achieve the goal of the use case.
There are two kinds of actors – primary and secondary.
A Primary actor is anyone or anything that interacts with the system to gain direct benefit.
A Secondary actor is anyone or anything that is involved in achieving a use case but does not gain direct benefit from the use case.
Frequently, a secondary actor assists the primary actor to achieve a use case.
2.5 Pre-Conditions
Indicate what elements that must be in place prior to the start of the use case. For example, for the “Place Bid” use case, a pre-condition might be that users with permission to use the system have an active account with credit card information associated.
2.6 Basic Flow
This should detail the step-by-step procedure that must occur to achieve the primary goal of the use case. In other words, a sequential list of the actions that are taken by an actor and how the system responds to those actions.
The steps below show the Basic Flow for a “User Login” use case:
User launches site in browser
Login screen is displayed
User submits valid username and password
Main page is displayed
2.7 Alternate/Exception Flows
Alternate flows explain less common actions that could happen, but are not error based.
An alternate flow for the “User Login” use case would be if a user’s password has expired and he/she is prompted to enter a new password
Another alternate flow would be if the user is on a different computer and must answer a security question
Exception flows detail what happens when something goes wrong and the user cannot achieve the goal; an exception or error flow to any line item in the basic flow.
An exception flow for the “User Login” use case would be if a user enters an incorrect username and/or password.
2.8 Post-Conditions
Post conditions are those elements that must be present when the use case is completed in order to be deemed successful.
For the User Login example, the post-condition would be that the user can proceed to use the system.
2.9 Supplemental Requirements
This section is used to document requirements that are not directly related to the actions but is important information (e.g., business rules, data limitations, constraints, etc.) that must be considered.
