Requirements Traceability & Change Impact Simulator

Change & Verification

Change churn rate 0.4

V&V rigor 0.6

Program status

Traceability coverage

100%

Open ECRs

Verification debt

Defects found

Review cycles

Requirements closed

6/6

How it works

Three layers model a spacecraft's configuration baseline: requirements (top) trace down through design / interface elements (middle, the ICDs) to the test cases (bottom) that verify them. Every edge is a traceability link.

Triggering an ECR (Engineering Change Request) on a requirement marks it changed and propagates impact along every downstream link — the interfaces it touches and every test that exercised them go stale, exactly like a real change-impact analysis. That is why a single requirement edit can silently invalidate several already-passed tests.

Running a verification pass re-tests every stale item. Pass probability scales with the V&V rigor slider — high rigor (thorough review, more test coverage) both re-verifies more reliably and is more likely to actually catch a latent defect instead of rubber-stamping it. A requirement only closes once every design element and test underneath it is green again.

Traceability coverage = share of requirements whose full chain is currently verified. Verification debt = stale test cases still waiting on a re-test. Autoplay fires new ECRs at a rate set by the churn slider, mimicking a program running through its review cycle while change traffic keeps arriving.

Real-world relevance: this loop — requirement → ICD → V&V, broken and re-closed by every ECR/ECO — is exactly what configuration management and requirements-traceability tooling track on a real space mission, from CubeSat to flagship.

Verified / traced Changed (ECR source) Impacted / stale

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.