Page 128 -

Requirement functionality
Is every requirement correct?
Are all inputs and outputs clearly specified?
Requirement performance
Are all nonfunctional requirements that constrain performance (speed, resource utiliza-
tion, etc.) clearly and quantitatively defined?
Requirement testability
Is each requirement testable?

NOTE
More information on SRS development can be found in Managing Soft-
ware Requirements: A Use Case Approach by Dean Leffingwell and Don
Widrig (Addison Wesley, 2003) and Software Requirements by Karl
Wiegers (Microsoft Press, 2003).

Change Control

Throughout the course of most projects, many of the people involved come up with
changes to the planned software that could be implemented. Many poorly managed soft-
ware projects have been driven to failure because the designers, developers, and testers
had to repeatedly switch directions because of uncontrolled changes. Changes originate
from all over the project: a stakeholder may discover a new need that should be addressed,
a senior manager could change his mind about a feature, a programmer could figure out a
way to combine behaviors to make the software more efficient, a tester could discover
conflicting requirements, etc. Some of these changes will be worth doing, while others
should probably be scrapped. But every change will come with a sense of urgency, and the
project manager needs a way to sort through them to make sure that only the right
changes are made.
Change control is a method for implementing only those changes that are worth pursuing,
and for preventing unnecessary or overly costly changes from derailing the project.
Change control is essentially an agreement between the project team and the managers

that are responsible for decision-making on the project to evaluate the impact of a change
before implementing it. Many changes that initially sound like good ideas will get thrown
out once the true cost of the change is known. The potential benefit of the change is writ-
ten down, and the project manager works with the team to estimate the potential impact
that the change will have on the project. This gives the organization all of the information
necessary to do a real cost-benefit analysis. If the benefit of the change is worth the cost,
the project manager updates the plan to reflect the new estimates. Otherwise, the change
is thrown out and the team continues with the original plan.

Changes that seem “small” because they are easy to describe in words can have an unex-
pectedly large impact on the project. Even the most carefully planned and tracked project
can be thrown off course by unexpected changes. A project manager can use change con-
trol to keep this from happening.
120 CHAPTER SIX