5 Rules for Writing Effective Use Cases

July 10, 2018

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
Actors Customer
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:

  1. Create a new use case to indicate the email route
  2. 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.

When “Good Enough” isn’t Good Enough

October 11, 2011

So what is this picture? The unhelpful answer is that it is a photo of a sign with a burlap sack on it. I’d like to say that my community thought it would be a cute Halloween decoration, but I cannot. The truth: it is great example of the “good enough” anti-pattern. Read more

Walk Softly and Carry a Proper Meeting Recap!

May 16, 2011

You know the drill:

It’s late Friday afternoon and someone tosses an email or instant message your way regarding what you thought was a resolved topic. Read more