How Do You Write Good Interface Requirements Between Hardware Subsystems?

The question sounds basic. Every systems engineer has written interface requirements. Most have also sat in an integration lab at midnight watching two subsystems that individually passed all their tests refuse to work together. The requirements were complete — technically. The interface, apparently, was not.

Interface requirements are the hardest class of requirement to write well. They live at the boundary between teams, between disciplines, and between organizations. They’re owned by everyone and enforced by no one. This article is a practical guide to writing them correctly, recognizing the failure modes before they become hardware problems, and maintaining them as designs evolve.

What an Interface Requirement Actually Specifies

Start with the definition. An interface requirement is a verifiable obligation placed on a system or subsystem at a defined boundary with another system or subsystem. It does not describe internals. It does not reference a single component. It specifies what must be true at the boundary — and it must be testable there.

That boundary can be physical (a connector), logical (a software API), electrical (a bus), thermal (a mounting surface), or some combination. Good interface requirements cover all six categories of interface characteristics:

Physical. Geometry, connector type, pin count, keying, mounting pattern, mass constraints, and spatial envelope. Example from aerospace: “The payload interface plate shall mate with the launch vehicle adapter using a 24-bolt pattern on a 650 mm bolt circle diameter, with fastener holes toleranced to ±0.1 mm positional accuracy.” That’s verifiable with a go/no-go gauge. A requirement that says “the interface plate shall fit the adapter” is not.

Functional. What the interface must do — what signals or forces or fluids pass across it, and what behavior each side must exhibit. Example: “The engine control unit shall provide a throttle-by-wire command signal to the electronic throttle controller within 10 ms of receiving an accelerator pedal position input.” The 10 ms is owned at the interface. Neither the ECU nor the throttle controller can claim it alone.

Electrical. Voltage levels, current limits, impedance, signal polarity, ground references, ESD protection classes, isolation requirements, and power quality. This is where automotive engineers spend most of their interface requirement time. A requirement like “the battery management system shall supply 12 V ±0.5 V at up to 20 A continuous to the gateway module connector J3” is complete. One that says “the BMS shall supply 12 V power” is not — it leaves the tolerance, the current limit, and the connector undefined.

Thermal. Heat rejection, temperature limits at the interface surface, thermal resistance requirements between mating components, and coolant flow rates if applicable. In high-density electronics assemblies, thermal interface requirements are chronically underspecified. “The RF power amplifier module shall not present a thermal resistance greater than 0.4 °C/W between the device case and the chassis mounting surface at the specified fastener torque.” That is a requirement. “The RF module shall not overheat” is a wish.

Data. Message content, data formats, units, scaling, endianness, valid range, update rate, latency, and error handling. An AUTOSAR-based automotive system might specify: “The wheel speed sensor shall transmit a CAN message with identifier 0x3A0 at a 10 ms cycle time, containing wheel speed in rpm as a 16-bit unsigned integer, scaled at 0.1 rpm/LSB, valid range 0–6553.5 rpm, with a rolling counter and checksum per ISO 17458.” Every element in that sentence is independently verifiable.

Protocol. The handshaking, enumeration, error recovery, power sequencing, and initialization behavior. This matters most in complex digital interfaces. “The payload computer shall complete USB enumeration within 2 seconds of power-on and shall re-enumerate within 500 ms of a bus reset without requiring a power cycle.” Protocol requirements are frequently missing from requirements documents and present only in the ICDs — which creates the traceability problem discussed below.

The Difference Between an Interface Requirement and an Interface Definition

This distinction trips up experienced engineers. It is not semantic.

An interface requirement is normative. It states what shall be true. It has a verification method. It is owned by the system.

An interface definition — typically captured in an Interface Control Document (ICD) — is descriptive. It documents the agreed design of the interface. It is owned jointly by the two teams on either side of the boundary.

Here’s the relationship that matters: requirements flow down, ICDs flow up. The system requirements authority writes interface requirements. The subsystem teams negotiate the interface definition that satisfies them. The ICD is the artifact that captures that agreement. The interface requirements trace to sections of the ICD; the ICD does not replace the requirements.

In practice, many programs skip the requirements and go straight to the ICD. This produces two failure modes. First, nobody verifies the interface against a requirement — they verify against the ICD, which was designed by the same people who built the hardware. Second, when the ICD changes (and it will), there is no requirements baseline to assess impact against. You’re left reconciling two versions of a Word document.

The aerospace standard ECSS-E-ST-10-06 makes this explicit: interface requirements belong in the system requirements specification; ICDs are design documents that must remain consistent with them. The same principle applies whether you’re working to DO-178, ISO 26262, or an internal standard.

The Three Most Common Failure Modes

1. Circular requirements. This happens when both subsystems specify requirements that assume the other is correct. Subsystem A says: “shall accept input from 3.0 V to 3.6 V.” Subsystem B says: “shall output a voltage compatible with Subsystem A’s input specification.” That second requirement is not a requirement. It references a requirement it doesn’t define, creating a circular dependency that cannot be closed without auditing both specifications simultaneously. The fix is to assign a single numeric obligation at the interface and make both sides trace to it. The system requirement owns the number.

2. Performance not captured at the interface. Latency, bandwidth, accuracy, and dynamic range requirements are frequently specified only inside subsystems, not at the boundary. The result: two subsystems that individually meet their performance specs but together fail to meet system performance. Automotive active safety is where this hurts most. If the radar processing module meets its 30 ms processing latency requirement and the vehicle dynamics controller meets its 20 ms actuation latency requirement, but the system requirement for obstacle response latency is 40 ms end-to-end, you have a problem that neither subsystem requirement surfaces. End-to-end interface requirements must bound the budget.

3. Tolerance stack-ups ignored. Geometric tolerances on connectors, mating surfaces, and cable lengths interact. Thermal expansion differentials between aluminum chassis and titanium fasteners change contact resistance. Signal timing tolerances accumulate across a data path. All of these are interface phenomena that require explicit analysis — and the results of that analysis must flow back into the interface requirements. A requirement that specifies a connector pin position to ±0.2 mm is meaningless unless someone has checked that the accumulated manufacturing tolerances of the mating connector, the PCB footprint, and the chassis machining actually close within that value.

ICDs in Practice: What They Must Contain and What They Can’t Replace

A well-constructed ICD is a design document that enables integration. It should contain: interface geometry drawings, connector pinouts, signal definitions and electrical characteristics, data dictionary, timing diagrams, test points and test access requirements, and change history with configuration control.

What an ICD cannot do: establish verification accountability, provide requirements traceability, or communicate upstream when a change invalidates a system-level obligation. Those functions belong to requirements. Teams that rely on ICDs as their sole interface specification tool discover this during integration testing, when a late ICD revision changes a signal timing and nobody can answer whether a system requirement was violated — because there was no system requirement to trace to.

A practical rule: every row in an ICD that makes a performance claim should trace to at least one interface requirement. If it doesn’t, you either need a requirement or you need to ask why the claim is in the ICD.

Writing good interface requirements is one problem. Keeping them synchronized with evolving hardware designs, ICDs, and verification plans over a multi-year program is a harder one. This is where tooling matters.

Traditional requirements management platforms — IBM DOORS, Jama Connect, Polarion — handle requirements as text attributes in structured documents. They support traceability through manually maintained links, and many programs have used them effectively for decades. The limitation is that interface requirements are inherently relational: they connect two subsystems, they reference ICD sections, they constrain system architecture decisions. Document-centric tools represent these relationships awkwardly. The traceability matrix becomes a maintenance burden rather than an analytical asset.

Graph-based tools change the mechanics significantly. When requirements, subsystems, interfaces, and ICDs are nodes in a connected model, an interface requirement isn’t just text with a few links appended — it is a first-class edge between two system entities, with properties that can be queried, validated, and maintained programmatically.

Flow Engineering is built on this model. Interface requirements in Flow Engineering are authored as explicit relationships between subsystem nodes, with the six interface domains represented as structured properties rather than free text. When a design change updates the electrical characteristics of an interface, the tool surfaces which requirements are potentially affected — not through a manual change-impact analysis but through the graph structure of the model itself.

For the requirement author, this changes the workflow. Instead of writing a paragraph and then manually inserting trace links, the engineer writes the interface requirement in context — linked to the specific interface, the specific ICD baseline, and the specific verification event. The requirement is embedded in the model, not pasted into a document that lives alongside it.

For teams managing ICDs, Flow Engineering allows ICD sections to be linked directly to the requirements they satisfy. When an ICD changes — even in a late design cycle — the tool identifies which requirements need re-review. This doesn’t eliminate the engineering judgment required to assess impact, but it eliminates the document archaeology that typically precedes that judgment.

The practical starting point for a team transitioning to this model isn’t to re-write all existing requirements. It’s to instrument the highest-risk interfaces first: the ones that cross organizational boundaries, the ones with late-closing ICDs, and the ones where integration failures have happened before. Start with those six interface domains, write requirements that have numeric bounds, assign verification methods to each, and link them to the ICD sections that define the design. That structure, once established, becomes the artifact that survives design iteration.

Writing Requirements That Survive Integration

The test of an interface requirement is not whether it passes a compliance review. It’s whether, at integration, you can point to a measurement and say: “the interface either passed or failed this requirement.” If the answer is ambiguous — because the requirement referenced a description rather than a bound, because the tolerance was unspecified, because the protocol behavior was only in the ICD — the requirement failed before the hardware did.

Good interface requirements are uncomfortable to write. They require someone to own a number. They require negotiation between teams. They require analysis of tolerance stacks and timing budgets before the design is complete. That discomfort is not a process problem to be optimized away. It is the mechanism by which integration risk gets surfaced early, while there’s still time to do something about it.