1. Managing Change 1

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. Capturing Changes Change Request System Firewall Vision Requirements and Use Cases Design Code Tests Inputs Customer and and user Marketing Developers Testers Others 12

13. 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

14. 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

15. Change Request Flow Change Request System Firewall Vision Requirements and Use Cases Design Code Tests Inputs Customer and and user Marketing Developers Testers Others Change Control Process No Action Fix test Fix bug Modify design New requirement New feature Action after approved decision 15

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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