Numerous professional studies have shown that poorly understood software requirements are the number one cause of schedule and budget overruns and ultimately project failure. Studies have also shown that the earlier in the SDLC that scope is understood, and defects averted, the greater the cost efficiency of the project. In fact, the cost of fixing errors in the requirements phase is only 1% to 5% of the cost to fix bugs in later phases of the lifecycle (1).
It has been said that $1 spent on developing thorough, clear and concise requirements technology, processes, procedures, templates and standards is worth $100 spent on fixing a system that does not meet user requirements(1).
“Investing” in requirements engineering technology bears the following returns:
- Happier customers
- Better communication
- Lower system defects
- Reduced rework
- Faster development
- Reduced scope creep
- Less chaos! (2)
Software requirements engineering is a blend of art and science. For that reason, and because each industry (and company, for that matter) has its unique own quirks and challenges, every IT shop has its own standards and agreements around what constitutes a “good requirement”(2). However, there are some global standards that should be followed, or at least leveraged as guiding principles.
One of the chief goals of this site will be to attempt to gather and share industry standards and best practices in hopes that others in the field may benefit.
(1) According to the IEEE, more than 50% of the projects that fail are due to poor requirement definition and scope creep. The US Air Force has reported that 41% of all system defects are due to poor requirements.
(2) Ellen Gottesdiener, Software Requirements. 2005
