How Do You Handle Requirements Conflicts Between Subsystem Teams?

A systems engineer on a spacecraft program sent us this question:

“Our propulsion subsystem generates peak thermal loads of 340W during main engine burns. Our thermal control subsystem was allocated a maximum heat rejection requirement of 280W. Both teams built to their allocated requirements. Both are technically correct. Now we’re in PDR and neither team thinks it’s their problem. What’s the right process here?”

This is a well-posed question, and it describes a situation that happens on nearly every complex hardware program at some point. The specifics vary — propulsion and thermal, power and avionics, structures and mechanisms — but the pattern is consistent: two subsystem teams each built something correct in isolation, and the combination is physically impossible.

The instinct is to treat this as a conflict between teams and mediate. That instinct is wrong. This is a process failure, and the fix is not negotiation — it is returning to the system level and doing the interface work that should have happened earlier.

What This Conflict Is Actually Telling You

When subsystem requirements are physically incompatible, one of two things went wrong upstream:

Premature allocation. The system-level thermal budget was allocated to subsystems before the interface between propulsion and thermal was fully defined. The 280W number was probably derived from a trade study or mass model that predated the propulsion team’s detailed thermal analysis. The thermal team’s requirement was correct at the time it was written. It’s now stale.

Insufficient interface definition. The interface between propulsion and thermal — specifically, what heat the propulsion system is contractually allowed to generate and under what operating conditions — was never formalized into an Interface Control Document (ICD). Without that formalization, both teams had a number but no shared model of what that number meant and how it would be verified.

In either case, the root cause is not a disagreement between engineers. It is a gap in the systems engineering process. Treating it as a personnel or organizational conflict will produce a negotiated outcome that may or may not be physically valid, and it will leave the underlying process gap open to produce another conflict later.

Who Has Authority to Resolve This

Before touching any requirement, establish who has decision authority. On a well-structured program:

  • Subsystem teams own the internal requirements and design decisions within their allocated interface bounds. They do not have authority to change their allocated requirements unilaterally.
  • The systems engineer (or systems engineering lead, depending on program structure) owns the system-level requirements and the interface definitions. They have authority — and responsibility — to adjudicate conflicts by returning to system-level requirements.
  • The chief engineer or program systems engineer is the escalation path if the conflict involves schedule, cost, or risk decisions that exceed the SE lead’s authority.

In the scenario above, neither the propulsion team lead nor the thermal team lead has the authority to resolve this conflict. The moment it reached PDR as an open item, it became a systems engineering issue. The SE lead should have caught this before PDR — the fact that it surfaced there is itself a process signal.

What the SE lead should not do: call a meeting between the two team leads, let them negotiate, and document whatever they agree on. That produces a social resolution, not a technical one.

The Formal Process for Resolving Interface Incompatibilities

Here is the sequence that produces a defensible, traceable outcome:

Step 1: Document the Discrepancy Formally

Create a formal discrepancy report or requirement change request that captures:

  • The conflicting requirements by identifier (propulsion thermal output spec, thermal system rejection requirement)
  • The magnitude of the conflict (60W delta in this case)
  • The operating conditions under which the conflict occurs (main engine burn, duration, duty cycle)
  • The date the conflict was identified and by whom

Do not let this live in meeting notes or email threads. It needs to exist in whatever requirements management system the program uses, with a status that the configuration control board can track.

Step 2: Trace Both Requirements to Their System-Level Parent

Pull the requirements traceability for both conflicting specs. The propulsion thermal output requirement and the thermal rejection requirement should both trace to a parent: a system-level thermal management requirement, a power-thermal budget, or a spacecraft-level performance requirement.

If they trace to the same parent, you have an allocation math error — the parent was distributed inconsistently across children. If they trace to different parents, you may have a system architecture gap where no single requirement governs the interface.

This traceability exercise tells you where to go to find the authoritative source, and it tells you whether the fix is a re-allocation or a missing requirement.

Step 3: Convene a Trade Study, Not a Negotiation

Once you know the system-level parent, the SE lead should initiate a formal trade study that evaluates options, not a meeting where the two teams argue. The trade study options in this scenario might include:

  • Increase the thermal system’s rejection requirement (cost, mass, power implications)
  • Constrain the propulsion system’s burn duty cycle (performance implications)
  • Add a thermal storage (phase change) solution that buffers peak loads (cost, mass)
  • Redefine the thermal requirement to specify average versus peak (verify whether the system-level requirement actually cares about peaks)

Each option has cost, mass, schedule, and risk dimensions. The SE lead evaluates them against system-level requirements and constraints — not against what either subsystem team prefers.

Step 4: Revise Requirements Through Configuration Control

Once the trade study produces a recommendation, the resolution goes through formal configuration control. Both affected requirements get revised with:

  • A rationale statement linking the revision to the trade study
  • Updated traceability to the parent requirement
  • A change log entry in the ICD covering the propulsion-thermal interface
  • Notification to any other subsystems that may be affected by the change

The ICD update is critical. If the propulsion-thermal interface now has a formal 340W allocation at a specific duty cycle, that number needs to live in a controlled document that both teams can reference — not in someone’s memory of a meeting.

Step 5: Update the Interface Control Document

This step is where most programs fail to close the loop. The ICD between propulsion and thermal needs to be updated to formally define what the propulsion system is allocating thermally to the thermal system, under what conditions, and how this will be verified. “Thermal output during main engine burn: 340W maximum, duty cycle not to exceed X minutes per orbit” is a verifiable interface requirement. “We talked about it and it should be fine” is not.

The ICD is the contract between subsystems. If it did not exist before this conflict, creating it is part of the resolution — not an optional follow-on.

Why This Keeps Happening: The Document-Based Requirements Problem

The scenario above is not unusual. Programs running requirements in document-based tools — Word, Excel, IBM DOORS in flat-list mode — routinely encounter interface conflicts late because the tool does not model interfaces as first-class artifacts.

In a document-based process, requirements live in separate subsystem requirement specifications. The propulsion spec is a document. The thermal spec is a document. The ICD is a third document, possibly managed by a different team. When the propulsion thermal output changes during design, nothing in the toolchain automatically surfaces the implication for the thermal spec or the ICD. Someone has to notice, and in a fast-moving program with ten simultaneous subsystem design cycles, they often do not notice until integration.

The verification matrix — which maps requirements to verification events — is usually built separately from both, which means the interface incompatibility may not surface until a test that was supposed to close two requirements simultaneously fails.

This is not a criticism of the teams. It is a structural consequence of treating requirements, interfaces, and verification as separate documents rather than as connected elements of a single model.

How Systems Graph Models Change the Visibility Problem

This is where the architecture of your requirements tooling matters. Tools that represent the system as a connected graph — where requirements, subsystem functions, interfaces, and verification events are all nodes with explicit relationships — can surface interface conflicts during design rather than during integration.

Flow Engineering is built on this graph-based model. In Flow Engineering, subsystem requirements and the interfaces between subsystems are first-class artifacts in the same model. When the propulsion team updates their thermal output requirement, that update propagates through the graph to the interface edge connecting propulsion to thermal, which immediately surfaces as a status change on the thermal team’s side. The conflict does not require a scheduled review or a sharp-eyed engineer to notice — it is structurally visible.

More specifically, Flow Engineering’s approach to interface requirements means that the ICD is not a separate document that someone has to remember to update. Interface requirements are defined on the edges between subsystem nodes in the model. When a requirement on either side changes in a way that affects an interface edge, the model flags the inconsistency. This is the difference between a system that requires discipline to catch conflicts and a system that makes conflicts hard to miss.

Flow Engineering is focused on the systems engineering layer — requirements, interfaces, traceability, and verification planning. It is not a design tool or a simulation environment. Programs that need to model thermal physics or run integrated hardware simulations will need additional tools connected to it. But for the requirements and interface management layer, the graph-based approach addresses the structural problem that causes conflicts like the one described above to appear late.

Practical Starting Points If You Do Not Have Graph-Based Tooling

If your program is running in a document-based environment and you cannot switch tooling mid-program, you can reduce the frequency and severity of interface conflicts by doing the following:

  1. Identify all subsystem-to-subsystem interfaces explicitly at system requirements review, and assign a responsible engineer to each ICD before subsystem requirements are allocated.
  2. Require ICD signatures before subsystem CDRs. A subsystem design is not ready for CDR if its interfaces are not formally documented and agreed.
  3. Run a cross-requirements consistency check before each major milestone. Pull every requirement that references a physical interface quantity — power, heat, force, bandwidth, data rate — and verify that the numbers are consistent across the documents that share that interface.
  4. Track interface requirement changes through configuration control the same way you track subsystem requirements. An ICD revision that is not formally controlled is not a real ICD.

Honest Assessment

The 60W conflict between propulsion and thermal is fixable. The process to fix it is well-defined: document it, trace it, trade it, revise it, control it. What makes these conflicts expensive is not the technical gap — it is the time spent discovering them late, assigning blame, and running informal negotiations that produce undocumented decisions.

The systems engineer asking this question is doing the right thing by recognizing it as a process problem. The answer is not to pick a winner between the two teams. The answer is to go back to the system level, find the authoritative source of truth, and update the interface definition with the rigor it should have had from the start.