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.
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.
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
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
Requirements that are incorrect
Requirements that are poorly communicated
Requirements that are low-value
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.