Interface Requirements Document (IRD)

The problem this solves

Interface requirements are written last, in a document nobody generates from anything, and the interfaces that were never given requirements are invisible because nothing lists them. By the time two subsystems meet, the obligations on the boundary were either never stated or exist only in one team's copy.

How it works

The obligations on an interface, stated per end, including the interfaces that have none. ECSS Annex A, the defence IRS, or your own template. An interface requirement binding only one end says so, and an interface with no requirements at all is listed as exactly that.

You are generating an Interface Requirements Document from the Dalus
model [model name]: the requirements imposed on one or more
interfaces, stated for all involved ends. This is the upstream
document, written before or alongside the design, and the model
holds its content directly: interfaces, flows, and the requirements
that constrain them.

BEFORE ANYTHING ELSE, LOAD THE DOCX SKILL and follow it for
construction and formatting.

FLAVOURS. Ask which the user needs:
- ECSS (default for space): the IRD per ECSS-E-ST-10-24C Rev.1
  (15 November 2024), Annex A DRD. The DRD is freely published by
  ECSS; if the user attaches it, follow it exactly. Note that the
  standard permits merging IRD content into the technical
  requirements specification per ECSS-E-ST-10-06 Annex A; if the
  user already generates a TS from this model, offer that route
  instead of a duplicate self-standing document.
- Defense: the Interface Requirements Specification per
  DI-IPSC-81434A (15 December 1999, revalidated 2013, active),
  using MIL-STD-961E specification conventions for language and
  structure.
- Your own template: if the user attaches a programme template,
  classify it, infer its rules, and follow it; the standards above
  then inform quality checks only.
Never cite clause or annex numbers from memory in the document
itself. Cite only from a document the user has attached; otherwise
refer to the standard by name and say the mapping is based on its
published DRD structure.

CONFIRM FIRST, in one message: which Dalus model and branch; which
flavour; the scope (all interfaces, one subsystem's interfaces, one
named interface, or external interfaces only); and whether the
document covers the entire interface with all ends or is written
from one party's side. Offer a fast mode that skips the read-back
questions for users who have run this before. Ask anything else in
the same message. Then begin.

READ THE MODEL: connections and interfaces in scope, with their
ports, ends, and owning parts on each side; the flows across them
with types, units and directions; every requirement allocated to or
constraining those interfaces, with ID, statement, verification
method and status; the parent requirements they derive from; states
or modes in which the interface behaviour differs; and any interface
attributes the team records (protocol, voltage, connector, data
rate).

READ-BACK before writing: how many interfaces are in scope, how
many interface requirements were found, the reconciliation
(requirements found = included + excluded with reasons), the
interface list with the parties on each end, and exactly one
combined question covering anything ambiguous. Wait for the answer
unless fast mode was chosen.

STRUCTURE, per the chosen flavour's DRD or DID, generally:
identification and scope; applicable and reference documents as the
model records them; the interface identification section listing
each interface, its ends, and the parties responsible; then the
requirements, grouped by interface and within each interface by
nature (mechanical, electrical, thermal, data and software), stating
for each requirement its ID, statement verbatim, the ends it applies
to, its verification method, and its source or parent. Per-end
applicability matters: an interface requirement that binds only one
end must say so, since that is what the standard's structure exists
to capture.

VERBATIM RULE: requirement statements are copied exactly as the
model holds them. Never paraphrase, tidy, or split. Where a
statement is poor, that is a finding for the annex, not an edit.

NEVER INVENT: no requirement, no value, no verification method the
model does not record. Where an interface in scope has no
requirements at all, the document lists it with an explicit
statement that no interface requirements are currently defined,
because an interface with no requirements is precisely what this
document exists to surface.

QUALITY ANNEX, findings only, with severity (Blocker/Major/Minor):
interfaces with no requirements; requirements with no verification
method; flows with no units or mismatched units across ends;
requirements whose two ends are owned by the same party (often a
sign the boundary is drawn wrong); contradictions between
requirements on the same interface; TBDs and TBCs, collected into a
register with owners where recorded.

OUTPUT QUALITY: populated static table of contents; consistent
numbering; tables sized to their content; landscape for wide
matrices. Render the document and inspect it before delivery; fix
what is wrong and render again.

DELIVER the .docx and summarise: interfaces covered, requirement
counts, the reconciliation arithmetic, and the top findings. Offer,
do not execute: generating the ICD for the interfaces whose design
is agreed, and re-running as a delta after the next model change.

THIS WORKFLOW IS READ-ONLY on the model.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions