We have written much on requirements in other blog posts.  We have been maintaining this blog for years, admittedly sometimes more fervently than others.  We have created a schedule for our blog posts and other events by Value Transformation personnel available either on the event location on the website or as a downloadable from the website.

There seems to be a myth that “waterfall” development requires ALL of one step in the delivery sequence before the next step can begin.  For example, all requirements must be written before work commences on the development work.  I have worked in what I would call traditional development approaches that some would refer to as waterfall, and at no time did we believe or act as if all requirements must be known and documented before we moved to the next stage, the actual development.  Even PMI recognizes the need work with the level of detail that can be known from where the position presently, often referred to as progressive elaboration. That is, as we learn more about what needs to happen either product or project, we take the requisite action.

To illustrate some of what is known about requirements and project success, benefits from an introduce function point.  A function point is a unit of measure regarding functionality of a product or system. The larger the number, the more functional content in the product.  From this information, a correlation between functional content and cost and time can be derived, only if these things are recorded and tracked.  For more information on function points, please visit the International Function Point Users Group.

In a large sample study by Capers Jones[1], the data shows as function points increase, so too does the rate of project cancellation. For example, 40% of 10,000 function point projects are cancelled and 65% of 100,000 function points are cancelled.  In another larger scale study, we see that as function points increase, requirements volatility increases[2].  Requirements volatility amounts to numerous change requests which is a type of rework and can often be considered waste.

Those that think a conventional approach to product development often referred to as waterfall, requires all the requirements up front are probably setting their endeavor up for failure.  Studies and experience more than suggest an incremental and iterative approach responding to what is learned during doing the work.  This is an advantage to taking an agile approach in which there is not even a hint that all of the requirements must be known before doing the development work.

[1] Jones, C. 1996. Patterns of Software Systems Failure and Success. International Thomson Press.

[2] Jones, C. 1997 Applied Software Measurement.  McGraw Hill.