Requirements Engineering: Managing Requirements Change

1. Requirements Engineering: Managing Requirements Change UFCE4S-10-3 Lecture Five Stewart Green

2. Lecture Structure • Motivation for requirements change management (RCM) • What is involved in RCM? • Identifying and storing requirements • Change management • Traceability Requirements Engineering UFCE4S-10-3 Lecture Five

3. References • Requirements Engineering, G. Kotonya and I. Sommerville, John Wiley,1998, Chapter 5 • Revisiting Requirements Production, O.Gotel and A. Finkelstein, Software Engineering Journal, May 1995 (a paper related to traceability, a key component of the infrastructure supporting requirements change management) Requirements Engineering UFCE4S-10-3 Lecture Five

4. Motivation • During the life-time of a software development project, the requirements may change frequently • Changes need to be managed as efficiently and effectively as possible Requirements Engineering UFCE4S-10-3 Lecture Five

5. Why do requirements change? • Take five minutes to write down reasons why requirements may change during the lifetime of a software project. You may discuss this with your neighbours. Requirements Engineering UFCE4S-10-3 Lecture Five

6. Reasons for Changing Requirements • Record here the reasons we capture on the whiteboard • I have put my list on UWEOnline; it will appear after the lecture Requirements Engineering UFCE4S-10-3 Lecture Five

7. Impact of Poor RCM • Poor requirements change management may lead to: • Systems that don’t meet a customer’s needs • Extended development schedules • High costs for rework • So there is a need to manage changing requirements so that their quality is maintained. • Managing requirements change must be performed in parallel with other requirements engineering activities Requirements Engineering UFCE4S-10-3 Lecture Five

8. Requirements Change Management • Requirements change management involves: • Managing agreed changes to requirements • Managing relationships between requirements • Managing dependencies between requirements (documents) and other development artefacts (design, code, tests, etc.) Requirements Engineering UFCE4S-10-3 Lecture Five

9. Implications of the RCM • Point one on the previous slide implies that the impact of change must be understood, and that changes are made in a timely and cost-effective way • Points two and three imply that traceability information needs to be supported. • Traceability information includes answers to the following questions: • Who suggested this requirement (backward traceability)? • Why is this requirement needed (rationale)? • What other requirements are related to this requirement (dependencies)? • What design components, code components or user documentation components are related to his requirement (forward traceability) Requirements Engineering UFCE4S-10-3 Lecture Five

10. Identifying and Storing Requirements in an Online File • An essential pre-requisite for RCM is that all requirements are associated with a unique identifier • In many projects a requirements document that contains the requirements is created and maintained in one or more online files. Requirements Engineering UFCE4S-10-3 Lecture Five

11. Advantages of Online Files • All the requirements are located in one place • The requirements are easy to access • It is easy to produce a new version of the requirements document Requirements Engineering UFCE4S-10-3 Lecture Five

12. Disadvantages of Online Files • Traceability information has to be maintained externally • Facilities for searching and querying requirements are limited to available word-processing facilities, e.g. “find” in Word. This means it may be time-consuming to find a group of related requirements • It is not possible to directly access (dependent) requirements linked to a requirement for which a change has been proposed • Version control is at document or chapter level, rather than requirement level • It is not possible to navigate automatically between related requirements. Requirements Engineering UFCE4S-10-3 Lecture Five

13. Storing Requirements in a Database • Each requirement is represented as an entity or object • Built-in database facilities can be used to link related requirements • Built-in database facilities can be used to support searches and queries • Built-in database facilities can be used to support version control at the requirement level • Built-in database facilities also support: • Browsing • Report generation • Requirement s document generation Requirements Engineering UFCE4S-10-3 Lecture Five

14. Object-Oriented Database Requirements Engineering UFCE4S-10-3 Lecture Five

15. Change Management Process Requirements Engineering UFCE4S-10-3 Lecture Five

16. Change Analysis and Costing 1 Requirements Engineering UFCE4S-10-3 Lecture Five

17. Change Analysis and Costing 2 • According to Sommerville there are six basic activities in the change analysis process • Ensure the change is necessary • Discover impacted requirements • Find dependent requirements using traceability information • Validate proposed changes with customer • Estimates cost of change in time and money • Validate costs with customer and, if necessary, renegotiate changes Requirements Engineering UFCE4S-10-3 Lecture Five

18. Traceability 1 Requirements Engineering UFCE4S-10-3 Lecture Five

19. Traceability 2 (after Sommerville) Requirements Engineering UFCE4S-10-3 Lecture Five

20. Traceability Mechanisms Requirements Engineering UFCE4S-10-3 Lecture Five