Impact analysis

Impact analysis answers the question you should ask before any significant change: what does this touch? By following the thread out from an item, it shows everything a change would affect — so you plan the work with the full picture rather than discovering the consequences afterward.

Following the thread

An item rarely stands alone. A requirement is realized by architecture, verified by tests, and constrained by risks; each of those connects to more. Impact analysis traverses those links to assemble the set of affected items — not just the immediate neighbors, but the things connected to them too.

Direct and indirect

The analysis distinguishes direct impact — the items linked straight to what you’re changing — from indirect impact, the items reached further along the thread. It can follow the connections to a chosen depth, so you can look one hop out for a quick check or trace the full ripple of a change across the program.

Upstream and downstream

Impact runs both ways. Looking downstream shows what depends on the item you’re changing — the tests, controls, and releases that would need attention. Looking upstream shows what it depends on — the needs and decisions that drove it. Together they frame a change completely: what it might break, and what it was meant to satisfy.

Planning a change

The point of impact analysis is to do it before the change. The set of affected items is your re-verification plan: the tests to re-run, the risks to re-assess, the reviews to re-open. Estimating that scope up front is the difference between a controlled change and a surprise — and it’s exactly the evidence a change-control process expects.

After the change

Once a change is made, the same connections drive suspect links, which flag the affected items for the re-verification impact analysis predicted. Analysis plans the change; suspect links make sure the follow-through actually happens. Impact analysis is also available as a report for capturing the assessment formally — see Reports.