Why Hardware Programs Fail at System Integration (And What Requirements Have to Do With It)

System integration is where hardware programs go to die quietly. The schedule slip starts around PDR. By CDR, the integration plan has been compressed. When hardware finally comes together, what should be a controlled verification activity turns into a multi-week debugging campaign that no one budgeted for, and which the schedule never recovers from.

The instinct in every post-mortem is to find the technical cause. A connector pinout was wrong. Two firmware teams made different assumptions about message timing. The thermal interface pad had the wrong conductivity. These are the proximate causes — real, specific, embarrassing. The actual cause, sitting one level up, almost never appears in the post-mortem: the requirements that should have prevented each of those problems were either never written, were written but never connected to the teams who needed them, or were written in two different places with two different values.

Integration failure is, in the overwhelming majority of cases, a requirements failure. The hardware did exactly what the engineers designed it to do. The problem is that what those engineers were designing against was not the same thing.

What “Requirements Failure” Actually Means

Requirements failure does not mean someone wrote bad requirements. It means the requirements infrastructure — the set of stated, agreed, traceable, communicated specifications that govern how a system comes together — was not sufficient to prevent integration surprises. This happens in three characteristic ways.

Interface requirements that were never written. An Interface Control Document (ICD) is supposed to be the contract between two subsystems. In practice, ICDs are often written early, treated as done, and then quietly diverge from actual design decisions made downstream. More critically, many interface requirements are never captured at all. Electrical interface specs cover voltage and current. They don’t always cover transient behavior, sequencing requirements, or what happens when one subsystem resets unexpectedly. Mechanical interface specs cover bolt patterns and envelope dimensions. They don’t always cover load transfer paths under thermal cycling. The integration team discovers these gaps when two subsystems are physically connected for the first time.

Performance requirements interpreted differently by two teams. A system-level requirement states a data latency budget: the system shall process sensor input within 200 milliseconds end-to-end. This gets allocated: 40ms to the sensor, 80ms to the processing subsystem, 80ms to the output stage. The processing subsystem team interprets “80ms processing budget” as worst-case under nominal temperature. The system integration team assumes it means worst-case over the full operating temperature range. Neither team wrote down their interpretation, because each assumed it was obvious. At integration, the system fails its latency requirement at high temperature, and the two teams argue for a week about whose interpretation is correct before discovering there is no authoritative source to consult.

Derived requirements that were never communicated. Derived requirements are specifications that a lower-level team generates in response to a parent requirement — not because the system spec said so explicitly, but because their design choices created obligations for adjacent subsystems. A power electronics team selects a switching topology that introduces a 50mV ripple on the 5V rail. Meeting the conducted emissions requirement means that ripple must stay below 20mV at the power input of the downstream processor board. That 20mV limit is a derived requirement. If the power electronics team doesn’t communicate it — or doesn’t recognize it as a requirement at all — the processor board team designs their input filter for 100mV tolerance. Both teams pass their individual verification tests. Integration fails.

The ICD’s Actual Job and Why It Usually Gets Neglected

An Interface Control Document is not a record of what engineers agreed to at the start of the program. It is a living specification of the exact conditions at which two subsystems meet, owned jointly by both teams, and updated whenever either team makes a decision that affects the interface.

In practice, ICDs are written once (usually under schedule pressure at the start of the design phase), blessed at a review, filed in a document management system, and never looked at again until something breaks. By the time integration begins, the ICD often describes an interface that hasn’t existed for six months.

There are structural reasons this happens. ICDs are long, difficult to maintain, and updating them requires coordinating two teams who are both busy designing their own subsystems. When a design decision changes an interface parameter, the engineer who made that decision has to remember that the ICD exists, has to know which section covers that parameter, has to get a document change request approved, and has to notify the other team. That chain breaks constantly. Not because engineers are negligent — because the process asks them to maintain a manual, disconnected artifact in parallel with the work that actually drives their decisions.

The ICD’s job is fundamentally a traceability job: it should maintain a live, current, agreed-upon specification of every parameter at every interface. The document format is not the right tool for that job.

Integration Test Plans and the Traceability Problem

Every integration test case should answer two questions: what requirement is this test verifying, and what does a passing result mean in terms of system compliance?

If a test case doesn’t trace to a requirement, it is either redundant (testing something already covered) or it is testing something that was never specified — which means the team invented a requirement at test time, without the review, negotiation, and baseline process that requirements are supposed to go through. Both situations indicate a requirements infrastructure problem.

In real programs, integration test plans are often written by the integration team based on their engineering judgment about what could go wrong, rather than systematically derived from the requirements baseline. The result is a test plan that covers what the integration team thought to worry about. It won’t cover the interface assumptions that neither team thought to write down — because those, by definition, are not visible.

Proper integration test traceability works in both directions. Every requirement that governs integrated system behavior should have at least one integration test case that verifies it. Every integration test case should point back to the requirement it verifies. This bidirectional traceability serves two functions: it shows you which requirements have no test coverage (a direct schedule risk), and it shows you why each test exists (so that when the test fails, you know what the system-level impact is).

The programs that do integration well treat the requirements database and the integration test plan as two views of the same underlying information, not two separate documents that happen to reference each other occasionally.

Why the Requirements Connection Disappears in Post-Mortems

Post-mortems are conducted by engineers who are tired, under pressure to close out the program, and focused on preventing the specific failure that just cost them six weeks. They root-cause to the level where they can implement a corrective action: update the ICD template, add a connector pinout review checklist, create a timing verification step in the subsystem acceptance test.

These are not wrong corrective actions. But they address symptoms. The causal chain — a requirement that should have existed didn’t, or a requirement that existed wasn’t connected to the team that needed it, or a requirement was ambiguous and both interpretations seemed reasonable — requires examining the requirements process, not the specific artifact that was wrong.

There is also a social pressure in post-mortems that works against requirements-level root cause. Saying “the ICD was out of date” implicates a process and a shared failure. Saying “the connector pinout was wrong” implicates a specific error with a specific fix. Organizations systematically prefer the latter because it feels more conclusive and distributes blame more narrowly. The result is that requirements infrastructure problems accumulate across programs without anyone explicitly deciding to let them accumulate.

How Graph-Based Requirements Models Change Integration Risk

The second half of this article is about how a different kind of requirements tool architecture changes when integration risk becomes visible — specifically, how moving from document-based requirements management to a live, connected graph of requirements and interfaces creates early warning capabilities that document-based tools cannot provide by design.

Flow Engineering (flowengineering.com) is built around a requirements graph rather than a hierarchical document. Requirements are nodes. The relationships between them — parent-child decomposition, interface allocations, derived requirement links, verification assignments — are live edges in the graph. When any element changes, the graph updates, and every relationship that touches that element is immediately visible.

For interface management specifically, this architecture is structurally different from maintaining ICDs as documents. When a system engineer allocates an interface requirement to two subsystem teams, both allocations exist as explicit graph edges. If one subsystem team later modifies their interface parameter — changes a voltage level, adjusts a timing specification, narrows a tolerance — that change is reflected in the graph, and the affected edge to the other subsystem requirement is immediately flagged. The ICD update is not a separate manual task; it is a consequence of the requirement change, visible to both teams in real time.

Derived requirements get the same treatment. Flow Engineering’s model requires that derived requirements be explicitly linked to the parent requirement that generated the design decision that created them. This makes derived requirements traceable rather than implied. A power electronics team creating a ripple specification as a consequence of their topology choice can create that requirement in the shared graph, linked both up to the system EMC requirement and across to the processor board input filter requirement. The processor board team sees it. The gap that normally goes undetected until integration is visible during design.

The integration test traceability problem also has a concrete answer in a graph-based system. Because requirements and test cases are nodes in the same graph, generating a coverage report — which requirements have no test case linked to them — is a query, not a manual audit. Teams can run this report weekly. Requirements without test coverage are surfaced before the integration test plan is finalized, not after the hardware arrives.

Flow Engineering’s focused scope is worth naming directly. It is not a full program lifecycle management system. It does not replace a formal verification management tool, handle procurement tracking, or manage configuration baselines across large multi-contractor programs in the way that IBM DOORS Next or Jama Connect do for organizations that need those capabilities at enterprise scale. Teams with complex regulatory submission workflows or deeply embedded ISO 26262 process compliance requirements may need to layer additional tooling. What Flow Engineering does — graph-based requirements modeling with live interface management — it does in a way that document-based tools cannot replicate, because the document format is not capable of representing live relationships.

Practical Starting Points

If your program is currently in design phase and integration is six months out, three things will reduce integration failure risk more than anything else:

Make interface requirements explicit and bilateral. Every interface between subsystems should have requirements that are owned by both teams, not just one. If the requirement lives only in one team’s spec, the other team doesn’t have to maintain consistency with it.

Require derived requirements to be communicated upward and sideways. Any design decision that creates an obligation for another subsystem — a power rail characteristic, a mechanical load path, a communication timing constraint — should generate a written derived requirement, linked to the design decision and visible to the affected team.

Build integration test cases from the requirements baseline, not from integration team intuition. Run a coverage analysis before your test plan is finalized. Every requirement governing integrated behavior needs a test. Every test needs a requirement it’s verifying.

If your organization is evaluating requirements tools with integration risk in mind, the question to ask any vendor is not “do you support traceability?” Every tool claims that. The question is: when an interface requirement changes, how do the affected teams find out? If the answer involves someone manually updating a document and sending an email, the tool is not solving the integration problem. It is encoding the integration problem in a more expensive format.

The programs that integrate cleanly are not the ones with the most talented integration teams. They are the ones where the requirements structure made the integration state visible before hardware existed. That is a tool and process architecture question, and it has a concrete answer.