Ask an experienced integration engineer where programs fail and you will rarely hear "the subsystems did not work." You will hear that the subsystems worked fine on their own and failed at the seam between them — one side sent data in the units the other side did not expect, one side assumed a message rate the other could not sustain, one side powered up in a sequence the other was not designed to tolerate. Integration is where the interfaces get exercised for the first time, and interfaces are where the assumptions two teams made independently finally collide. The Interface Control Document, or ICD, exists to make those assumptions explicit and agreed before integration turns them into failures.
An interface is any boundary across which two elements interact, and the categories are broader than newcomers expect. There are functional interfaces (what one side does for the other), physical interfaces (mechanical mounting, connectors, envelopes), electrical interfaces (power, grounding, signal levels), data interfaces (message formats, protocols, timing, byte order), thermal interfaces (heat conducted or radiated across a boundary), and environmental interfaces (what each side exposes the other to). A single connection between two subsystems can involve several of these at once. The ICD is the document that captures, for a given interface, everything both sides must agree on for the connection to work.
The reason interfaces need their own management discipline, separate from requirements, is ownership. A requirement typically belongs to one element and one team. An interface belongs to two, and neither owns it alone. This shared ownership is exactly why interfaces get neglected — each side assumes the other is handling the details, and the boundary falls into the gap between two responsibilities. The ICD forces the issue by making the interface a controlled artifact that both parties sign up to, so the definition is a negotiated agreement rather than two independent guesses that happen to be documented in separate specifications.
It is worth distinguishing the Interface Requirements Document from the Interface Control Document, because programs use the terms loosely and the distinction is useful. The Interface Requirements Document (IRD) captures the requirements on an interface — what the interface must accomplish, the constraints it must satisfy — early, when the interface is still being defined. The Interface Control Document captures the detailed, agreed definition — the specific pin assignments, the exact message structures, the precise mechanical dimensions — as the design matures. In practice many programs merge them or use one term for both. What matters is that both the requirements on the interface and the detailed control of its definition are captured and managed, whatever you call the documents.
The data interface is where modern systems break most often, because it is where the most detail hides and the most assumptions live. A data ICD has to pin down the message set (which messages exist), the structure of each message down to the field, the data types and units and valid ranges of every field, the byte order and encoding, the message rates and timing constraints, the protocol and error handling, and the behavior at startup and under fault. Every one of these is a place where two teams can quietly disagree. The classic integration failure — one side sends a value in meters, the other reads it as feet — is a units mismatch that a properly detailed ICD would have caught on paper, months before the hardware met.
Interface definitions change, and changes to an interface are more dangerous than changes to an internal requirement precisely because they are bilateral. When one team modifies its side of an interface — adds a field, changes a rate, revises a connector — the other side may be silently broken until integration reveals it. This is why interface change control is stricter than ordinary change control on many programs: an Interface Control Working Group or equivalent body reviews proposed interface changes with both sides present, because a unilateral interface change is one of the fastest ways to inject an integration failure that will not surface until it is expensive to fix.
This is where interfaces meet traceability, and where treating them as documents rather than as connected data costs programs dearly. An interface is defined by interface requirements, which trace up to the system requirements that demanded the connection and down to the design elements on both sides that implement it, and across to the verification activities that will prove the interface works. When an interface definition changes, everything in that web is potentially affected — the requirements that assumed the old definition, the design on both sides, and the interface verification tests. If the ICD is a standalone Word document disconnected from the requirements and the design, that impact is invisible, and the change propagates by email and memory. If the interface is a connected element in the same model as the requirements, the change flags exactly what it touches.
Interface verification is its own activity that too many programs treat as an afterthought of subsystem testing. Verifying that each side independently conforms to the ICD is necessary but not sufficient — you also have to verify the interface end to end, exercising the actual connection with both sides present, because conformance to a document does not guarantee two conforming implementations actually interoperate. Interface verification cross-reference — every interface requirement mapped to the test, analysis, or demonstration that proves it — belongs in the V&V matrix alongside functional requirements verification. An interface requirement with no verification method is exactly as dangerous as a functional requirement with none, and arguably more, because the failure it hides shows up at integration when schedule margin is thinnest.
Interfaces are also where the ConOps and the requirements first make contact with the outside world. The concept of operations establishes, in narrative form, that the system will exchange data with a particular external network, ground segment, or clinical information system long before an ICD exists. Those operational expectations flow into interface requirements, which flow into the detailed ICD. Keeping that pedigree connected — from the operational need to interoperate, to the interface requirement, to the controlled interface definition, to the interface verification — is what lets a program answer "why does this interface exist and does it still serve its purpose?" when the ConOps evolves and an operational assumption shifts.
The failure modes are consistent across every domain. Interfaces defined too late, after both sides have committed to incompatible internal designs, so the ICD documents a conflict rather than preventing one. Interfaces defined too vaguely — "the subsystems shall exchange telemetry" with no message-level detail — so the real definition happens ad hoc during integration. Unilateral interface changes that skip the bilateral review and silently break the other side. And ICDs maintained as disconnected documents, so an interface change never flags the requirements, design, or tests that depended on it. Each of these turns a manageable boundary into an integration surprise.
The discipline that prevents this is not exotic. Define interfaces early, at least at the requirements level, so both sides design to an agreed boundary rather than discovering it at integration. Capture the detail the interface actually needs, especially for data interfaces where units, ranges, timing, and encoding are where mismatches hide. Manage interface changes bilaterally, with both owners reviewing every change. And treat the interface as a traceable element wired to the requirements it serves, the design that implements it, and the verification that proves it — so an interface change surfaces its full impact instead of hiding until integration. Interfaces get the same rigor as requirements because, at integration, they are where the requirements were actually right or wrong.
Hitt Hosting SE treats interfaces as first-class, connected elements rather than as standalone documents. Interface requirements link up to the system requirements that demanded the connection, across to the design elements on both sides that implement it, and forward to the verification activities that prove the interface works, so the full web around an interface is queryable. Because interfaces live in the same model as requirements, risks, and V&V, a change to an interface definition flags every requirement, design element, and test that depended on the old definition — the bilateral impact that email-based ICD management misses. Interface verification sits in the same coverage view as functional verification, so an unverified interface shows up as the gap it is, and the ICD a review board asks for generates from the live, agreed data instead of being reconciled by hand before integration reveals what everyone assumed.