Classic Use Case Mistakes

Over the years I have come to understand the role of use cases in the requirements definition activities. They are very valuable if done properly. The problem I continue to see in many organizations is that they are not done properly. So what are some of the mistakes that can help ensure you are getting the most value from your use cases? 

Mistake Number 1: Creating inside-out user cases. 

Results: Use cases that are written from the perspective of the system, not the user. These use cases are often complex and technical. The problem is that most of the time users don’t understand this because it is not natural to them. This makes it difficult to get valuable feedback from the users. 

Actions: Make sure the user’s perspective is maintained when writing use cases. 

Mistake Number 2: Including user interface details in use cases.

Results: Use cases that include a lot of steps that really don’t contribute to understanding how the user will interact with the system. You may see details about where error message are displayed, radio buttons, links, other details about a screen that add to the confusion. Often use case writers try to include every possible action as a part of the use case flow. For example, every possible selection has an alternate flow titled “User Selects Cancel Button”. Adding all of these alternate flows results in a use case that is much more complex that it needs to be. 

Actions: During requirements gathering keep the user interface details out. They are a distraction from defining the interactions that need to occur. Consider keeping user interface requirements in a separate section. This can be used as a checklist when testing to make sure the entire set of interface requirements are met for each screen. 

Mistake Number 3: Expanding the system boundary. It is difficult to keep in mind the scope of the system you’re developing. For example, consider other systems that interact with the system under development. Is it inside the boundary? Is it an actor? Should it not be shown on the use case diagrams? Results: When actors are included which are outside the control of the team, a lot of time is spent documenting a system that already exists and will not be changed. A lot of time will be spent explaining to users that the system just “works the way it does”. You are better off not including details about systems that are outside the boundary of the system. 

Actions: If the team is responsible for implementing and testing it, then it is inside the system boundary. If it is a separate system done by a separate team, it becomes an actor. 

Mistake Number 4: Creating use case interactions that don’t provide value to an actor. 

Results: Use cases that don’t provide any value to the actor. These use cases may not be derived from business requirements. Or they may be derived from business requirements but don’t contribute to the overall goal of the business requirement. 

Actions: Make sure every use case has a clearly stated goal that provides a benefit to an actor. Note that the actor that benefits does not have to be the primary actor in the use case. 

These are typical mistakes made when writing use cases. Many times the end result is a set of very long, very complex, and very technical use cases that provide very little benefit to end users or developers. Consider training your team on writing good use cases before just throwing them out the use case wolves. It will be worth the time and money spent to ensure use cases are providing the maximum benefit to your project.

(Reference: Use Cases: Requirements in Context by Kulak and Guiney)


 By Marcia Stinson