There is never enough time to do it right the first time, but always enough time to go back and do it again! – unknown

I’ve worked on projects where too much time was spent developing requirements, waiting until they were perfectly defined (which they never were), only to guarantee excessive time and cost overruns which ultimately resulted in the projects’ failure. In these cases, “great” was the enemy of “good.” I’ve also worked on projects at the other extreme where the requirements were merely a general idea stated in one or two sentences. Both of these examples represent inefficient project development and lead to excessive project costs. The goal is to find the optimal balance between these two extremes and ultimately minimizing the software development costs. The question should not be whether defining requirements are worthwhile for your project, but to what level of requirements will provide the “optimal” cost-benefit.

Should you devote 1 day, 1 week, or 1 month to the requirements phase on your project? Should your requirements be 1 page, 5 pages, or 50 pages? The optimal cost-benefit balance is dependent upon numerous software project factors including platform (PC, web, embedded system), complexity, safety, budget, and customer. However, I believe that there are “common sense” guidelines that, if applied, will help you find the optimal balance for your project.

In Part 2 of this blog series, I will provide some specific reasons on why  requirements are important, and then in Part 3 I will continue by giving you some practical “how to” tips on developing requirements.