Managing Change

1

Why Do Requirements Change?

External Factors – those change agents over which the project team has little or no control.

Internal Factors – those factors that while under project control still influence change.

2

External Factors

There was a change to the problem possibly due to the economy or in the marketplace.

The users changed their mind or the identity of the users themselves changed.

The external environment has changed, e.g., the hardware has changed.

The new system comes into existence. The very existence of a new system causes the requirements for the system itself to change.

3

Internal Factors

We failed to ask the right people the right questions at the right time during the requirements gathering effort.

We failed to create a practical process to help manage changes to the requirements.

Iterating from requirements to design begets new requirements.

4

Unofficial Sources of Change – “Requirements Leakage”

Enhancements mentioned by distributors who had been overheard by programmers at a sales convention

Direct customer requests to programmers Mistakes that had been made and shipped and had to be

supported Hardware features that didn’t get in or didn’t work Knee-jerk change-of-scope reactions to competitors Functionality inserted by programmers with “careful

consideration” of what’s good for the customer Programmers’ “Easter Eggs”

5

A Process for Managing Change

1. Recognize that change is inevitable, and plan for it.

2. Baseline the requirements.

3. Establish a single channel to control change.

4. Use a change control system to capture changes.

5. Manage change hierarchically.

6

Step 1: Recognize That Change is Inevitable and Plan for It The project team should develop a plan

for managing change that should include some allowance for change in the initial baseline.

All requests for change whether they come from the stakeholders or the developers should be considered legitimate.

7

Step 2: Baseline the Requirements In each iteration, the team should baseline the

requirements for the build, e.g., put version control on the pertinent artifacts and publish the baseline for the development team.

In this way the development team can distinguish between known, or “old” requirements and new ones.

A request for a new requirement can be compared against the existing baseline to see where it fits in and whether it conflicts with other requirements.

8

Step 3: Establish a Single Channel to Control Change Every proposed change should go through a

single channel to determine its impact on the system and to make the official decision as to whether to accept it.

This can be the project manager, the owner of the Vision Document, or a change control board (CCB).

A change should not be initiated until the change control mechanism makes the change “official”.

9

Step 4: Use a Change Control System to Capture Changes Many proposed changes may occur during the

design, coding, or testing of the system. These may be proposed corrections due to design or coding bugs.

Even so, the impact of these changes must be addressed. We may decide not to fix certain errors in requirements.

In any event, the team should implement a formal method for capturing all requested changes to the system.

10

Step 4: Use a Change Control System to Capture Changes (Cont’d)

This should be accomplished through a change request and defect tracking system that provides: a centralized repository of such requests Web-based entry of items automatic status tracking automatic notification of affected parties a mechanism for promotion of change

requests into the requirements management system when appropriate

11

Capturing Changes

Change RequestSystem

Firew

all

Vision

Requirementsand Use Cases

Design

Code

Tests

Inputs Customer and and user

Marketing

Developers

Testers

Others

12

The Change Control Board (CCB) Should consist of no more that three to

five people The members should represent the key

stakeholders for the project: Customers Marketing Program management

Has the responsibility to ensure that all those affected by the change are notified

13

Considerations When Deciding Whether to Make Changes The CCB must consider the following

factors: The impact of the change on the cost and

functionality of the system The impact of the change on customers

and other external stakeholders not well represented on the CCB; other project contractors, component suppliers, etc.

The potential for the change to destabilize the system

14

Change Request Flow

Change RequestSystem

Firew

all

Vision

Requirementsand Use Cases

Design

Code

Tests

Inputs Customer and and user

Marketing

Developers

Testers

OthersChange Control

Process

No Action

Fix test

Fix bug

Modify design

Newrequirement

Newfeature

Actionafter

approveddecision

15

Step 5: Manage Change Hierarchically A change to one requirement can have a ripple

effect in other related requirements, the design, or other subsystems.

A programmer should not be allowed to introduce new features and requirements directly into the code on the user’s behalf.

Every new feature/requirement has an impact on the cost, schedule, reliability, and risk associated with the project.

16

Step 5: Manage Change Hierarchically (Cont’d) In order to mitigate the ripple effect, changes to

the requirements should be carried out in a top-down hierarchical fashion, i.e., the Vision Document first, then the Use-Case Model and Supplementary Specifications, followed by the Design, Implementation, Tests, and User Documentation.

This process is aided by the traceability mechanism used to link the software artifacts which highlights the lower places in the hierarchy where additional analysis is needed.

17

Requirements Configuration Management The benefits of a requirements management

process based on configuration management is advantageous because it: Prevents unauthorized and potentially destructive

or frivolous changes to the requirements Preserves the revisions to requirements documents Facilitates the retrieval and/or reconstruction of

previous versions of documents Supports a managed, organized baseline “release

strategy” for incremental improvements or updates to a system

Prevents simultaneous update of documents or conflicting and uncoordinated updates to different documents at the same time

18

Questions Change Management Tools Help Answer

If a single product feature is proposed for a change, what are the work consequences of that change?

If an element is proposed for a change, what other elements of the system may be impacted by the change?

How can the requirements be “rolled back” if the project takes a wrong turn?

How and why was a given requirement changed?

19

Elements Impacted by Change

Whenever a change occurs, you should use the traceability information to find what other requirements are affected.

If the change to a feature does not impact a requirement, you need only consider the changed feature itself.

If it does impact a requirement, you may need to rework the affected element

20

Audit Trail of Change History

A change history allows you to view a chronological history of all prior changes to a given requirement.

A change management tool can capture the name of the change’s author as well as the date and time of the change.

Such a tool should also allow you to enter a change description to document the change. This will be a key element in any regulatory or project review of those changes that affect the claims, efficacy, and safety of the device and its software.

21

Configuration Management and Change Management A change history should exist at three levels

within your project.1. At the finest level of detail, the change history

records all changes to each individual use case or requirement within the project.

2. At a middle level of detail, you should automatically maintain a similar change history of each project document.

3. At the most general level of detail, you should automatically maintain a similar change history for the entire project.

22