Impact Analysis is a key aspect of responsible requirements management. It provides accurate understanding of the implications of a proposed change, which help the teams make informed business decisions about which proposals to approve. Change impact analysis (IA) is basically “identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change”, and they focus on IA in terms of scoping changes within the details of a design. It can also focus on the risks associated with changes so the evaluation of the many risks associated with the change, including estimates of the effects on resources, effort, and schedule can also be termed as Impact analysis. Both the design details and risks associated with modifications are critical to performing IA within change management processes.
The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change. Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise. In product development surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis.
Impact analysis has three aspects:
- Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels.
- Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
- Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.
Types of Impact Analysis Techniques
IA techniques can be classified into three types:
- Trace
- Dependency
- Experiential
In traceability IA, links between requirements, specifications, design elements, and tests are captured, and these relationships can be analysed to determine the scope of an initiating change. On complex projects with thousands of artifacts, to manually determine what and who is affected by a change is time consuming and error-prone. With Impact Analysis, automatically highlights the items and people that are impacted when a change occurs.
In dependency IA, linkages between parts, variables, logic, modules etc. are assessed to determine the consequences of an initiating change. Dependency IA occurs at a more detailed level than traceability IA.
Within software design, static and dynamic algorithms can be run on code to perform dependency IA. Static methods focus on the program structure, while dynamic algorithms gather information about program behaviour at run-time.
Literature and engineering practice also suggest a third type of IA, experiential IA, in that the impact of changes is often determined using expert design knowledge. Review meeting protocols, informal team discussions, and individual engineering judgement can all be used to determine the consequences of a modification.
Understanding the impact enables teams to quickly and accurately respond to change requests. The team can be responsive while maintaining control over scope and the customer expectations. Lastly, impact analysis is essential on projects where quality and safety is an issue such as in healthcare, automotive and aerospace projects. In these situations, it’s critical to understand the specific set of requirements and features that need to be retested after a change is implemented.
While effective and easily implemented, impact assessment is not a panacea and does not totally replace existing change procedures, instead, you should strive to improve your existing process. The procedure for performing an impact assessment consists of the following five steps:
- Define the extent of the change proposed – Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
- Determine key differences in the changed state (proposed) from a point of reference or the original state – Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
- Focus on the possible effects of the key differences from step #2 – Estimate the impact of the proposed change on the project’s schedule and cost.
- Sort and prioritize the possible effects (#3) from the key differences (#2) based on risk and possibility – Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
- Make a decision using the results – Report the impact analysis results to all stakeholders so that they can use the information to help them decide whether to approve or reject the change request.
In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand.
