An engineering change impact assessment is the structured record of what a proposed change affects, who has assessed each consequence, what must be updated or repeated, and who can approve the resulting baseline. For a spacecraft programme, the assessment should connect the proposed diff to requirements, interfaces, architecture, configurations, verification activities, evidence, owners, risks and closure conditions before the baseline moves.
This guide includes an on-page change impact assessment template and a worked payload-to-spacecraft data-interface change. It is a reusable engineering structure, not a claim that one form satisfies every organisation or contract. Tailor the review authority, evidence and assurance depth to the programme, applicable standards and consequence of the change.
What is requirements change impact analysis?
Requirements change impact analysis asks a simple question with a difficult answer: if this requirement changes, what else might need to change, be reviewed or be reverified? It is part of engineering change control, but it happens before the approval decision so the change authority can see the likely consequence.
NASA's software engineering guidance on managing requirements changes calls for documenting requests and analysing their effect on the project. The principle applies across hardware and systems engineering: a controlled change needs more than revised wording. It needs an assessment of the technical and programme context that depends on the old baseline.
Impact analysis is not a promise that every consequence can be predicted. It is a repeatable way to expose known dependencies, uncertainty and missing information before the team commits. The analysis should be revisited when tests, supplier responses or detailed design reveal new effects.
Why is the full blast radius hard to see?
Engineering information is usually distributed by discipline and tool. Requirements may be in a database, interfaces in documents, budgets in spreadsheets, design parameters in models, work in Jira and evidence in test folders. Each local owner can understand their piece while no one sees the complete dependency path.
The number of relationships also grows faster than a simple requirement list suggests. A subsystem requirement can derive from several parents, constrain several interfaces, apply to multiple configurations and be verified by a combination of test and analysis. A proposed edit therefore has first-order, second-order and sometimes organisational consequences.
“Of course a change to one subsystem has knock-on implications for the rest…”
The durable answer is not simply to send more messages. It is to preserve dependency classes and authority so the right people can review a proposal against shared, configuration-correct context.
Which dependency classes belong in the dossier?
| Dependency class | Questions to answer |
|---|---|
| Intent lineage | Do source needs, parent requirements, derived constraints or allocations need to change? |
| Boundary dependencies | Does either side of a physical, power, data, thermal or operational interface change? |
| Solution dependencies | Which functions, components, parameters, budgets or design assumptions use the old value? |
| Configuration dependencies | Which variants, models, serial articles, software loads or baselines are affected? |
| Assurance dependencies | Are hazards, methods, cases, procedures, results or accepted evidence still valid? |
| Delivery dependencies | Which owners, suppliers, reviews, cost items, schedules or contracts need action? |
How do you perform requirements change impact analysis?
- Define the proposed diff. Record the old value, proposed value, reason, source, affected baseline and requesting owner.
- Confirm the requirement's context. Check parents, rationale, allocation, interfaces, applicability and current verification state.
- Traverse direct relationships. Identify immediately connected requirements, systems, parameters, risks, tests and evidence.
- Follow meaningful downstream paths. Continue through relationship types that can carry technical consequence, not every link in the repository.
- Ask owners for domain assessment. The graph finds candidates; responsible engineers explain the real effect, options and uncertainty.
- Classify consequence and required action. Mark items for information, review, update, reanalysis, reverification or formal approval.
- Decide and record. Approve, reject, defer or revise the proposal with rationale and required follow-up work.
- Verify closure. Confirm that approved updates, tests and evidence are complete for the affected configuration.
The sequence matters. Teams often jump from a change request straight to a meeting. That can produce a decision, but the meeting begins before the affected record is assembled. A structured first pass makes the discussion shorter and leaves an auditable explanation afterwards.
Run a pre-approval dependency sweep
Before approval, record each material dependency class as affected, reviewed with no impact, or unknown. NASA's requirements-management guidance says requirement changes should be assessed before approval across cost, schedule, architecture, design, interfaces, ConOps and higher- and lower-level requirements. The table below turns that principle into a reviewable sweep; it is Arc's suggested working format, not a prescribed NASA form.
| Sweep result | Meaning | Required record before approval |
|---|---|---|
| Affected | A credible path connects the proposal to a technical or programme consequence | Named owner, consequence, disposition, due date and closure evidence |
| Reviewed—no impact | The dependency class was examined and the current item remains valid | Reviewer, rationale, configuration checked and review date |
| Unknown | Context is missing, contradictory, stale or owned outside the available record | Visible warning, information owner and escalation or decision condition |
| Not applicable | The class does not apply to the stated scope | Short rationale and approving reviewer |
A blank result is not “no impact”. Treat missing source revisions, unowned interfaces, absent configuration data and inaccessible supplier evidence as explicit warnings. Automation may assemble candidates, but the responsible human supplies the disposition and the authorised change body owns the decision.
A worked spacecraft-interface change
This scenario is fictional. The spacecraft, identifiers, values, analyses and results are illustrative rather than evidence from a real mission. Assume a 12U Earth-observation spacecraft has a baselined payload-to-onboard-computer interface of 800 Mbit/s. A late payload update proposes 1.1 Gbit/s to preserve a higher-resolution imaging mode. The originating change request is not simply “increase the data rate”. It records the old and proposed values, the imaging scenario that drives the proposal, affected flight-model configuration, required decision date and payload owner.
The first direct impact is the electrical and data interface between the payload and onboard computer. The interface control record, payload output requirement and onboard-computer input requirement all use the old value. The architecture then carries the consequence into processing capacity, storage throughput, bus utilisation, power and thermal budgets. Mission operations, downlink planning and ground processing may be affected even though they are not adjacent to the changed sentence.
| Assessment area | Example finding | Owner | Required disposition before approval |
|---|---|---|---|
| Requirements | PAY-DATA-014 and OBC-IF-022 contain 800 Mbit/s; the daily data-volume requirement assumes the previous imaging mode | Payload and avionics leads | Revise, reject or constrain the proposal; preserve parent rationale and bidirectional traceability |
| Interface definition | Link protocol supports the rate, but connector pin allocation and clock-tolerance assumptions need confirmation | Interface owner | Update the interface control record and obtain approval from both sides of the boundary |
| Architecture and budgets | Peak OBC load rises, recorder write margin falls and an extra 8 W is predicted during image transfer | Avionics, power and thermal owners | Update performance, power and thermal models; identify any limit or operating restriction |
| Verification activity | Existing throughput case stops at 850 Mbit/s and does not reproduce the new burst profile | Verification lead | Revise stimulus, duration, acceptance criteria and test configuration; review facility capability |
| Existing evidence | Interface analysis A-017 and thermal analysis T-042 were accepted against the old profile | Analysis owners | Mark evidence as superseded for the affected configuration and rerun the applicable cases |
| Operations | Higher collection volume exceeds the current daily downlink plan on two target scenarios | Mission operations lead | Choose compression, contact-time or collection constraints and update the concept of operations |
| Risk and programme | Late OBC qualification rerun threatens the environmental-test slot | Chief engineer and programme manager | Record schedule exposure, mitigation and residual risk accepted by the change authority |
The team might approve the complete 1.1 Gbit/s change, approve it only for a bounded operating mode, change the compression design, or reject the proposal. The dossier does not choose automatically. It makes the trade reviewable and prevents an approval from silently carrying obsolete tests and analyses into the new configuration.
What closes the worked change?
Approval is a decision to proceed, not evidence that the work is finished. This example closes only when the affected requirement and interface revisions are merged, budget models are updated, the revised throughput test passes on the applicable hardware and software configuration, superseded analyses are replaced, operations constraints are baselined and every approval condition is signed off. The final record links those closure items to the original change request.
Direct, downstream and systemic impact
A direct impact affects an immediately connected item. If the data-rate requirement is allocated to the onboard computer, that allocation is direct. A downstream impact appears through one or more intermediate relationships, such as a thermal test affected because higher processing power increases dissipation.
A systemic impact changes how the programme operates rather than one product item. The proposal may require a new supplier exchange, a certification discussion, a review milestone or a change to common architecture used by several missions. These impacts are easy to miss because they live outside the requirement tree.
The categories help organise review, but path length is not the same as severity. A distant safety consequence can matter more than a direct documentation edit. The assessment needs both structural reach and engineering judgement.
An on-page engineering change impact assessment template
Use the following structure as a review record in the team's controlled system. A small, low-consequence correction may need only brief entries. A change that affects safety, qualification, a customer interface or several configurations needs the full owner and evidence trail.
| Section | Record | Completion test |
|---|---|---|
| Change definition | Change ID, old state, proposed state, reason, source, requester and decision date | A reviewer can understand the exact diff without opening two uncontrolled exports |
| Scope and applicability | Baselines, products, variants, serial articles, software loads, lifecycle states and excluded configurations | Included and excluded configurations are explicit |
| Paths examined | Parents, children, interfaces, functions, components, parameters, budgets, risks, tests, evidence and supplier commitments | The assessor records both discovered impacts and relevant classes checked with no impact |
| Item assessment | Affected item ID, relationship to the change, consequence, severity, uncertainty, action and rationale | Every claimed impact can be traced to an item or documented engineering inference |
| Owner response | Named technical owner, assessment date, recommendation, effort, schedule and unresolved question | No material impact is treated as accepted merely because a cell is blank |
| Verification and evidence | Method, level, procedure, article/configuration, acceptance criteria, existing evidence validity and planned reverification | Evidence is retained, superseded or repeated deliberately for the changed configuration |
| Decision | Approve, reject, defer or revise; decision authority; rationale; conditions; residual risk and effective baseline | The person making the decision and the limits of that authority are visible |
| Closure | Follow-up actions, owners, due dates, merged revisions, new evidence and closure approval | Every approval condition has objective completion evidence |
This template is intentionally on the page rather than hidden in a downloadable file. Teams can reproduce the fields in their existing change-control workflow, requirements platform or issue system while keeping the assessment connected to the authoritative engineering objects.
Review the change dossier before approval
A practical prioritisation considers consequence, likelihood, uncertainty, reversibility and time sensitivity. Teams can use a simple rubric instead of inventing false numerical precision.
| Priority | Typical condition | Expected response |
|---|---|---|
| Critical | Potential safety, mission, regulatory or contractual consequence | Formal cross-functional review before approval |
| High | Material interface, architecture, supplier or qualification effect | Named owners, analysis and planned closure |
| Moderate | Contained redesign, test update or evidence refresh | Owner review and tracked follow-up |
| Low | Editorial or administrative update with no technical effect | Lightweight review with recorded rationale |
| Unknown | Insufficient context to assess consequence | Do not approve until uncertainty has an owner |
A complete dossier should let the change authority answer five questions without reconstructing the analysis: what changed and why; which configurations are in scope; which dependency paths were examined; what each owner recommends; and which work or evidence must close after approval. Unknowns remain explicit entries with owners, not blank cells interpreted as “no impact”.
Why traceability is necessary but not sufficient
Traceability provides the paths that impact analysis follows. A requirement linked to its source, children, satisfying elements and verification cases gives the team a strong starting point. A requirements traceability matrix can expose many of these connections.
Links alone do not explain consequence. A verifies link says that a test supports a requirement, but an engineer must decide whether the proposed wording invalidates the test method or only changes a report label. Relationship types, applicability and rationale make the graph more useful, while domain owners supply the final judgement.
Can spreadsheets manage change impact?
They can when the requirement set is contained, relationships are simple and one team owns the update. A disciplined workbook can record a change request, affected rows, owners and status. The problem appears when links span multiple files, configurations and organisations. Copying identifiers between tabs does not guarantee that every affected item is current.
Dedicated software should not merely draw a larger graph. It should let the team compare a proposal with the baseline, filter relationship paths, collect owner assessments, preserve comments and connect approved follow-up work to closure. The workflow matters more than a dramatic visualisation.
How can AI support impact analysis safely?
An AI agent can walk known links, retrieve relevant context, group candidate impacts and explain why each item was included. It can also search semantically for probable missing relationships, such as a test procedure that mentions the changed parameter but is not formally connected.
The result should distinguish graph-derived facts from model inference. Engineers need to confirm candidate impacts and decide the response. The safest design creates a proposed assessment in a branch or review package instead of directly changing downstream records.
How Arc handles requirement changes
Arc's controlled engineering-change workflow lets engineers propose work in branches, compare the diff and inspect affected requirements, interfaces, systems and verification items before merging. Arc's documented traceability and impact views provide the paths; within Arc's documented AI-governance boundary, configurable agents can help assemble a first-pass blast radius and flag likely gaps after the workflow has been configured and evaluated for the programme.
Reviewers can discuss the actual proposal in context, assign follow-up work and preserve the approval rationale. The baseline only moves when the team merges the accepted change. That keeps fast collaboration compatible with controlled engineering history.
Related reading
Use the requirements traceability and verification matrix guide to structure the paths and evidence this assessment follows, and preserve the approval rationale with the engineering decision record template. Then distinguish the records and closure stages in ECR vs ECO vs ECN and confirm evidence applicability with as-designed, as-built and as-tested configuration management.
Frequently asked questions
What is requirements change impact analysis?
Requirements change impact analysis is the structured assessment of how a proposed requirement change affects connected requirements, interfaces, design elements, configurations, verification work, evidence, cost, schedule and contractual commitments before approval.
When should impact analysis be performed?
Perform it before approving a baseline change and repeat it when new affected relationships or evidence appear. The depth should scale with consequence, uncertainty and the number of configurations or organisations involved.
What is the difference between direct and indirect impact?
A direct impact touches an item immediately connected to the changed requirement. An indirect impact appears farther through the dependency network, such as a test, supplier interface or budget affected through another requirement.
Can AI perform requirements impact analysis?
AI can traverse known relationships, group affected items and suggest likely missing impacts. Engineers must confirm the relationship meaning, assess technical consequence and approve the resulting change.
What should a change impact assessment template contain?
A useful template records the proposed diff and reason, affected baseline and configurations, dependency paths examined, item-level impacts, owner assessments, verification and evidence consequences, risk and schedule effects, approval conditions, decision authority and closure evidence.
Apply this to a space bid
For a funded hardware project, use this engineering method to assess a changed interface in a supplier bid package. Keep proposed commitments, current evidence and unresolved customer decisions distinct.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.