managing change 1. why do requirements change? external factors – those change agents over which...
TRANSCRIPT
![Page 1: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/1.jpg)
Managing Change
1
![Page 2: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/2.jpg)
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
![Page 3: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/3.jpg)
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
![Page 4: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/4.jpg)
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
![Page 5: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/5.jpg)
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
![Page 6: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/6.jpg)
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
![Page 7: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/7.jpg)
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
![Page 8: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/8.jpg)
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
![Page 9: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/9.jpg)
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
![Page 10: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/10.jpg)
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
![Page 11: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/11.jpg)
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
![Page 12: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/12.jpg)
Capturing Changes
Change RequestSystem
Firew
all
Vision
Requirementsand Use Cases
Design
Code
Tests
Inputs Customer and and user
Marketing
Developers
Testers
Others
12
![Page 13: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/13.jpg)
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
![Page 14: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/14.jpg)
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
![Page 15: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/15.jpg)
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
![Page 16: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/16.jpg)
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
![Page 17: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/17.jpg)
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
![Page 18: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/18.jpg)
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
![Page 19: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/19.jpg)
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
![Page 20: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/20.jpg)
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
![Page 21: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/21.jpg)
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
![Page 22: Managing Change 1. Why Do Requirements Change? External Factors – those change agents over which the project team has little or no control. Internal](https://reader035.vdocuments.us/reader035/viewer/2022062301/56649f1e5503460f94c365fe/html5/thumbnails/22.jpg)
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