It amazes me how no one would ever consider building a house without a blueprint but time after time we tend to rush into coding before the requirements and designs have been fully thought out.

I use to think that this was a problem inherent with smaller companies with huge pressures to be faster to market but I have seen this in large companies as well for other reasons.  Often with big companies the task of gathering and maintaining the requirements of significant project can be overwhelming and if the process is not strictly followed, it will quick become out of control.

Requirements are the foundation that QA builds upon and always references back to.  The goal of QA is to prove that the solution delivered meets all the requirements as requested.  If we are not clear on the requirements or if the requirements are modified through the process but not documented, how can we prove that the solution provided is sound?

With the trend of SDLC methodologies going towards a more agile approach, this analogy still holds true.  The emphasis in Agile is to have a more practical approach to documentation which could mean less in quantity but not less in quality.

I have seen agile projects where they try to figure it out as they go and this just leads to a tremendous amount of frustration and wasted effort by everyone.    In one agile project I was on, the marketing team outlined the requirements to the team and then while we worked on the first iteration milestone, they redesigned the exact same area for the next milestone!  When we produced the first milestone, it was a mess and everyone was let down.  One of the developers described it as “the public spanking”.   Marketing was disappointed because their vision had completely changed and  this was their old vision, not their new one.  Development was frustrated at having to go back and rip up all the code they had just finished building.    No one walked away feeling that they had done a good job despite all their hard work.  Had the marketing department held off with the requirements so that the majority of the requirements were sound and not rushed to start coding so quickly, it would have saved everyone a lot of frustration.

It is never an easy think to halt the process and say “we aren’t ready yet” but better to do this early in the process then to allow the building to start and have the house fall down.  Not only is it costly, it kills the team moral.