Information Technology Reference
In-Depth Information
A
B
C
A
B1
C1
Requirements change
Figure 4.3
Manage changes in requirements.
Other reasons why requirements change include:
Something was misunderstood by the user or the development
team in the original requirements.
Something in the original requirements was not thought through
or specified in detail.
Something was missing.
There was a communication problem. For example, the customer
assumed certain things about the delivery based on the agreed-
upon requirements. This often becomes an issue at the time of
user acceptance testing (UAT).
Recognizing Change
It is important to recognize a change as such. Costs are involved in
handling any modifications to software already developed. Who bears this
cost depends on the classification of the modifications requested. If it is
a change from the original specifications, then the customer has to bear
it under the rules of engagement as specified by the change control
processes. If it is a “bug,” then the developer may have to absorb the costs.
Any change agreed to becomes part of a new baseline, and can by
itself become an issue in future cycles of discussions.
Changes and Releases
There is a development lead-time involved between when the requirement
is identified and when it is implemented. For the same reason, what is
in production at any time reflects the requirements finalized earlier. This
lead-time is often determined not by the complexity of the change
involved, but by an external release schedule. New versions of the
application may be released only three times a year, or a major version
