Page 131 -

• During the testing phase, the testers may discover omissions in the SRS or design that
cause defects. For example, an enhancement to a software project may require that a
new record type is to be added to one feature, but the requirements and design fail to
specify how that record type is handled in another related feature. The programmers
never implemented any handling for this new record type in the second feature because
the design failed to indicate how that was to be handled.
• The users or stakeholders may discover during a design walkthrough, demo, user accep-
tance testing, or beta testing that the software does not fulfill their needs.

During the CCB meeting, the project manager explains the change to the rest of the CCB.
Once the CCB is brought up to speed, it must determine what project work products will
have to be changed. Each change will affect at least one work product that has already
been approved—if this were not the case, the CCB would not have to meet because the
change could be handled as part of the regular review process.
The CCB must evaluate every change that is requested. This ensures that nothing slips
through the cracks, and that a real decision is made for each request. However, this could
mean that at some very busy points in the project, the CCB must meet periodically—
sometimes weekly or even daily. At each meeting, it may discuss many changes that have
been submitted since the previous meeting.

It is important that when the CCB is being organized, the project manager makes sure that
each member understands that this sort of time commitment may be necessary. These
meetings are an important way for all of the CCB members to stay on top of the issues that
come up during development. This knowledge is very valuable later on in the project
when it is time to determine whether the software is ready for release (see Chapter 8).
Analyze the Impact of Each Change
It is vital that the project manager understand and manage all of the information produced
in the change control process. While all of the project team members’ opinions are necessary
in evaluating the change, it is the project manager who owns the change, and who makes
sure that it is properly understood and evaluated. This is generally a lot of work: the project
manager needs to take the time to understand why each change is needed, what needs to be

changed, and how much work it will be to make the change. His understanding must be
complete enough that he can present this information at the CCB meeting.
The project manager who is responsible for guiding each change through the change con-
trol process. This is why it is important that the project manager be the one who updates
the issue report to reflect both the effort that was estimated in the evaluation and the final
decision of the CCB. And it is the project manager who is responsible for making sure that
each CCB member is given enough information to understand the change.

During the change control process, the project manager works with the team to evaluate
the impact. One effective way to do this is to use the Wideband Delphi estimation process
(see Chapter 3). If this is done, the project manager can append the results of the Delphi
meeting to the issue report and present them to the CCB for cost-benefit analysis. But

SOFTWARE REQUIREMENTS 123