We are often asked this question. It is common to see cases where projects over specify their requirements for a product. In one of our classes, we were told that one government organization had defined over 4,000 requirements for a single instrument!!
Mandatory characteristics for any requirement is that it is Needed, Verifiable, and Attainable. I call these the NVA characteristics. In other blogs “Is the Requirement Verifiable?” and “Are the requirements Attainable?” I address the “Verifiable” and “Achievable” aspects of good requirements. In this article, I will focus on “Needed”.
If a requirement is not needed, why is it in the requirement set? The goal during the Requirement definition phase is to define a necessary and sufficient set of requirements that clearly and completely communicates stakeholder expectations to the design team – and no more. In an earlier blog, “How do you know your requirements are complete?” I discussed the activities you need to do to get the knowledge needed to develop a complete set of requirements. In this article, I address the problem of going overboard resulting in too many requirements.
By its very existence, a requirement has a dollar value associated with it because all requirements need to be maintained, managed, and verified. Requirements that are not necessary result in increased management cost of the requirements which, in turn, increases overall project costs and leaves fewer resources for “needed” requirements. Un-needed requirements result in work being performed that is not necessary and take resources away from the implementation of those requirements that are needed. In addition, implementing requirements that are not necessary may result in degraded system performance as well as introduces a potential source of failure and conflict.
Implementation
Often, when there are an excessive number of requirements, a common cause is implementation (i.e., design) creeping into your requirement document. Remember when developing your “design-to” set of requirements, the focus should be on the “what” not “how”. You tell the designers “what” you need, and they come up with a design – “how”.
Gold plating
Another major cause of excess requirements is “gold plating”. Gold plating is the act of adding features to a system that are not needed. How can you identify requirements that are gold plated? If a requirement cannot be traced to a source or there is no trace to a parent, it could mean that the requirement is not needed, and thus, is gold plating. Be sensitive to gold plating as this is a major source of requirements creep and can have a significant impact on the cost and schedule of your project.
Zero-based Requirement Definition
To help combat uncontrolled growth of requirements, we advocate that organizations employ a “zero-based” approach to developing their requirements and maintain this “zero-based” approach in project execution. A “zero-based” approach means that all requirements are thoroughly evaluated by the project for applicability to meeting stakeholder expectations defined during scope definition and thereby “earn” their way into the requirement set.
To test for requirement need, ask:
1) Why is the requirement needed? Why is it in the requirement set? What role does it play in the realization of the stakeholder expectations defined in the product Scope? If there is no rationale, or a weak rationale for its existence, consider deleting it.
2) What would happen if we deleted this requirement – would the developer address this concern anyway? If nothing would happen or the developer would have to address this concern anyway to meet other requirements, then why is it in the set? Consider deleting it.
3) Is the intent of this requirement addressed by other requirements (possible duplicate)? If so, consider deleting it.
4) Is the requirement communicating “how” to do something (implementation)? If not justified, consider deleting it.
5) Is there a trace from the requirement to a source? If it cannot be traced to a valid source, why is it in the set? Consider deleting it.
6) Does this requirement apply to the level (e.g., system, subsystem, assembly, subassembly, component, etc.) you are writing requirements for? The requirement may be valid, but not for that level. If the requirement is not being stated at the correct level, move it to the correct level.
Conclusion
Adopting a zero-based approach to defining requirements and asking the above questions for each requirement will help greatly in avoiding specifying requirements that are not needed. The end result? A necessary and sufficient set of requirements needed to communicate stakeholder expectations to the design team – and no more.
As with all our blog posts, your comments on this topic are welcome.
If you have any other questions, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.
