Every engineering change starts with the same question: if we change this, what else moves with it? On a small system, experience answers it. On a complex system — where requirements, interfaces, software, tests and evidence are spread across teams and toolchains — that question is one of the hardest in engineering to answer well. This note is about why, and about a practice for answering it more reliably.
What change impact analysis is
Change impact analysis is the process of identifying what a proposed change may affect before you make it: which requirements the change touches, which components and interfaces are involved, which tests and verification activities would need to be repeated, and which assumptions, risks or pieces of evidence the change may invalidate.
The important word is before. Impact analysis done after the change is not impact analysis — it is failure investigation. The value of the practice is that the answer arrives while the change is still a proposal, when redirecting it is cheap.
Why it goes wrong
The links live in people’s heads. On many programmes, the real map of what connects to what is held informally by a few experienced engineers. It works until those engineers are unavailable, the system grows past what one person can hold, or the question arrives after they have moved on.
Evidence chains are documents, not graphs. Requirements live in one tool, design in another, code in a repository, test results in a third, and the argument that ties them together in documents nobody can query. Each boundary a relationship has to cross is a place it can silently break.
The cost arrives before the benefit. Recording impact properly takes time on the day of the change, while its value — fewer escaped regressions, faster reviews, defensible evidence — is realised later and somewhere else. Under schedule pressure, the practice is the first thing to be trimmed.
Change accumulates quietly. Each individual change looks harmless; the hundredth change has shifted the system far from what its original analysis described. Without a habit of re-examining impact, the recorded picture drifts from reality.
A bounded practice that fits real programmes
Change impact analysis does not need to be heavyweight. A practice that fits inside real programmes looks like this:
1. Record the change before making it. One page: what is changing, why, and the candidate list of things it may touch. Written down, so it can be wrong on paper instead of in the system.
2. Walk the chain. For the proposed change, step through the same chain every time: requirements, interfaces, implementation, tests and verification, assumptions and risks, evidence and approvals. The chain does the remembering so people do not have to.
3. Classify with reasons. Mark each item affected, possibly affected, or unaffected — with a one-line reason. The reasons are what make the analysis reviewable.
4. Close the loop afterwards. When verification finishes, compare what the impact analysis predicted against what actually needed attention. The difference is the most useful data a programme has about where its real coupling lives.
How software can help
Steps 2 and 3 are exactly where software should carry the load. This is the problem at the centre of our engineering-evidence research: connecting requirements, assumptions, implementation, tests and results so their relationships can be traced, reviewed and maintained — and investigating how a system could propose an impact set for human review, rather than leaving engineers to reconstruct it from memory each time.
Status: conceptual research and prototyping at Fallon Apus Orbital Systems. This is not a finished product.
If your programme is wrestling with change impact — or you would like to compare notes on how your organisation answers the question today — write to Paul at paulorbitalsystems@proton.me. And if you would like a short, serious briefing on this kind of problem each week, the newsletter below is where those notes go first.