Engineering Delivery
Model your system as elements with dependencies, describe a change or design decision to one of them, and trace the ripple through the dependency graph. Scores the impact, lists every affected element by ripple level, and prompts the change considerations to review.
Free to use, no sign-up needed.
Overview
Every design decision on a real system carries a ripple. Replace a core switch, re-IP a management VLAN, relocate an antenna, decommission a power feed — the change rarely stays where you made it. The hard part is not the change itself; it is knowing everything it touches before you commit to it. On a complex communications or RF system, the dependencies live in people’s heads and across a dozen drawings, and the second- and third-order effects are exactly the ones that get missed.
The noIM₃ Change Impact Analyser makes that ripple explicit. You model the system you are working on as a set of elements — radios, switches, power feeds, structures, configurations, interfaces, documents — and record, for each one, the other elements it depends on. Then you describe the change: which element, what kind of change, how big, and which way to follow the ripple. The tool traces the dependency graph and shows you what the change actually reaches: the directly affected elements, the indirect ripple level by level, a scored impact index with a Low / Medium / High / Critical band, the interfaces and high-criticality elements in the path, and a checklist of change considerations to review.
It is a structured analysis over the dependencies you enter, not a black box. Every figure traces back to an input, the risk weights are visible and editable, and the impact score composition is shown in full. This first release is deliberately generic — a domain-agnostic framework for thinking through a change — and is built to grow more specific over time. It is a planning and review aid for a design decision, not a measurement or a predictive simulation.
Build the system as a list of elements — each with a type (RF, network, power, physical, software, interface, documentation) and a criticality — and record the elements each one depends on. The model is free-form and domain-agnostic, so it suits a single rack, a radio site, a backhaul network or a whole programme equally well.
A change to an element ripples to everything that depends on it, directly and then onward. The analyser walks the dependency graph breadth-first and tags every affected element with its ripple level — direct, second order, third order — so the downstream effects that are easy to miss are laid out explicitly instead of being left to memory.
Follow the ripple downstream to the dependents (what is affected if the element changes — the usual question), upstream to the prerequisites (what the element relies on), or in both directions for the full neighbourhood around the change.
The impact index combines the changed element’s own criticality, each affected element’s criticality reduced by a per-level decay, and multipliers for the change type and scope. It maps to a Low / Medium / High / Critical band on editable thresholds, and the full score composition is shown so every part of the number is traceable.
The interfaces and the high- or critical-criticality elements caught in the ripple are pulled out separately — these are the boundaries that need re-testing and the elements that warrant a formal change review, so they don’t get buried in the list.
Each analysis ends with a set of change-hygiene prompts derived from the result — removal with dependents, compatibility on a replace or upgrade, re-testing affected interfaces, updating the documentation. They are generic prompts to confirm against your own change process, framed as considerations, never as findings.
The criticality weights, change-type risk factors, scope multipliers, propagation decay and band thresholds are all exposed and editable. Tune the model to your own risk appetite, or leave the defaults — either way nothing is hidden behind the score.
Weighing two options — modify in place versus replace, or changing one element versus another? Turn on Compare to assess a second change against the same model, direction and weights, with an A-versus-B table and a delta on every metric so the lower-impact path is obvious.
Model a change that touches several elements at once and the ripple traces from all of them together. See the whole system as a layered dependency graph with the change set and its ripple colour-coded by level, and the impacted rows highlighted in the model grid, so the spread is visible at a glance.
The project auto-saves to your browser and round-trips to a JSON file you can keep or move between machines. Export the impacted-element list to CSV, copy the full assessment to the clipboard, or print a formatted Change Impact Assessment to PDF for a change record, an MoC form, or a design note.
Inputs and outputs
Inputs 8
Outputs 12
Use cases
It traces the dependencies you enter. You record, for each element, the other elements it depends on; a change to an element then ripples to everything that depends on it, directly and onward through the graph. The analyser walks that graph and tags each affected element with its ripple level. The impact index is built from the changed element’s criticality, each affected element’s criticality reduced by a per-level decay, and multipliers for the change type and scope — all of which are visible and editable. It invents no relationships of its own.
It is a transparent, configurable index, not a physical measurement. The propagation is a deterministic trace of the dependencies you define, and the weighting is a small model whose every factor is shown and editable. It is a structured way to rank and reason about a change, not a simulation of how the system will behave. The full score composition is displayed so you can see exactly how the number is built.
Downstream follows the dependents — the elements that would be affected if the changed element changes, which is the usual change-impact question. Upstream follows the prerequisites — the elements the changed element relies on. Both directions give the full neighbourhood around the change. You choose the direction and how many ripple levels to follow.
No. The model is deliberately generic — elements, types and dependencies — so it suits any system a systems integrator or technician works on. The defaults and the worked example are drawn from a radio site, but nothing in the model is RF-specific. This first release is a domain-agnostic framework intended to grow more specific over time.
No. The considerations are generic engineering-change hygiene prompts derived from the result — things like confirming alternatives when removing an element with dependents, checking compatibility on a replace or upgrade, re-testing affected interfaces, and updating the documentation. They are prompts to review against your own change-management process, not assertions about your specific system.
