Quality writers are writing about requirements. Requirements writers are writing about quality. Just like the Reese’s Peanut Butter Cup – Two Great Tastes that Taste Great Together. You can’t have one without the other.
Quality
The Business Analyst Blog writes about speeding up testing:
Everyone has suggestions about how to improve your testing—implement a testing process or methodology, utilize IEEE standards, work towards CMMI compliance, etc. No one mentions that improving requirements will improve testing! […] Why does it take so long? I would argue that one of the main reasons is that poor (or missing) requirements slow down the process as much as any other issue.
Well said. If we’re testing for the wrong things, we’re wasting time and resources.
Requirements
The Software Quality Blog writes about requirements best practices:
No process is more fundamental than the process of defining and managing business and technical requirements. It’s no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.
Well said again. The Standish Group estimated that 40% to 60% of defects were due to errors in requirements, not code.
Convergence
In Where Bugs Come From, we showed that having the requirements errors happen throughout the process, not just at the beginning of the process. Numbers 3 and 4 of the following list are the painful and visible impacts of the problems both of our authors above are addressing. And those errors are introduced in numbers 1 and 2:
Requirements errors can happen
- When stakeholders incorrectly define their goals. A focus on ROI is the best way to assure that our stakeholders are focusing on the right part of the business. Elicitation techniques help us to drive this process in a way that tends to focus on the right requirements. The centerpiece of elicitation is interviewing stakeholders – both users and beneficiaries of the system.
- When product managers / business analysts incorrectly document stakeholder goals. Writing good requirements is an absolutely masterable skill. Check out these top ten tips for writing good requirements.
- When developers write unit tests of the wrong implementation. Even with a great continuous integration strategy, all we end up doing is efficiently testing the wrong stuff.
- When test teams assure that the wrong requirements have been implemented. We waste time testing requirements that aren’t really requirements. And we waste time tracking down false positive defects.
Conclusion
When we’re selling the value of requirements engineering, use this argument to explain the benefits (or impacts) of good (or bad) requirements. When we’re responsible for implementation (dev and test) on a project, remember why we care about requirements. It isn’t enough to verify that requirements are implementable. We have a vested interest in validating that the requirements are also complete and valuable.
Sidebar
[disclaimer: I am a bit of a dork.] I cracked myself up today when I typed “errors of omision”.
