Engineering change impact analysis: a worked MBSE example

What change impact analysis is

Every engineering change starts small: one value in one requirement, one part swapped, one interface widened. Its consequences are rarely small, because the item being changed was used by other items. A derived requirement was computed from it, a component was sized against it, a test was passed against it, a budget allocated it. Change impact analysis is the work of finding those dependent items, judging what the change does to each one, and stating the cost, schedule and risk of the whole set before anyone decides.

It has two halves that are easy to confuse:

• Before the decision, impact analysis sizes the change. The change board needs to know what has to be redesigned, re-analysed and re-verified, and what that costs, to approve or reject the request.
• After the decision, impact resolution follows the change through. Each dependent item is checked against the new value and either updated or confirmed, and the check is recorded.

Standards place this work in configuration management. ISO/IEC/IEEE 15288 makes the evaluation of a requested change, and the control of its implementation, part of its configuration management process (6.3.5), and expects the requirements and architecture processes to keep the traceability that makes the evaluation possible. ISO/IEC/IEEE 29148 counts traceability among the characteristics of a good requirement set for the same reason. The NASA Systems Engineering Handbook (NASA/SP-2016-6105 Rev 2) treats change evaluation under requirements management (section 6.2) and configuration management (section 6.5), and the INCOSE Systems Engineering Handbook describes change impact as one of the main uses of the trace web.

In a model-based project the analysis starts from links: the recorded relationships between requirements, functions, components, analyses and tests. The requirements traceability guide explains those links. This guide is about using them when a change arrives, and about what they miss.

The kinds of impact

A change reaches further than the requirement tree. A useful impact analysis checks each of these categories, even when the answer for most of them is "none".

Impacts also differ in depth. A direct impact is one link away from the changed item. An indirect impact arrives through a chain: the arrays change, so the structure that holds them may change, so the mass budget moves. A good analysis follows the chain as far as values actually flow, and stops where they do not.

A repeatable method

The method below works for a requirement change, a design change or an interface change. Its steps are the same whether the links live in a model or in a spreadsheet; a model makes steps 2, 3 and 10 quick and the rest more complete.

1. Frame the change. Write down the item, the old value, the new value and the reason. A request that says "update the power requirement" cannot be analysed; one that says "3.1 from at least 28 W to at least 30 W orbit average, because the load grew to 26 W" can.
2. Trace forward. List everything the changed item drives: lower-level requirements, the design elements that satisfy it, the analyses linked to it and the activities that verify it. Start one link out, then follow any link along which a value flows.
3. Trace backward. Check the parents and the needs above the changed item. Did the cause of the change also change a parent? Is the change still consistent with the need it serves?
4. Look sideways. Search for the value itself. Budgets, measures, test thresholds, operations procedures and document text often quote a number without a link to the requirement that set it.
5. List the blind spots. Note the orphans and coverage gaps near the change. Change impact is computed from the links, so an item without its link is invisible to it.
6. Size each impact. For each item: no change, update, re-analyse, re-verify or redesign. Give it an owner and an estimate.
7. Re-run the budgets. Recompute every budget the change touches and compare the margins with their thresholds.
8. Decide. The change board approves, rejects or sends the request back, with reasons on the record.
9. Implement under control. Apply the approved changes as one recorded step, traceable to the request.
10. Resolve the suspect links. Check each downstream item against the new value, then clear its flag with a reason, or keep it open with an action.
11. Re-verify. Re-run or re-analyse what was judged against the old value.
12. Close. Update the baselines and documents, and close the record only when every open item has an owner.

The downloadable checklist has the same steps with a "done when" condition for each, for use in a change review.

Worked example: 3.1 Orbit Average Power, 28 W to 30 W

The example is EO-1, a fictional 6U CubeSat that images farmland, built in Holarch as an LML project: requirements in SRS-001 EO-1 System Requirements Specification, functions F1 to F11, components under the EO-1 Spacecraft, the EPS Power Budget equations EQ-1.1 to EQ-1.4, and test cases TC-01 to TC-20. It is the same model as the end-to-end MBSE example, and the same change appears there and in the traceability guide; here it is followed step by step. Configuration control is on: approved requirements change only through an approved change request.

The change request

Requirement 3.1 reads "The solar arrays shall generate at least 28 W orbit-average power at end of life", with the rationale "Orbit-average load is 24 W in imaging mode; 28 W gives 15% margin." (24 W × 1.15 = 27.6 W, rounded up to 28 W.) It is Approved and part of the SRR baseline. After the Preliminary Design Review (PDR) the orbit-average load grew to 26 W; the history of TPM-2 Orbit-Average Power Margin records a payload heater load added at PDR. To keep the 15 percent margin, 3.1 has to rise to 26 W × 1.15 = 29.9 W, rounded up to 30 W.

The systems lead, J. Rivera, raises CR-1 Raise 3.1 Orbit Average Power to 30 W. The request holds the reason, the proposed change as a word diff (28 → 30, with the new rationale "Orbit-average load grew to 26 W after PDR; 30 W keeps 15% margin.") and the affected items. Nothing in the model changes until the request is approved and applied.

The list under the affected items is the next layer out: everything traced to the items already in the request. It is long (31 items here, from 3 Electrical Power to the equation variables) because it is not filtered by whether a value flows. Reading it is still worthwhile: it is where TPM-2 first appears.

Tracing forward, backward and sideways

Before the board meets, an impact analysis from 3.1 over the trace links, one level out, shows what the change reaches.

Eight items are one link away, and they fall into three groups:

• Forward, six items. 3.1 is satisfied by 1.3.1 Solar Arrays, F3 Generate and Store Power, F3.1 Convert Sunlight to Power, EQ-1.1 Solar Power Generation and EQ-1.4 Power Margin Check, and verified by TC-06 Solar Array Power Test. Each was judged against 28 W.
• Backward, one item. 3.1 is derived from 1.5 Daily Collection Volume (3.2 GB per day). The parent did not change: TPM-2's history ties the load growth to a payload heater added at PDR, not to a larger daily collection volume. 1.5 needs no action, and the record should say it was checked.
• Sideways, one item. TPM-2 Orbit-Average Power Margin specifies 3.1. It measures the margin of the 28 W allocation over the load, so it changes with the request even though nothing satisfies or verifies anything through it.

Going one level further (the arrays to their cell area and efficiency, the equations to their variables) shows where the numbers come from, and that is where the sideways search begins. A search of the model for "28 W" finds three items no link reaches: the orbit-average power allocation in the spacecraft power budget (28 W), the description of TPM-2, and the Power Margin measure of effectiveness ("against the 28 W need"). None of them is wrong yet, but each will be once the change is applied.

Approval and the six suspect links

The program manager, L. Brandt, approves CR-1 with the note "Load growth confirmed in the PDR power budget. Arrays and TC-06 to be re-checked." The change is applied as one step; 3.1's history records it "via CR-1", and 3.1 goes from Approved back to In Review because its text changed after approval.

Applying it flags every link the change could invalidate. Each downstream link of 3.1 becomes suspect: the judgement it records ("this item fulfills 3.1" or "this test shows 3.1 is met") was made against 28 W.

Two of the eight items from the impact analysis are not flagged, for different reasons. 1.5 is upstream: a change to a derived requirement does not invalidate its parent. TPM-2 is linked by specifies, a relationship the suspect rule does not follow; in Holarch only decomposed by, derived by, refined by, satisfied by, verified by and traced to links are flagged. Check which link types your tool flags, and review the others by hand.

Each suspect link is a small review: read the change, check the item, then clear the flag with a reason or keep it with an action.

Two flags cleared and four open is a normal result. The flags that stay open are the review's findings; clearing them to make the list empty would hide exactly what the change board needs to see.

Why TC-06 stays suspect

TC-06 Solar Array Power Test illuminates the deployed arrays on a solar simulator and sweeps their I-V curve. Its expected result is a peak power of at least 72 W; it measured 75.1 W and passed. The trap is that the test measures peak power while 3.1 constrains orbit-average power. The power budget converts one into the other with EQ-1.3 Orbit-Average Array Power:

P_oa = P_gen × F_sun × K_path, with a sunlit fraction F_sun of 0.62 and a power path efficiency K_path of 0.6, so orbit-average power is 0.372 times peak power.

The measured 75.1 W gives 27.9 W orbit average, below the new 30 W. To show 30 W the arrays need about 30 / 0.372 = 80.6 W peak. The old "Passed" cannot be carried over, so the TC-06 link is not cleared. It stays suspect with the comment "75.1 W peak gives 27.9 W orbit average by EQ-1.3; 30 W needs about 80.6 W peak. Re-test or re-analyse at the new value before clearing."

The same arithmetic exposes two older problems. The original pass was marginal: 27.9 W is also just under the old 28 W. And the 72 W threshold corresponds to only 26.8 W orbit average, so it was never derived from 3.1 through the power budget. The test was also run on the simulator at beginning of life, while 3.1 applies at end of life; whether the model's peak power already allows for array degradation is a question for the power engineer. The resolution is to derive TC-06's expected result from EQ-1.3 at the new value (with any degradation allowance on top), and re-run it once the arrays are settled. The RVTM guide shows how the same suspect mark appears in the verification matrix.

Without the flag, TC-06 would still read "Passed" next to a requirement it no longer proves, and a verification review would count it.

The blind spot: EQ-1.3 has no link

EQ-1.3 Orbit-Average Array Power computes the very quantity that changed, and it is the equation that exposed the TC-06 shortfall. It was not in the impact analysis, it was not flagged, and it is not in the change request. The reason is in the traceability matrix: EQ-1.3 satisfies no requirement. Its sibling EQ-1.4 is linked to 3.1; EQ-1.3 was missed when the links were made.

A reviewer who looked only at the flagged items could have cleared TC-06 against its 72 W peak limit and never run the conversion. That is the engineering consequence of an orphan: change impact is computed from the links, and a missing link is a blind spot. The model was right about the physics and silent about the dependency.

The fix is one link, EQ-1.3 satisfies 3.1. Because 3.1 is under configuration control, the link is itself a change: it goes into a small follow-up request (CR-2, Add a Relationship) rather than being drawn directly. Then look for the pattern rather than the instance: every analysis that computes or checks a requirement's value should be linked to that requirement, and an empty analysis column in the matrix is worth a question before the next change, not after.

The other blind spot: the 3.5 gap

The same matrix has an empty row: 3.5 Battery Thermal Control, "The thermal design shall keep the battery warm enough (TBD)." Nothing satisfies it and nothing verifies it. It is not linked to 3.1 and no impact analysis from 3.1 will reach it, yet it matters to this change.

A battery that has to be kept warm in eclipse usually needs heater power, and heater power is orbit-average load. Today the power budget holds no battery heater, because nothing in the design answers 3.5. When the thermal analysis sets the limit (the requirements writing guide rewrites 3.5 with an illustrative "at or above 0 °C while charging") and a heater is allocated, the load may grow again, and 30 W may already be too little. The 26 W that drives this change is the load of the design as modelled, not of the design that will fly.

A coverage gap near a change is therefore part of the impact analysis: it is a known unknown that can invalidate the new value. The record for CR-1 should name it, with an owner and a date, instead of letting the next change find it.

Budgets and margins

The power budget rolls up each part's orbit-average power draw. For EO-1 the best estimate is 23 W, 25 W with contingency, against an allocation of 28 W: a margin of 3 W, or 10.7 percent, just above the 10 percent the project requires. TPM-2 tracks that margin over time, and its history shows the drop at PDR when the payload heater load was added.

The parametric diagram of the EPS Power Budget runs the numbers. After Solve All, EQ-1.3 turns the 75.43 W peak of the arrays into 28.06 W orbit average, and EQ-1.4 Power Margin Check, P_oa ≥ P_load × (1 + M_req), fails: with P_load = 25 W and M_req = 0.15 it needs 28.75 W.

Three findings follow, and each belongs in the impact record:

• The margin did not close even before the change. 28.06 W against 28.75 W is short by 0.69 W. The change request did not create the problem; the impact analysis found it.
• The load is stated two ways. 3.1's rationale says the load grew to 26 W; the budget feeds EQ-1.4 with 25 W, the roll-up with contingency. With 26 W the check needs 29.9 W and is short by 1.84 W. Which load 3.1 is sized against is a decision, and it has to be the same number in the requirement, the budget and the equation. EQ-1.4's suspect link stays open until it is.
• Raising the allocation is paper margin until the arrays deliver. Moving the budget's allocation from 28 W to 30 W would show 5 W (16.7 percent) of margin, but the arrays produce 28.06 W. The allocation should move with the design decision, not with the requirement.

The design options are now concrete. With EQ-1.1 (P_gen = A × Eta × S × cos(Theta), 1361 W/m² at 0.35 rad), 80.6 W peak needs about 0.214 m² of the same cells (7 percent more area) or about 31.5 percent cell efficiency on the same 0.2 m². The third option is to keep 28 W and accept a margin of 28 / 26 = 7.7 percent, below both the 15 percent of the rationale and the project's 10 percent threshold, which would need its own waiver. Choosing among them is the change board's job, and the person clearing flags should not make that choice by clearing them. More array area on a 6U also touches the structure, the deployment mechanism (3.6 Array Deployment) and the mass budget, so whichever option is chosen starts a smaller impact analysis of its own.

Documenting the decision

The change request is the record. When it is applied, it should show who asked, why, what changed, who approved it and when, and the history of each step.

A change record that will survive an audit holds more than the approval:

• The impact list, with how each item was found: forward, backward, sideways, or by search. The download below is the full list for CR-1, twelve rows.
• The finding and the decision for each item, in one line each: "cleared, no value in the text", "stays suspect, re-test at 80.6 W".
• The options and the choice, with the reasons. For CR-1 the choice between larger arrays, better cells and a lower margin is still open, and the record says so.
• The open actions with owners: revise and re-run TC-06; reconcile P_load; add EQ-1.3's link through CR-2; rewrite 3.5 and add the heater power to the budget; update TPM-2 and the Power Margin measure; raise the budget allocation with the array decision.
• The blind spots: what the links could not show, and what was done to find it.

The record is closed when the suspect links are resolved, the re-verification is done, and the documents and baselines carry the new value. For CR-1 that is after the array decision and the TC-06 re-run, not when the text of 3.1 changed.

Configuration control and change requests

Impact analysis is the technical half of configuration control. The other half is the process that decides: a baseline that says which version of each item is agreed, a change request for any change to it, a board that approves or rejects, and a record that ties each change to its request. ISO/IEC/IEEE 15288 (6.3.5) and the NASA SE Handbook (section 6.5) both describe this loop; the details, such as how many approvers a change needs or which changes a lead may approve alone, are set by each project.

Two rules make the loop work in practice:

• Control what is agreed, not everything. Draft requirements and work-in-progress design change freely. Once a requirement is approved or baselined, changes go through a request. Controlling too early slows the team down; controlling too late means the baseline was never real.
• Keep the review open while the change is locked. Comments, reviews and suspect-link flags must remain usable on controlled items, or a team cannot carry out the review the change requires.

In Holarch a project owner turns on configuration control in the Change Requests settings. Approved requirements and items in the latest project baseline can then be changed only through an approved change request; comments, reviews and suspect-link flags stay open. A request lists its affected items and the items traced to them, stages the edits with a word diff, collects the required approvals (1 to 3, from owners, editors or a named change board on the hosted service) and applies all its changes as one undo step, recorded in each item's history as "via CR-n". The change request log exports to Excel or Word. Interface changes follow the same path; the ICD guide covers interface change control.

Common failure modes

Download the impact record and the checklist

• EO-1 change impact record for CR-1 (CSV): twelve rows, one per item the analysis considered, with how it was reached, the link to 3.1, whether it was flagged, the question, the finding, the decision and the status. It includes the items no link reached.
• Change impact checklist (CSV): the twelve steps of the method, each with the question to answer and a "done when" condition.

Frequently asked questions

How is change impact analysis different from traceability?

Traceability is the set of links; impact analysis is one use of them. Traceability is built continuously while requirements and the design are written. Impact analysis runs when a change is proposed, reads the links around the changed item, and adds what the links cannot show: values quoted without a link, orphans, gaps and budgets.

Are suspect links the same as an impact analysis?

No. An impact analysis comes before the decision and sizes the change; suspect links come after the change is applied and make sure each dependent item is checked. Both follow the same links, so both share the same blind spots.

How many levels should an impact analysis follow?

As many as a value flows through. One level finds the direct impacts. Go further where the downstream item passes the change on (the arrays to the structure and mass), and stop where it does not (a function whose text holds no value).

Who does the analysis, and who decides?

The engineer who raises the change, or the owner of the changed item, usually prepares the analysis, with the owners of the affected items answering for them. A change board or the configured approvers decide. Keeping the two roles apart is what makes the decision independent of the person who wants the change.

Does every change need a change request?

Only changes to agreed items: approved requirements, baselined designs, released interfaces. Drafts change freely. A typo fix in an approved requirement still goes through the process in most projects, but it should not raise suspect flags or need a full analysis.

Try it in Holarch

1. Create the demo with Manage Projects → Project Files ▾ → New Demo Project. Its specification already holds the change to 3.1 and the six suspect links.
2. Open requirement 3.1 and choose Open in ▾ → Spider. With nothing selected, tick only the Traceability family in the inspector's Chart section, select 3.1, click Impact and choose Level 1.
3. Open Needs & Requirements → Suspect Links. Click Diff on a row to see the change, then Clear… with a comment for F3 and F3.1. Leave TC-06 suspect.
4. Open the Parametric Diagram on the equation EQ-1 EPS Power Budget and click Solve All to see EQ-1.4 fail.
5. Open Plan & Deliver → Change Requests, turn on configuration control in Settings, and click New Change Request to propose the missing link: Add Change ▾ → Add a Relationship…, EQ-1.3 satisfies 3.1.

The full reference is in Change Requests, Traceability (impact analysis and the Spider diagram), suspect links and Budgets and TPMs.

Where to go next

• Requirements traceability: the link types, coverage gaps, orphans and the traceability matrix this analysis depends on.
• Requirements verification matrix: how a changed requirement shows in the verification status.
• Needs and requirements in Holarch: documents, quality checks, baselines, change requests and traceability in one model.
• Change Requests docs: configuration control, approvals and the change log.