In a previous blog entry we introduced you to use case types and use case presentation methods (textual use cases or use case diagrams). In this entry, we will cover the five most important rules for creating use cases.
Rule #1: Follow a straight path to achieve a use case goal
A use case should be as concise as possible; when another possible route becomes evident, consider the following:
- Is the path achieving the same goal with the same actor?
- Is another actor now involved?
- Has the goal changed?
- Is the path an alternative to the main path?
In part 1 of this blog series, we had the following use case example:
|Use Case Name||Complete Customer Profile|
|Goal||Input personal information into ABC Corp online portal|
|Use Case ID||UC001|
|PreCondition||Customer has login credentials provided by ABC Corp System Admin|
|Primary Course||1. User accesses ABC Corp’s portal|
2. User logs in using credentials provided by System Admin
3. System verifies customer and displays personal details entry form
4. User enters personal details into form and clicks save
5. System presents a confirmation screen informing the user that the information has been saved
6. End Use Case
|Alternative Course||1a. System is down|
1a1. User emails personal information to System Admin
1a2. Proceed with Alternative Course 1b.
1b. System Admin enters customer information
1b1. System Admin User accesses “customer information” functionality
1b2. System Admin User enters personal information emailed by customer
1b3. End Use Case
3a. System Cannot verify User
3a1. Customer emails System Admin for credentials reset
3a2. Resume at step 3
As shown in this use case example, there is more than one way to provide personal information to complete a customer profile. We could have done one of two things to illustrate this:
- Create a new use case to indicate the email route
- Create an alternative path in this use case
We chose to go with option 2 and created the alternative path. The reason being that the alternative path still concerns the same actor, system, and use case goal (complete customer profile). In addition, there are relatively few steps involved in this alternative course to warrant creating a new use case. If there were too many steps, then a new use case would have been the appropriate action to take. If new actors and goals are introduced, it is ideal to create different use cases even though the steps may seem similar.
Rule #2: Don’t confuse use cases with user stories
Use cases and user stories are two different animals. Use cases represent formal requirements while user stories capture the benefits derived from a system function in one or two sentences (e.g., “As a customer, I want to enter personal information to complete my customer profile”) in the language of the everyday user.
Rule #3: Focus on process vs. system functionality
When working with use cases, make sure that the language and flow of the courses (primary or alternative) focus on the user’s execution of a process rather than the underlying system functionality. In a use case, we aim to capture the interaction of the user with the system and not necessarily detailed system logic.
Rule #4: Reference other use cases when appropriate
Let’s take the use case example above, which has a primary course that started to become too long. Ideally, a use case’s primary course should have no more than 10 steps. If you run into a scenario like this, determine if there are parts of the primary course that can be made into their own use case.
For instance, if a user had to go through user confirmation were they had to receive an email and confirm their credentials, then a new use case would likely need to be created. We might call this new use case “UC004: Confirm Registration”. In UC001’s primary course, instead of including steps to confirm the account, we can instead replace the steps with something like:
“Step 9. Confirm account registration see Use Case UC004”
This reference just saved us five plus lines of steps in one use case!
Rule #5: Treat “if” statements with caution
Using “if” statements as triggers to indicate different states in the interaction of the user with the system can be a bit tricky. Using the same use case example above, suppose we had not created an alternative course for an email request for login credentials. Instead, we could have stated in the primary use case that “If the system is not available, then email System Administrator” for login credentials. This could work. However, it is not a good practice because a use case with multiple “IF” triggers quickly becomes difficult to follow and the distinction between the primary and alternative courses becomes obscured. When the “if” statements start to increase, it is best to create separate use cases and, where necessary, reference them as mentioned in Rule #4.
Following these five rules for effective use cases will help you write use cases that capture system requirements and concisely describe the system’s functionality from the user’s (actor’s) perspective.