1. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory1 Requirements Change Management Section Six Version: 1.0 Mehr 1386

2. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory2 Why Do Requirements Change? We failed to ask the right people the right questions at the right time The problem being solved changed The users changed their minds or their perceptions The external environment changed We failed to create a process to help manage change Our understanding of the problem improved Why

3. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory3 Stable and volatile requirements Requirements changes occur while –the requirements are being elicited, analysed and validated and – after the system has gone into service Some requirements are usually more subject to change than others –Stable requirements are concerned with the essence of a system and its application domain. They change more slowly than volatile requirements. –Volatile requirements are specific to the instantiation of the system in a particular environment and for a particular customer. What

4. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory4 Types of volatile requirement Mutable requirements –These are requirements which change because of changes to the environment in which the system is operating Emergent requirements –These are requirements which cannot be completely defined when the system is specified but which emerge as the system is designed and implemented Consequential requirements –These are requirements which are based on assumptions about how the system will be used. When the system is put into use, some of these assumptions will be wrong. Compatibility requirements –These are requirements which depend on other equipment or processes. What

5. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory5 Requirements change factors Requirements errors, conflicts and inconsistencies –As requirements are analysed and implemented, errors and inconsistencies emerge and must be corrected. These may be discovered during requirements analysis and validation or later in the development process. Evolving customer/end-user knowledge of the system –As requirements are developed, customers and end-users develop a better understanding of what they really require from a system. Technical, schedule or cost problems –Problems may be encountered in implementing a requirement. It may be too expensive or take too long to implement certain requirements. What

6. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory6 Requirements change factors Changing customer priorities Customer priorities change during system development as a result of a changing business environment, the emergence of new competitors staff changes, etc. Environmental changes The environment in which the system is to be installed may change so that the system requirements have to change to maintain compatibility Organisational changes The organisation which intends to use the system may change its structure and processes resulting in new system requirements What

7. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory7 Managing Changing Requirements - Overview Problem Solution Space Problem Space Needs Features Software Requirements The Product To Be Built Test Procedures DesignUser Docs Traceability What

8. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory8 Change requests come from many sources throughout each iteration of the product lifecycle A Key to Managing Change All requests go through a single channel Maint Test Code Design Req Customer and End-User inputs Marketing New Feature New Requirement Bug Help Desk End-User inputs Approved Decision Process (CCB) Single Channel for Approval Coders inputs Testers inputs Change Request (CR) What

9. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory9 Configuration & Change Management Controls change to, and maintains the integrity of, a project’s artifacts'.

10. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory10 Configuration & Change Management Identifying configuration items (Requirements Artifact set, …), Restricting changes to those items (Requirements Artifact set, …), Auditing changes made to those items, Defining and managing configurations of those items.

11. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory11 Requirements Configuration Management Configuration management of requirements is important for the same reasons that configuration management of source code is important. Benefits of requirements management under CM –Prevent unauthorized change –Preserve revisions of requirements documents –Retrieve previous versions of documents –Allow a managed baseline release strategy –Prevent simultaneous update of documents What

12. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory12 Metrics for Requirements Management What types of questions to ask? –How many requirements do we have? –What percentage are in the baseline? –What critical requirements haven’t been implemented? –What resources are needed to put in this new feature? –What’s the estimated cost of the proposed changes? –How many changes since the last customer review? Who authorized the changes? What’s the impact on test ? What

13. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory13 Configuration & Change Management Workflow in RUP

14. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory14 Plan Project Configuration & Change Control Establishing project configuration management policies Establishing policies and processes for controlling product change Documenting this information in the Configuration Management Plan

15. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory15 Create Project Configuration Management (CM) Environments Making sure the essential artifacts are available to developers and integrators in the various private and public workspaces They are adequately baselined and stored for subsequent use.

16. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory16 Controlling Requests for Change Require all changes go through a single channel Have a documented process for handling change requests Contents of a change request: –What artifact or artifacts it concerns –Problem description –Suggested solution –Priority Should be submitted to a Change Control Board (CCB) or other review authority How

17. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory17 Manage Change Requests (1/2) Submit Change Request –requests for new features, enhancements, corrections, changed requirements,... –Any role may submit a change request as part of any activity throughout the project lifecycle. Review Change Request –To determine if the Change Request (CR) should be accepted or flagged for rejection.

18. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory18 Manage Change Requests (2/2) Confirm Duplicate or Rejected CR –A designated CCB administrator should be assigned to confirm a suspected duplicate or invalid change request.CCB Verify Changes in Build –Confirms that a Change Request has been completed, typically by conducting subset of tests on one or more builds.

19. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory19 A Sample Change Request (1/2) Identification Project: Change Request Number: Change Request Type: (Problem or Enhancement) Title: Date Submitted: Originator: Change Request Priority: Current Problem Description of the current problem: Critical Failure: Nuisance: Enhancement: New Requirement: Conditions under which the problem was observed: Current Environment: Hardware Operating System Compiler Source of the current problem: Cost or Savings Impact of the current problem: Proposed Change (Originator) Description of the proposed change: Estimated cost to implement the proposed change: Proposed Change (Change Review Team) Action: Approved:

20. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory20 A Sample Change Request (2/2) Disapproved: Deferred: Description of the proposed change: Affected Configuration Items: Category: Error Fix: Enhancement: New Feature: Other: Resolution Estimated cost to implement the proposed change: Implementer: Actual time to implement change: Analysis: Implementation: Test: Documentation: Affected Number of Lines of Code: Assessment Test Methods: Inspection Analysis Demonstration Test: Test Platforms: Test Cases: Change Review Team Disposition Changes Approved and Accepted:

21. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory21 Monitor & Report Configuration Status Ensuring that artifacts and their associated baselines are available. Determining if required artifacts are stored in a controlled library and baselined. Supporting project Configuration Status Accounting activities. Facilitating reporting of change request information, especially the activities related to work performed against defect and enhancement requests. Ensuring that data is "rolled-up" and reported for the purposes of tracking progress and trends.

22. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory22 Change and Deliver Configuration Items The creation of workspaces, accessing project artifacts, making changes to those artifacts, delivering the changes for inclusion in the overall product, by any role in the project team. The building of the product, creation of baselines and promotion of the baselines for availability to the rest of the development team.

23. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory23 Manage Baselines & Releases The frequency and formality in which baselines are created are described in the CM Plan. The degree of formality is clearly much higher for a product being released to a customer than for executable releases within the internal project team.

24. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory24 Requirements Management Architecture What

25. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory25 Business Needs drive Customer Needs which drive User Needs which demand Product Features that drive Software Requirements that we developers Implement and Test What Is Requirements Traceability? What

26. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory26 Why Use Requirements Traceability? Assure quality –Verify the implementation fulfills all requirements –Verify the application does only what was intended Help manage change –Understand the impact of a change –Find related requirements Why

27. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory27 Requirement Traceability Strategy Stakeholder Requests Design Model Supplementary Specification End-User Documentation Materials and Training Materials Use-Case Model Vision Test Model Features Software Requirements Needs What

28. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory28 1. Trace top-level requirements into detailed requirements 2. Trace requirements into design 3. Trace requirements into test procedures 4. Trace requirements into user documentation plan Design Software Design Descriptions Object Models Test Suites Test 2 3 Req A 1 Product Requirements (Features) Detailed Requirements (Use Cases) Req B Documentation Plan User Docs 4 Traceability Paths What

29. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory29 Link Feature to Use Case Verifies that all lower level (derived requirements) are consistent with stakeholder needs Vision Document FEAT10:The recycling machine will allow the addition of new bottle types. [UC4: Use Case “Add New Bottle Type”] New kinds of bottles can be added to the machine by starting it in ‘learning mode’ and inserting 5 samples … How

30. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory30 Link Feature to Subflow Within a Use Case Vision Document FEAT14:The recycling machine will sound an alarm if an invalid item is deposited. UC1: Use Case “Recycle Items” The user uses this machine to automatically … UC1.1 Basic Flow UC1.1.1 The use case starts when … … UC1.1.6 End of Use Case … Alternative Flows [UC1.2 Deposit Item Not Valid …] UC1.2.1 If at step UC1.1.2, the … UC1.2.2 The item will be … UC1.2.3 An alarm will sound … UC1.2.4 Return to step UC1.1.2 … UC1.3 Printer out of Paper … If at step UC1.1.4, the paper sensor … How

31. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory31 Link Feature to Section of a Use Case Vision Document FEAT24:The recycling machine shall recognize deposit items with 95% reliability. UC1: Use Case “Recycle Items” The user uses this machine to automatically … UC1.1 Basic Flow Alternative Flows UC1.2 Deposit Item Not Valid Special Requirements [UC1.17 Recycle items must be recognized with 95% reliability]... Use-Case Diagram How

32. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory32 Link Feature to Other Requirements Verifies that all lower level (derived requirements) are consistent with stakeholder needs Vision Document FEAT101:The system shall provide maximum passenger comfort at all times. Supplementary Specification SUPP201:The motor control servo algorithm shall provide smooth acceleration and deceleration profiles with no detectable jerks, overshoots or undershoots. Hardware Requirements Specification HR271:The motor control amplifier and servo subsystem shall provide sufficient capacity to accelerate and decelerate at a rate of 1G. HR272:The environmental control system shall maintain the temperature of the elevator cabin to within 2 degrees C at all times How

33. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory33 Link Requirements To Implementation Objects Verifies that implementation supports the real requirements Product Requirements Document FEAT101:The system shall provide maximum passenger comfort at all times. Supplementary Specification SUPP201:The motor control servo algorithm shall provide smooth acceleration and deceleration profiles with no detectable jerks, overshoots, or undershoots. Object Specifications Object001 Name: AccelerationServo Description: Algorithm to control acceleration and.... Methods: Servo Algorithm, Motor Feedback Attributes: Location, Velocity, Acceleration How

34. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory34 All Requirements Should Trace to Test! Left path - Verifies that all requirements have associated tests. Right path - Validates that all requirements have been met. Vision Document FEAT101:The system shall provide maximum passenger comfort at all times. Supplementary Specification SUPP201:The motor control servo algorithm shall provide smooth acceleration and deceleration profiles with no detectable jerks, overshoots, or undershoots. Elevator Test Specification ET301:The elevator shall be instrumented with the 2000 Test System and tested to assure that acceleration and deceleration profiles are monotonic and.... System Validation Protocol SVP501:Test for passenger comfort by....... How

35. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory35 Viewing Links - Traceability Matrix How

36. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory36 Viewing Links: Tree Report Tree reports show the full hierarchy of traceability links How

37. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory37 Sample Queries Show me all user needs that are not linked to product features Show me the status of tests on all use cases in Iteration #3 Show me all supplementary requirements linked to tests whose status is untested Show me the results of all tests that failed, in order of criticality Show me the features scheduled for this release, which user needs they satisfy, and their status What

38. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory38 Change Management User Documentation Specifications Design Specifications Test Specifications Use-Case Model Supplementary Specifications Features Software Requirements Vision Document Change Management What

39. Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory39 Links to requirements that have changed are marked as “suspect” Suspect links must be resolved by the user Req A before edit “if return value > $5” Req B Req C “if return value > $2” Req A after edit Req C Req B Impact Analysis by Traceability Links What