Prerequisites? Do you really need them?
YES!!!
I have had many discussions about requirements, if they are needed, and then
if they are really needed. By this I mean, some people say they are needed but they don’t really believe it or at least they don’t know that they don’t believe it. Then you have the rare few who not only know in their mind, requirements are needed, but they know it in their hearts. IE: They actually do it.
You can easily distinguish the two. One will demand requirements are written down and are the soul foundation of the project, the other will think they should be written down but they would rather get coding than push for it.
The relative average cost of fixing a defect based on when it is found is as follows:
Requirements Architecture Construction System Test Post-Release
1 3 5-10 10 10-100
Clearly, discovering requirement defects, (IE: incorrectness, omissions, conflicting), is cost prohibitive.
Quote from Code Complete:
“Iterative approaches tend to reduce the impact of inadequate upstream work, but they don’t eliminate it.”
“One common rule of thumb is to plan to specify about 80 percent of the requirements up front, allocate time for additional requirements to be specified later, and then practice systematic change control to accept only the most valuable new requirements as the project progresses.”
“Some projects spend too little time on prerequisites, which exposes construction to an unnecessarily high rate of destabilizing changes and prevents the project from making consistent progress. Some projects do too much up front; they doggedly adhere to requirements and plans that have been invalidated by downstream discoveries and that can also impede progress during construction.”
“If the requirements are explicit, the user can review them and agree to them. If they’re not, the programmer usually ends up making requirements decisions during programming.”
“A plan to follow the requirements rigidly is actually a plan not to respond to your customer.”
“How much change is typical? Studies at IBM and other companies have found that the average project experiences about a 25 percent change in requirements during development (Boehm 1981, Jones 1994, Jones 2000), which accounts for 70 to 85 percent of the rework on a typical project (Leffingwell 1997, Wiegers 2003).”
“Generally, a well-run project devotes about 10 to 20 percent of its effort and about 20 to 30 percent of its schedule to requirements, architecture, and up-front planning (McConnell 1998, Kruchten 2000). These figures don’t include time for detailed design – that’s part of construction.”
