Change Impact Analysis in Agile Development

Any change that will influence the system’s safety requirements after we have finished the safety analysis and safety planning for development of safety-critical software will require a change impact analysis. One of the reasons for using Scrum is its declarations to “embrace change”. Using agile development we may add new requirements, change existing requirements and make current requirements more detailed both in the product backlog and in the sprint backlogs. Problems, methods and necessary reports related to the consequences of such changes have been discussed and analysed in the SUSS (Agile Development of Safety Critical Software) project. We have come up with an extended Scrum model which includes the change impact analysis for all potential changes to the Scrum backlog. In addition, we have designed a change impact analysis process plus a template for a change impact analysis report. Before we entered the software development part of the project, which is Scrum’s domain, we have already performed a HazOp or FMEA and a risk analysis. Changes to the requirement or the introduction of new requirements may, however, invalidate these analyses. We may thus need to perform a change impact analysis for the whole system which again may force us to repeat all or part of the first safety analyses. One big challenge when performing a change impact analysis is to identify which parts of the system under development that is affected by a certain change. Manually this is rather costly process. One of the authors has developed a prototype tool that will help in the process. This tool was, however, not specifically built to be used in agile development and we will discuss how this prototype tool can work in or be adapted to an agile development process.