Requirements Change Management - Requirements Engineering and Management for Software Development Projects - page 116

The formal mechanism used for handling change management is a CR (Change
Request). A suggested format for a CR is shown in Table 8.1 .
8.3 Origination of Changes
Changes can originate from various stakeholders including:
1. Customers—Customers' representatives raise change requests mainly to
change core functionality requirements. Occasionally they can also raise
requests to modify ancillary functionality when the system software proposed
by them has undergone changes. The changes stem mainly from changes in a
business scenario, or new/modified statutes, and reorganization of key depart-
ments etc. The world is dynamic and anything could change to effect the frozen
core functionality requirements and customers could raise change requests.
2. End users—End users raise change requests when a frozen requirement needs
to be changed because they either forgot a key aspect of a requirement or they
forgot a requirement totally. They may add a field or modify a field; they may
change the screen layout or report layout; they may need an additional report;
and modify the steps of a process and so on. Normally change requests raised
by end users would affect core functionality requirements.
3. Project team—Project team members can raise a change request occasionally
when they are not able to implement a requirement in its entirety or need a
design modification. They may not be able to pack all the controls on the same
screen or all the fields on the same report and this would cause them to raise a
change request. Sometimes, they may be able to combine multiple screens into
one screen layout. Normally project team's change requests are concerned with
implementing the design and issues thereof.
4. Testing team—It is rare that a testing team raises a change request as it is
focused more on uncovering defects than on finding opportunities for
improvement. But testing teams may find opportunities for improvement
(especially about system response times uncovered on performance testing,
system stress uncovered in stress testing or concurrency control aspects
uncovered in concurrent testing) while carrying out testing and may raise
change requests albeit in practical terms these changes often are initially
confused with problem reports. Testing teams do find some opportunities for
improvement and raise change requests to resolve those changes.
5. Organizational Standards group—Organizational Standards groups may
change an existing standard or bring out a new one, which may impact projects
in progress. In such cases they may raise a change request to retrofit the
standard into the project deliverables. Unless the change addresses a critical
issue, the Organizational Standards group generally identifies a migration path
for the change.