What is Impact Analysis?

Impact analysis uses trace links to determine which artifacts — requirements, architecture, code, tests, evidence — are affected by a change. It makes the costs and risks of a change assessable before the change is implemented. Together with coverage analysis, it is one of the two core evaluations of requirements traceability.

How does an impact analysis work?

Maintained trace links turn the project data into a graph: artifacts are the nodes, semantic relationships such as “is verified by” or “is fulfilled by” the edges. Impact analysis follows these edges — directly or via chains of links, in both directions — and answers questions such as:

Which parts of the system are affected by this change request?
A test fails — which requirements are not fulfilled correctly?
A requirement changes — which architectural elements, software components, test cases and safety evidence need to be re-evaluated?

Typical triggers

In regulated development projects, it is not only the classic change request that triggers an impact analysis:

Changed requirements: the most frequent cause — every requirement change raises the question of what has to be changed along with it and what has to be retested.
Re-rated hazards: if a hazardous event is re-rated in the HARA, trace links immediately show which safety requirements, analyses and test cases are affected — and which remain untouched.
New vulnerabilities: a new CVE in an integrated component demands an answer as to which attack paths, security controls and verification evidence need to be re-evaluated.
Architecture changes: if an architectural element changes, the change propagates into dependent analyses such as FMEA and FTA.

Impact analysis vs. coverage analysis

Impact analysis evaluates what is linked: it follows existing links and finds what is affected. Coverage analysis evaluates what is not linked: missing links are indicators of open work — a requirement without a test case has probably not been tested. Both analyses need the same data foundation, but answer different questions: one steers changes, the other measures progress and completeness.

Why impact analyses do not scale without traceability

Anyone who does not maintain the cross-references between artifacts as digital trace links has to laboriously reconstruct them by hand for every change — across requirements tool, modelling environment, repository and test management. With short development cycles, this does not scale: an impact analysis that costs weeks of manual work does not fit into any sprint. The benefit of the links is measurable: in an empirical study with 71 participants, developers completed maintenance tasks 24 % faster on average with traceability and delivered 50 % more correct solutions.

Impact analysis in practice: from research to query

For the impact analysis to become an answerable question rather than a re-evaluation on suspicion, three prerequisites are needed: uniquely identifiable artifacts, maintained links across tool boundaries and a Traceability Information Model that defines the relationship types. Once they are in place, an end-to-end traceability layer shows on demand, for a requirement change, which software components, test cases, safety evidence and security controls are affected — in our experience the biggest lever for reducing change costs in regulated projects.

Frequently asked questions

What is the difference between impact analysis and coverage analysis?

Both evaluate trace links, but in opposite directions: impact analysis follows existing links and answers which artifacts are affected by a change. Coverage analysis looks for missing links and answers which requirements have not yet been implemented or tested.

What prerequisites does an impact analysis need?

Three things: uniquely identifiable artifacts, maintained trace links between them — including across tool boundaries — and a Traceability Information Model (TIM) that defines which relationship types exist. If one of these is missing, the impact of every change has to be reconstructed by hand.

Do standards require an impact analysis?

Yes, in one form or another: ISO 26262 requires an analysis of the impact of every change on safety requirements and evidence as part of change management. Process models such as Automotive SPICE presuppose bidirectional traceability as a base practice — exactly the data foundation on which impact analyses run.

Impact Analysis