While user requirements do often change, it is the job of the development organization to manage these changes in a controlled fashion and assure that requirements do not change or grow unnecessarily. Pity the poor programmer who started off writing a basic arithmetic calculator, agreed to add square roots and a few other user requested functions, then a few more, and even a few more, and soon had the task of developing a sixty-five function scientific calculator. Modifying or adding new requirements can happen for many reasons, not the least of which being the failure to honor Commandments One and Two.
Another reason requirements grow beyond their original scope is simply that software is so easy to change compared to hardware. No one would purchase a calculator at the local electronics store and then expect the manufacturer to add additional transistors to the calculator chip to implement a new function. If the calculator was a software application, no one would think twice about the ability to add a new function.
Perhaps an even more common reason that requirements change is due to the programmers themselves . Many a programmer has accepted a new user requirement not based on valid business reasons but simply to please a user. Other times the software may be fully functional and pass all unit test requirements, but the programmer just wants to add one more feature to make the application "just a little better." Good developers always want their code to be perfect in their own eyes. The cost of making even simple changes, however, is minor compared to the cost of the retesting and requalifying that may result.
This does not mean to say we are against iterative development. In Chapter 10, "The Software Life Cycle" , the use of iterative or spiral development is prominently discussed. Even in a spiral development model, however, new requirements are introduced at the start of each new iteration, not continually during the development process. Since requirement changes impact project budget and schedules, only allowing changes at set points in the software life cycle allows time to trade off the value and validity of each new proposed requirement against its cost. Meanwhile, developers can complete each stage with a frozen set of requirements, speeding the total development cycle.
Object-oriented and component-based software technologies help further isolate the impact of many requirement changes. Still, requirement changes are a constant problem for many software projects. Part of this is the developer's fault. Luckily, managing requirements is mainly a process issue rather than a technical one. Here are some ways to help prevent requirements from constantly expanding beyond their original scope:
Document all user requirements, allowing the users to review the completed requirements document and agree to its completeness;
Get users to agree up-front that future requirements changes will only be accepted after being evaluated for schedule and budget impacts;
Practice iterative development. Get users and developers to understand that the first version is not the final version. That "one last change" can always wait for the next version. Many a software system has suffered unexpected delays because a simple last-minute change rushed through just before release broke huge parts of the system.