As discussed is this week’s Podcast, Blueprint will be contributing a second whitepaper to the consortium focused on the business case of improving requirements practices within an organization. In this whitepaper (written by David Nyland, Blueprint’s President and CEO), there is an objective look at the drivers of investment in the front end of the application lifecycle, and the need for companies to organize their efforts for upfront “health” and efficiency.

An excerpt from the paper on why the traditional approach fails to address modern challenges:

With today’s requirements health issues, no paper-based approach to requirements definition will work (no matter how mature the process and organization). This is because the volume and level of detail of requirements has reached a level requiring many volumes of requirements specifications, prepared by multiple business analysts, which will result in a library of cumbersome documents that are impossible to review and validate. Due to the arduous manual effort required to create them, they would likely be out-of-date and impossible to efficiently maintain by the time they are completed.

For complex systems, dense paper-based approaches also fall short in terms of effectively providing efficient communication of requirements to developers and testers as these types of requirements are intimidating in their size and density, difficult to navigate, and arduous to comprehend. This situation exacerbates exponentially when using offshore and distributed developers and testers.

Finally, with large dense paper-based requirements, maintenance and change impact assessment is almost impossible, since many loosely coupled documents quickly get out-of-date and very rarely is there budget or impetus to manually and methodically maintain them. Often analysts turn to the actual system (rather than the requirements) to assess the impact of change.

An excerpt from the paper on the impact of up-front investment:

Organizations that deal with increased communications complexity and change impact assessment problems by adopting best-practice approaches to requirement definition spend between 10-30% of project time on requirements definition; and have substantially less rework, fewer cost and schedule overruns, and fewer defects found in production. The concept of “spend the time at the beginning to get it right” is a scientifically proven approach that works (and in Agile development, this effort is built into each sprint). It’s about working smarter, not harder, so the time invested in requirements health is an investment in preventing expensive and disruptive remedial actions later – expensive to IT, and expensive to the business. Organizations that actually utilize best practices to achieve complete and detailed requirements definition have high-quality requirements, and get massive payback in terms of low rework, predictability, and accelerated software delivery (assuming that at some point there is a diminishing margin return in adding more detail, and business analysts must be careful not to intrude on the work responsibilities of the systems analysts).

This paper will be made available next week.