One of the ten big rules of writing a good MRD is writing complete requirements. We identify problems and opportunities in the market. We determine that one of these problems is valuable enough and practical to implement. Then we have to write the requirements, and make sure that the requirements will completely solve the targeted problem.
The Big Rule of Writing Complete Requirements
From our previous article, Writing Good Requirements – Big Ten Rules:
Simply put, if the requirement is implented as written, the market need is completely addressed. No additional requirements are required. When writing a specification, we may use decomposition to break individual requirements into more manageable, less abstract criteria.
No Silver Bullet
Unfortunately, there is no silver bullet that we can apply to make sure that a requirement is complete. The best we can do is explicitly check it for completeness. And there’s no gaurantee that we will be right – our analysis is only as good as we are.
Pragmatic Marketing has a coffee mug that helps us with this.
Their message is simple – use data to support everything from valuation to prioritization to completeness verification. Don’t use opinion.
Imagine the following market problem for a mom-and-pop exterminator:
We aren’t making enough money from quarterly treatments. Our technicians are completely booked, but they spend at least three hours a day driving from job to job – double the industry average. Our prices are competitive, and our costs are in-line with the industry. We need our technicians to perform more treatments per day. Spot checks of a few previous schedules revealed that travel time could be reduced by 70% if we reorganized the treatments to minimize travel time.
We could write a product requirement as follows:
We need software that determines the better routes for our technicians each day. The optimal route is the one that requires the minimum travel time between each location, and between the office and the first location. Our software must generate routes that are 50% better than our existing process. Our dispatcher will be able to use these routes to plan each technicians schedule for the day. Note: The dispatcher will communicate the daily schedule to each technician at the beginning of each shift.
Analysis
We have data. Prices and costs are reasonable, but profit is unacceptable. Technician efficiency is the identified culprit. We’ve written a software requirement that should provide us with an improvement. We’ve assessed the potential value (50% reduction in travel time) and validated that it is feasible (70% reduction for manual spot-checks). We’ve even established critera for testability of the requirement (50% improvement over existing process – we can use historical data to validate the software solution).
Completeness
Well, it looks complete.
In our example, however, we didn’t do enough research. If we implemented software that provided more efficient routes, we would not get more efficient route execution – here’s why:
Additional research reveals that 80% of the time, the technicians have to return to the office to pick up more treatment chemicals because they didn’t bring enough with them for the whole schedule, or they have to cancel the last job of the day to account for drive time to return left-over chemicals to the office. The technicians can not take the pesticides home with them, and try to avoid a return trip to the office at the end of the day. If they use up all of the chemicals, they can drive directly home from the last appointment.
We need to add a requirement that our software also include planning of the amount of chemicals to take on each day.
Conclusion
Completeness comes from analysis. And our degree of completeness comes from the quality of our analysis. There is no silver bullet, we just have to think. Remembering to validate completeness, and base our decisions on data gets us half-way there, but we have to get ourselves the rest of the way there.
One thought on “Writing Complete Requirements”