Commandment Three

3: Don't Allow Unwarranted Requirements Changes

While user requirements often change, it's the job of the development organization to manage these changes in a controlled fashion and assure that requirements don't 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 soon had the task of developing a 65-function scientific calculator. Modifying or adding new requirements can happen for many reasons, not the least of which is the failure to honor commandments 1 and 2.

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. But if the calculator is 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 the user. At 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 re-qualifying that may result.

This doesn't mean that we oppose iterative development. In Chapter 10 of Software Development, 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 new iteration, not continually during the development process. Requirements changes affect project budget and schedules. Allowing changes only at set points in the software lifecycle 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 requirements changes. Still, requirements changes are a constant problem for many software projects. 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 users to review the completed requirements document and agree to its completeness.
• Get users to agree up front that future requirements changes will be accepted only after being evaluated for schedule and budget impact.
• 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.