Write a Requirement, not a Solution
The authors of Mastering the Requirements Process, 4th Edition discuss how proper descriptions, rationales, and fit criteria make for requirements that describe your real need, and don't prescribe a solution.
From the author of
From the author of
From the author of
One perennial difficulty we have encountered in our requirements work is stakeholders telling us what they think is the solution to the problem, but they don't tell us what problem they are wanting to solve. The stakeholder's solution might be the right solution, but then again it might not. Our experience is that presumed solutions usually do not solve the problem. Not solving the right problem leads to expensive rework after the solution is implemented.
Sometimes this is attributed to "changing requirements," which is wrong. It's just that the right requirement was not discovered in the first place.
So, how do we write the requirement and not a solution?
In our requirements work, and in our books, we advocate that you write requirements with three main attributes: the Description is what the stakeholders say is needed; the Rationale is the justification of the requirement; and the Fit Criterion is a measurement of the requirement that allows testers to determine if the delivered solution matches, or fits, the requirement.
Figure 1 is the Volere snow card showing the attributes of a requirement. We will concentrate on the main three—Description, Rationale, and Fit Criterion—and ignore the rest of the card. The other attributes have their uses, but they are not relevant for our purposes here.
Figure 1, the Volere snow card. You would most likely use an electronic version of the card for your requirements.
Click to open full-sized image
Let's just look at how the three main attributes ensure that you write the correct requirement.
The Description is the intention of the requirement. It is what people normally say when you ask them about requirements. The description is usually written in the form, "The product shall..." and then specifies an action that the product has to take to contribute to solving the business problem. Sometimes descriptions can look awfully like solutions, but that doesn't matter too much, because you are about to expose the real requirement by adding a Rationale.
You arrive at the Rationale by repeatedly asking "Why?" You are seeking the underlying reason for the requirement, and by finding it, you get a deeper understanding of the business problem for both you and your stakeholders. For example, let's say that you have this description of a requirement:
Description: The product shall record the start and end time of a truck's scheduled activity.
This is a normal kind of requirement, one that would not cause much comment. But does it contribute to solving the business problem? It doesn't look all that important and might be one of those "throwaway" requirements that people request for no good reason. Let's look at the rationale to justify this requirement:
Rationale: Trucks are to be scheduled a maximum of 20 out of 24 hours to allow for maintenance and cleaning.
Now we know why this requirement exists, and we know its value. We know that if it was not part of the final solution, then the truck fleet would suffer and possibly cause the business activity to fail in some way.
Additionally, now that we know the rationale and thus the value of the requirement, the developers and the testers know how much effort they should expend on it. It also indicates to future maintainers why the requirement exists in the first place.