The 8 Goals of Use Cases

Why do we write use cases?

We write use cases for the same reasons that people use our software - to achieve goals. In our case, we want to assure that we are creating the right software. By looking at this high level goal in more detail, we can make decisions that drive the best possible use case creation. Let’s apply our product management skills to writing better use cases by writing an MRD for use cases.

This article can be used as a guide to develop a process for defining, documenting and gathering use cases. It can be used to define a template for use cases, and it can be used to define specifications for a use case management system. We will start with a market analysis and a vision statement, and then create our market requirements.

Market Analysis

• 69% of software projects failed or were delayed in 2003 according to the Standish Group’s latest study.(1994 study, 2001 study)
• 40% to 60% of problems were attributed to bad requirements.
• Current investments are focused on coding efficiency not requirement quality.
• Incremental delivery is becoming more common as teams adopt different forms of agile processes. This increases the frequency of requirements changes during projects.

Bad requirements are further detailed as the following:

• Requirements that are overlooked cause us to fail to meet expectations and fail to deliver value.
• Requirements that are incorrect cause us to incorrectly address problems and fail to deliver value.
• Requirements that are poorly communicated cause us to implement incorrectly, failing to address problems and deliver value.
• Requirements that are low-value cause us to spend time and money on problems that don’t maximize value.

Through the course of any long term project, requirements will change. This happens more when we use iteration and prototyping to accelerate stakeholder feedback cycles. But that’s a good thing, because the changes result in better requirements. Agile development methodologies like feature driven development supercharge this phenomenon.

Vision Statement

We will improve our ability to write and manage use cases so that we may maximize their impact on

• Writing and maintaining great requirements
• to improve our ability to deliver the right functionality
• and ultimately achieve software product success

Market Requirements

With an understanding of the market problems and a guiding vision, we will document the market requirements for writing better use cases. The market requirements have an explicit scope - they specify which and how much of the market problems we intend to address.

When we use the phrase ‘our use cases‘, we are really saying ‘our use cases and our approach to managing the use cases.’ We’re using shorthand to improve the readability.

Prioritization of the requirements is denoted with (H) (M) or (L) prepending the requirement, representing high, medium and low priority requirements, respectively.

Requirements that are overlooked

• 1. (M) Our use cases must support validation of requirement completeness. [Update: Detailed article on this goal.]

Requirements that are incorrect

• 2. (L) Our use cases must support validation of requirement correctness. [Update: Detailed article on this goal.]

Requirements that are poorly communicated

• 3. (H) Our use cases must improve communication with stakeholders about the intended content of the system. [Update: Detailed article on this goal.]
• 4. (H) Our use cases must improve communication with the implementation team (dev + test) about the intended content of the system. [Update: Detailed article on this goal.]
• 5. (M) Our use cases must improve communication about the release-planning (delivery schedule) for the system to both stakeholders and implementers. [Update: Detailed article on this goal.]
• 6. (H) Our use cases must improve communication of the scope of proposed requirements changes to developers.
• 7. (L) Our use cases must improve communication of the impact of requirements change proposals to stakeholders.

Requirements that are low-value

• 8. (L) Our use cases must support prioritization of requirements across releases.

Conclusion

These goals define why we write use cases as part of software development. We do it to improve our ability to write the right software to solve our customer’s problems. We also write use cases to help us manage requirements changes and set delivery expectations with our stakeholders.