Page 137 -

Any changes made to one function can ripple through the rest of the software, causing
many unforeseen problems. Even a minor change in the basic behavior of the software
usually requires that the programmers make extensive alterations to its design. As the
changes pile up, they become increasingly awkward because the programmer needs to
patch existing code without breaking it. Each additional design change requires another
layer of patching, and most of those patches require some compromise between imple-
menting new behavior and not breaking existing behavior. This is a messy and difficult
way to code, and tends to introduce many defects and delays after a few iterations.
Had someone written down a description of the behavior of the software before the pro-
grammers started building it, many of these iterations could have been avoided. It’s much
easier to change the behavior of the software on paper than it is to change the code. By
adopting a highly iterative software requirements engineering process, the project team
can identify most of the changes before a single line of code is written. They may still have
to make changes to the software, but those changes will be much smaller and therefore
much less risky.

Scope Creep
Many software projects have been driven to failure by poorly controlled changes. Typi-
cally, one of the project team members, users, stakeholders, or decision-makers sees a
change that he thinks ought to be implemented. The change seems “small,” so program-
mers begin altering the software to include it. But the change turns out to be difficult to
implement, and the entire project is thrown off track. This problem is usually referred to
as scope creep, because the scope of the project slowly drifts over the course of many incre-
mental changes.
Scope creep is so common that many project managers don’t realize that it’s a problem at
all. They feel that refusing any change request would be considered “inflexible” by others
in the organization, and that any project manager or team member who refuses to make a
change is not being a team player. But in a team that does not control changes, progress
on the project starts to slow as the changes pile up. At every status meeting, the team
reports that they are 90% done—but it seems that they have been 90% done for the last 3
months, and they don’t seem to be making any headway on that last 10%. Terms like

“quagmire” and “death march” get tossed around. The project plan is a joke, a product of
wishful thinking that was abandoned months ago. When projects finally do deliver, it feels
less like the team successfully met their goal than they finally crawled out from under a
suffocating mess.
In a project like that, the programmers usually understand the problem. They can point to
portions of the code that had to be rewritten several times in order to accommodate
changes. The team members know that had they been asked to do the correct project the
first time, they could have built it much more quickly and easily, but that it took many
changes to finally arrive at the product they have now. And nobody even wants to think
about maintenance—the code is a mess, because it had to be patched and hacked so many
times.

SOFTWARE REQUIREMENTS 129