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 

Managing the Cone of Uncertainty

Some of you may not be familiar with the term "Cone of Uncertainty". In the Project Management and Requirement Management world it is often called "Scope". So what is the Cone of Uncertainty? If you have ever watched a weather report as they monitor the progress of a hurricane you will notice that the further the hurricane is from shore the larger the potential impact. As the hurricane nears, the potential impact becomes smaller and smaller as predictability improves.

It is no different in system development. Consider the early phases of a project, when we are far from understanding the potential impact of the system. Our estimates are based on what we used to call WAGs (Wild A** Guesses). Somehow these become finalized in a project schedule. I feel I must state here that we never came close to meeting that schedule. As we began to work through the requirements, our understanding of the system increased and our estimates began to change, and get closer to the truth during each phase of development.

So what can we do to manage this uncertainty? There is no silver bullet, of course. But there are some things we can do to mitigate this risk.

• Many environments change so slowly that they can be considered static. Know your environment and how quickly and often it changes.

• Before making any significant investments, uncertainty should be reduced to a comfortable level. Snap decisions are never a good thing. If there is uncertainty in new technology or new approaches, mitigate the risk with the input of experts.

• Systems engineering is volatile; external pressures increase uncertainty over time. External pressures can affect the entire development process. When those external pressures arise, assess and determine the importance of those pressures and identify their impact to the current development plans.

• You must actively and continuously work to reduce the uncertainty level. Just ignoring uncertainty will not make things any better. Identify uncertainty and meet it head on.

• The Cone of Uncertainty is narrowed both by research and by decisions that reduce variability. This is a key part of the System Engineering tasks. Document decisions and rationale and the resulting requirements so you can move on.

• These decisions are about scope, what is included - and what is not included. Continually assess what is in and what is out. Remember that today the capability might be in, and tomorrow it may be out (as Heidi Klum says on Project Runway). In an Agile environment this assessment is made almost daily.

Many process improvement efforts today are targeted towards reducing the size of the cone of uncertainty.

• Quality requirements from solid elicitation techniques

• Improved estimation techniques

• Formal requirements management

• Formal change management

• Proper and complete testing

Remember, that if these decisions change later in the project then the cone will widen. As always, requirements play a key role in managing the Cone of Uncertainty.

By: Marcia Stinson

Using Modeling during Requirements Elicitation

During elicitation requirements analysts are focused on understanding a CONOPS or Mission Statement and translating this to a more clear and concise format in the form of a requirements document. Modeling can reduce the time required for this effort and improve clarity and understanding. The following diagram illustrates the types of models that are frequently seen throughout the development lifecycle.

Models focused on the elicitation should be simple models that are non-technical in nature. These models should be easy to read and understand. Remember that their purpose is to clarify process flows or process narratives for non-technical end users and stakeholders. Moving immediately to UML or SysML type diagrams are too technical and usually too voluminous for stakeholders to read and understand.

The elicitation process consists of documenting high level capabilities, prioritizing the capabilities, and then using modeling to drill down and clarify how the capability will appear to the user. This technique can make the difference between unclear requirements and clear requirements that are validated and understood by the end users.

A good elicitation strategy is to begin with an outline of a basic process flow or use case with no alternate paths. Review this with the users and get agreement on this first. Once this is completed add alternate paths and document how they should be handled by the system. Do this for each step in the process flow. This will result in a very robust and clear set of requirements that capture details for handling alternate flows that may arise. Keep the language simple and clear and remove any information that doesn’t pertain to the flow itself.

This is the first step in understanding the user’s problem. Next is to figure out what the solution is to the problem!

By: Marcia Stinson