- An Investment Story
- Investing in Requirements
- Return on Investment
- Investment Risks
- What to Invest In?
- To Invest or Not to Invest
- Investing in Requirements
- Size of Requirements
- The Value of Requirements
- Reusing Requirements
- What Do I Do Right Now?
- What's the Least I Can Get Away With?
- Additional References for Requirements Value
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Value of Requirements
We have discussed the idea of investing in requirements, and thereby the project. As a requirement is a demand for something to be built, we also discuss the idea of whether it is worthwhile investing in building a solution to a requirement. In Mastering the Requirements Process, the authors referred to collecting the requirements as "trawling."
Trawling is a peculiarly British word that refers to deep-sea commercial fishing. The boats, or trawlers as they are known, use large nets, sometimes incredibly large, to drag through the oceans for their catch. The idea of running a net through the ocean for fish is analogous to dragging a metaphorical net through the organization to gather up requirements (see Figure 2.5). By using a net, a fisherman catches species of fish other than what he wants. Similarly, the diligent requirements analyst dredges up not only trivial or low-value requirements but also more requirements than can be built in the time allowed.
)
Figure 2.5 Trawling for fish has similarities to trawling for requirements.
Not all requirements are of equal value to the organization. This makes it worthwhile to consider the value of each requirement before deciding whether or not to build it. We refer to this as customer value, with the inference that you ask your customer, "How important is this requirement to you?" Keep in mind if you ask a customer to grade a requirement as high, medium, or low, the customer will tend to grade almost all the requirements as high importance. Such is human nature—if I tell you that everything is of high importance then I believe I will get more of my requirements implemented regardless of their importance.
Another thing that fights against grading a requirement as high, medium, or low is the expectation embedded in the term "requirement." If I call something a requirement the implication is I definitely need you to give it to me. Within systems engineering we have a different meaning for the term—in fact, it would be more accurate to talk about wishes.
A requirement is something somebody wishes to have implemented but no guarantee exists it can be implemented until we know all the requirements and can determine which ones can be implemented within the constraints. Given this reality, it makes sense to make requirers aware they will need to make choices and to provide them with a mechanism for considering choices early.
We have adapted William Pardee's idea of customer satisfaction and customer dissatisfaction [3] as a way of helping people to consider the relative importance of their requirements.
Pardee suggests you ask two questions about any requirement:
- "On a scale from 1 to 5 how satisfied will you be if I implement this requirement?"—where 1 means you don't particularly care whether the requirement is implemented and 5 means you will be extremely pleased if it is. (The scale of satisfaction.)
- "On a scale from 1 to 5 how dissatisfied will you be if I do not implement this requirement?"—where 1 means you are unconcerned if the requirement is not part of the product and 5 means you will be extremely unhappy. (The scale of dissatisfaction.)
The idea behind Pardee's thinking is that if your customer has a large-enough continuous scale, he can give you a more accurate indication of importance. The notion of having two scales is even more helpful. For example, the customer considers some requirements to be natural or part of the existing system, and thus the customer sees no reason why they would not be contained in any future product.
In the situation of "natural requirements" the satisfaction rating is likely to be low: The customer is not going to get excited if you deliver something already there. However, if you do not deliver the requirement, dissatisfaction is likely to be high. Conversely, if a customer considers a requirement to be a trivial piece of gold plating, it will garner a low dissatisfaction rating.
We have found Pardee's way of measuring satisfaction and dissatisfaction superior to the commonly used scale of "must have, nice to have, fit it in if you get time."
A simple way of determining the future of a requirement is to add the satisfaction and dissatisfaction scales. Any requirement that has an aggregate score of four or less should not be implemented. Then, starting with the highest aggregate scores, implement as many requirements as you can in the allowed time. However, to make your implementation decision, weigh the customer value against the cost of implementing the requirement. In other words, just because a requirement has high customer value does not necessarily mean it will be pos sible to implement it. In Chapter 9—Managing the Requirements, we discuss the subject of progressive prioritization and prioritization techniques.