Why Bother with Requirements?
Numerous studies have shown that some of the top reasons for the high rate of project failure result directly from requirements problems. Lack of requirements, misunderstood requirements, vague requirements, incomplete requirements, and changing requirements all are major failure points in system development. Such failures waste precious money, resources, and time. You have to know where you are going, or you'll never get there. That is the purpose of requirements.
Sometimes, I hear developers say they don't want to be saddled down with requirements. When asked “Why?” they often respond that they want or need to get started coding. But what will you code? That's like a builder saying he has to hurry up and lay brick, without really knowing where the property lines are, the orientation of the house, its size, where the utilities are, how many chimneys to build, or even if the homebuyer wants a brick house.
Also, rework is costly in construction of homes or in construction of software. The cost rises as time passes [LEFF2] (see Figure 3-1).
Figure 3-1. Cost to repair defects over time.
Also, without requirements, how do you know when you are done? Without the requirements to specify what needs to be built, the customer can keep telling you to change this or that ad nauseam (also known as scope creep). Having agreed-to requirements sets your goal, and you can execute tests against them to prove to the customer that you have reached that goal. Without requirements, you may never be “done” until the customer says so. If your original excuse for not having requirements was to get started coding sooner, wouldn't you also want to be done sooner? In addition, if you are working under contract that doesn't clearly define what you are to deliver, you might wait a long time for your payment.
Well-documented requirements will enable you to validate that your team is building what the customer expected. With the many regulations that exist throughout different industries today, such as BASEL II, Sarbanes Oxley, 21 CFR Part 11 [BASE1], and others, it's more important than ever to be able to prove that you are building what you said you would.
Requirements comprise the contract between you and your stakeholders that specifies what the system you are going to build will do to support their vision of the business (as expressed in the business models). In the end, you do not want to hear that what you built is not what they wanted. That scenario can cost you too much time, money, and maybe even your job or your business.