System Requirements Document (SRD)

The problem this solves

Spec documents get written twice: once as engineering, once as formatting. Teams keep requirements in a tool, then spend days copying them into a template, renumbering sections, and rebuilding the traceability table. By the time it is signed, the model has moved on.

How it works

You are generating a System Requirements Document (SRD) for the system
modeled in [model name] in Dalus, responding to a customer
specification. This is the supplier-side document: it states our system
requirements, each traceable to the customer's requirements, and is
baselined at SRR.

SOURCES, resolve in this order before doing anything else:
1. The customer specification: an uploaded TS, requirement spec, or
   RFO requirement annex. This input is MANDATORY. If none is uploaded
   and none is attached to the model, stop and ask for it; an SRD
   without a customer baseline is a different document.
2. Check for an attached copy of ECSS-E-ST-10C (system engineering
   general requirements). If present, locate the SRD DRD among its
   annexes and derive the document structure from it, citing clauses.
   If ECSS-E-ST-10-06C is also attached, apply its clause 8 rules to
   how our requirements are written.
3. If the user has uploaded a program template or example SRD, it
   governs appearance and numbering. ECSS governs content. Merge.
4. If no standard is attached, generate from the ECSS SRD structure
   you know and say so on the cover.

INGEST THE CUSTOMER SPECIFICATION first: extract every requirement
with its ID, statement, and type if given. Report the count. If IDs
are absent, assign positional references (CUST-001...) and say so.
Never alter a customer statement.

READ THE MODEL fully, as in the TS workflow: parts, connections,
flows with units, requirements with IDs, statements, attributes and
satisfy relationships, verification items, test cases, states,
mission cases, hazards.

READ-BACK, always, before generating: customer requirement count and
how many the model appears to respond to; model requirement counts
reconciled (stated / grouping / empty); the main coverage holes the
reader should expect; structural problems flagged rather than fixed.
Then ask exactly ONE question combining: does tailoring apply, and is
there a document ID scheme and issue number (otherwise auto-generate
and mark it). If the user replies "fast", use defaults.

COVERAGE ANALYSIS, the core of this workflow:
- For every customer requirement, find the model requirement(s) that
  respond to it, by explicit trace where the model has one, otherwise
  by content match marked as inferred.
- Assign each customer requirement a compliance status: Compliant
  (responding requirement fully answers it), Partial (responds but
  weaker, narrower, or unquantified), Not covered (no responding
  requirement), Not applicable (justify why). Never mark Compliant by
  optimism; when in doubt, Partial with the doubt stated.
- Every model requirement that traces to NO customer requirement is a
  derived requirement. Derived requirements are legitimate but each
  must carry a stated rationale; missing rationale is a finding.

STRUCTURE AND MAPPING:
- Render our system requirements grouped by ECSS requirement type,
  each with: ID, statement verbatim, type (inferences marked), parent,
  allocation, verification (TS v2 mapping rules apply: only entries on
  the requirement count as populated; test-case references are
  candidates), status, and RESPONDS TO: the customer requirement
  ID(s), or "Derived" with rationale.
- Grouping records and empty records handled as in the TS workflow,
  with explicit count reconciliation.

CONSISTENCY CHECKS, across both documents:
- Our requirement against the customer requirement it answers: units,
  magnitudes, direction (a customer minimum answered by our maximum is
  a finding), tolerances weaker than demanded.
- Our requirements against each other and against model attributes,
  as in the TS workflow.

FINDINGS with severity, ordered: Blocker (customer requirement not
covered, contradiction between our response and their demand), Major
(partial coverage, unverifiable response, derived requirement without
rationale), Minor (style). Suggested rewrites never applied silently.

ANNEXES, in this order because the first is the flagship:
A. Compliance matrix: one row per customer requirement: customer ID,
   customer statement (abbreviated), status, responding requirement
   ID(s), remark. Landscape. If the customer supplied their own
   compliance matrix file (e.g. an xlsx), ALSO fill that file in their
   format and deliver it alongside the document.
B. Derived requirements register with rationales.
C. Verification cross-reference.
D. Consolidated gap list ordered by what most endangers the response:
   uncovered customer requirements first, phrased as work to do in the
   Dalus model, after which this document can be regenerated.

GAPS: never invent a responding requirement to make coverage look
better. An uncovered customer requirement is rendered as uncovered.

OUTPUT QUALITY: identical to the TS workflow, non-negotiable:
populated static table of contents on first open, page numbers, cover
page with document ID, issue, date, source model, customer document
identified by name and date, sources used, tailoring, DRAFT status.
No instructions to the reader in the body. Render and visually verify
before delivering. Read-only on the model; after delivering, offer
(do not execute) turning uncovered requirements into tracked tasks.

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

Example output

What you get

Your format

Other tools hand you empty templates to type into. Because the document chain maps to requirement levels in the model — stakeholder needs at the top, system requirements below, satisfied by parts — one Dalus model emits the whole chain and cross-document traceability comes free.

Common questions