What Makes a Good Interface Requirement — and How Teams Get Them Wrong

Interface requirements sit at the boundaries between subsystems — electrical, mechanical, thermal, data, RF, structural — and they determine whether the pieces integrate into a working system or become the subject of a root-cause investigation six weeks before delivery. They are also, consistently, the worst-written requirements in any hardware program.

This is not because the engineers who write them are careless. It is because interface requirements are structurally difficult: they involve two organizations with different schedules, different models, and different incentives. The requirement has to describe obligations that belong to neither side exclusively, which means no one naturally owns it. That ownership vacuum is where most integration problems originate.

What a Good Interface Requirement Actually Is

Four properties define a well-formed interface requirement. When one of them is missing, you have a failure mode, not just a quality issue.

Specific. An interface requirement must state the parameter, the value, the units, and the operating condition. “The connector shall be compatible with the power supply output” is not a requirement. “The subsystem input impedance shall be ≥ 50 Ω across 0–500 kHz at nominal supply voltage of 28 VDC ± 0.5 V” is a requirement. The test engineer needs to know what to measure, at what conditions, and what passes.

Bilateral. Every interface has two sides. A good interface requirement defines the obligation of each side: what Side A shall provide, what Side B shall accept. A requirement written entirely from Side A’s perspective — even if technically accurate about what A will output — leaves Side B’s acceptance envelope undefined. Integration depends on the envelope of both. When you state only one side, you are not writing an interface requirement; you are writing a performance specification for one subsystem that happens to mention a boundary.

Testable. Testability at an interface is often harder than testability within a subsystem, because integration tests involve both sides simultaneously, with all the scheduling and configuration complexity that implies. A good interface requirement anticipates the verification method. If the only way to verify it is a full-system test, that is worth knowing at requirement writing time — and it should shape how the requirement is decomposed. If verification requires a specific stimulus and a specific measurement point, both should be traceable back to the requirement.

Owned by the system architecture. This is the hardest property to achieve organizationally. An interface requirement belongs to the system, not to the subsystem on either side of it. If the power subsystem team writes the interface requirement for the compute subsystem’s power input, the compute team will spend three months designing to a margin they did not validate. If the compute team writes it, the power team will discover the mismatch when they try to qualify the connector. The system architect — or the systems engineering function accountable to the integrated system — must own interface requirements as a class. This is not an administrative preference; it is a direct consequence of what an interface requirement describes.

The Three Common Failure Modes

One Side Writing Without Coordination

The most common failure: a subsystem team writes an interface requirement to describe what they need from the other subsystem, without a formal coordination loop. The requirement may be technically sound on its face, but it is missing the bilateral commitment. The receiving team never formally accepted the obligation. When they later discover that meeting the stated requirement conflicts with their own design constraints, the negotiation happens in an integration meeting rather than a requirements review — at the worst possible time.

The coordination failure is structural. If the process for writing interface requirements does not require a sign-off from both sides, bilateral requirements will not be produced. Teams naturally write requirements from their own perspective, using their own models, in their own requirement management tools. Without a mechanism that forces convergence, the interface lives in two separate documents that will drift apart.

TBD Performance Parameters

“TBD” in a requirement is sometimes legitimate — early in a program, before trade studies close, some parameters genuinely cannot be baselined. The problem is not TBD values at program start. The problem is TBD values that persist past the point where the downstream subsystem must make design decisions based on them.

Interface requirements have a deadline that is not the ICD review date. The deadline is when the first downstream design decision depends on the parameter. After that point, a TBD is not a placeholder — it is a risk that has already materialized. The downstream team either stops work (schedule impact), makes an assumption (risk), or proceeds optimistically (integration surprise).

Most programs have no formal tracking of parameter TBD status relative to design dependency timelines. The interface requirement is baselined with TBDs flagged and promptly forgotten until the design review at which the depending team is asked to show compliance.

Interface Definitions Maintained Separately from System Requirements

The Interface Control Document is the historical mechanism for managing this problem. The ICD captures the agreed interface definition between two subsystems, owned jointly (in principle) by both teams, and maintained through a formal change control process. When ICDs work, they work because someone enforces that maintenance.

They fail in a predictable way. The ICD is a document. The system requirements are in a requirements management tool. The subsystem specifications are in separate tools or documents. When a design change affects an interface, the change propagates through the program’s change control process — which updates some artifacts and not others, depending on whether the change author knew which documents to list as affected. The ICD falls behind the requirements model. The requirements model doesn’t know what changed in the ICD. Both claim to be the authoritative baseline.

Change control governance can slow this drift, but it cannot eliminate it when the interface definition exists in a document that is structurally disconnected from the requirements it constrains. The governance mechanism — a change control board, an ICD review cycle, a bilateral sign-off process — is being asked to compensate for a structural problem. Governance compensates; it does not fix.

ICD Governance: What Works and What It Cannot Do

Formal ICD governance is necessary. A bilateral change control process, with both subsystem teams as signatories on any interface change, is the correct mechanism for managing interface agreements between organizations. Programs that skip it pay for it in undocumented verbal agreements and tribal knowledge that evaporates when people leave.

What governance cannot do is maintain consistency automatically. When the system architecture changes and twelve interface requirements need updating, governance tells you who must approve the changes. It does not tell you which interface requirements are now inconsistent with the system model, or whether the bilateral obligations have been restated correctly, or whether the verification approach still applies to the updated parameter. Those assessments require human review — and they require that someone is looking at the right artifacts at the right time.

The gap between what governance can enforce and what actually needs to happen is where most ICD problems live. The process says the ICD must be updated before PDR. The engineering team updates the parameters they know changed. The parameters that changed indirectly — because a mass budget shifted, which changed a thermal interface, which changed a mechanical clearance — are missed because no one was looking at the dependency chain.

This is not a people problem. Engineers working from disconnected documents cannot see dependency chains that the documents do not encode.

How Modern Requirements Tools Address Interface Requirements

The structural fix to the disconnected-document problem is to encode interfaces as entities in the requirements model — not as cross-references between document sections, but as first-class objects with properties, owners, and relationships to the requirements on both sides.

When an interface is a node in a requirements graph rather than a reference in a document, several things become possible that are not possible with document-based management.

Bilateral completeness is checkable. If the interface entity carries properties for “Side A obligation” and “Side B obligation,” the tool can flag interfaces where one side is defined and the other is not. This is not a sophisticated AI function — it is a simple query. But it requires that the interface be a structured entity rather than a document section.

TBD tracking against design milestones is automatable. If an interface parameter is marked TBD and the requirements graph encodes which downstream requirements depend on it, the tool can surface which TBDs are blocking downstream closure. “This TBD is depended upon by these 4 requirements, which are allocated to Subsystem B, which has a PDR in 6 weeks” is information the model can generate. A document cannot.

Change impact is propagable. When a system-level requirement changes and that change affects an interface, the graph can identify which interface requirements are downstream of the changed requirement. The change author can see the affected interfaces before the change is approved, not after the ICD review discovers the inconsistency.

Flow Engineering implements interfaces as first-class entities in the requirements graph. Interface requirements carry explicit bilateral structure — each interface node captures the obligations of both sides, with separate ownership fields and verification linkages. The completeness view shows teams which interfaces have open bilateral obligations, which parameters are TBD, and which TBDs have downstream dependencies that are not yet closed. This makes interface requirement completeness an observable property of the model rather than a judgment call by the systems engineer reviewing a document.

The practical effect is visible in integration planning. When a team can query “show me all interface requirements where the acceptance parameter is TBD and the depending requirement has a PDR within 90 days,” they have an actionable list, not a discovery risk. Flow Engineering surfaces this through live requirement completeness metrics tied to the interface graph, making the gap between what is defined and what integration requires visible at any point in the program.

For ICD governance, the implication is that the ICD is no longer a separate document that needs to be synchronized with the requirements model — the interface entities in the requirements graph are the ICD, with the change control history attached to the entities themselves. The governance process does not change, but it operates on a single source of truth rather than on documents that are always slightly out of sync.

Practical Starting Points

If your program is already running and the ICDs are documents, you cannot immediately restructure everything. But you can do three things that will have immediate effect.

First, audit your open TBDs against design dependency timelines. For each TBD on an interface parameter, identify the earliest downstream design decision that depends on it. If that date is past or within the next program phase, escalate — that TBD has already affected design whether or not it is formally closed.

Second, add a bilateral completeness check to your ICD review process. For every interface requirement in your current ICDs, confirm that both sides’ obligations are explicitly stated. Requirements that describe only one side’s output or only one side’s input are incomplete. Do not wait for a full rewrite — flag and close the gaps incrementally.

Third, when you next update your requirements tool setup or evaluate tools, treat interface support as a first-class criterion. Ask specifically: can the tool represent an interface as a structured entity with bilateral properties? Can it query interface completeness across the program? Can it show change impact propagating through interface dependencies? The answer determines whether you will be managing your ICDs or merely storing them.

Interface requirements are where systems engineering earns its value — and where document-based processes show their limits most clearly. The engineering knowledge to write a good interface requirement is not rare. The structural conditions that ensure it gets written, coordinated, maintained, and verified are what most programs are missing.