Technical Requirements Specification (TS)

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 Technical Requirements Specification (TS) for the
system modeled in [model name] in Dalus, following ECSS-E-ST-10-06C.

SOURCES, resolve in this order before doing anything else:
1. Check the model's attached documents and this conversation for an
   uploaded copy of ECSS-E-ST-10-06C. If present, derive the structure
   directly from Annex A (the TS DRD) and follow its clauses, citing
   clause numbers where you apply them.
2. If the user has uploaded their program's own template or an example
   TS, that file governs APPEARANCE and numbering (cover page, headers,
   document ID scheme, table layout). ECSS governs CONTENT. Merge.
3. If no standard is attached, generate from the ECSS structure you
   know and state on the cover that the document was generated without
   the standard text present.

READ THE MODEL fully: part hierarchy, connections with ports, flows and
variable units, all requirements with IDs, statements, attributes and
satisfy relationships, verification items, test cases and which
requirements they reference, states, modes, mission cases, hazards.

READ-BACK, always, before generating: report in a short message what
the document will be built from: requirement counts broken into
(a) requirements with statements, (b) grouping records with no shall
statement, (c) records with empty statements, so the three add up to
the model total; verification coverage; architecture and behavior
counts; and the two or three structural problems the reader should
expect to see flagged rather than fixed. Then ask exactly ONE question
combining: does project tailoring apply, and is there a document ID
scheme and issue number to use (otherwise auto-generate one and mark it
as such). If the user replies "fast", skip further questions and use
defaults.

STRUCTURE AND MAPPING:
- System description from the part hierarchy and connections.
- Classify every stated requirement into the ECSS clause 6.2 types.
  Where the model type differs or is absent, mark the classification
  as inferred and show the model type alongside.
- Grouping records are rendered once, in a traceability structure
  section, not as requirements. Empty-statement records are listed in
  a dedicated final subsection so the total reconciles, and the
  reconciliation arithmetic is stated explicitly.
- Interface requirements cross-checked against actual ports and flows;
  every external interface in the model must appear, with units.
- Operational content derived from States and mission cases.

VERIFICATION MAPPING, apply strictly:
- Only a verification entry recorded on the requirement itself counts
  as populated, and its method must be rendered as one of: test,
  analysis, review of design, inspection. Never render a model Action
  as a method; if an entry points at an Action, render the method it
  implies and name the Action as the reference.
- A test case referencing the requirement is rendered as "candidate:
  Test, via [TE-x]", visibly distinct from populated verification.
- Verification entries attached to non-requirements (grouping or empty
  records) are themselves findings.

CONSISTENCY CHECKS, run across the whole model, not per statement:
- Requirement against requirement: contradictory values, inverted
  probabilities, overlapping scope.
- Requirement against model attributes: units and magnitudes (a
  requirement in newtons against an attribute in seconds is a
  finding), masses against mass limits, powers against budgets.
- Suspected data truncation: any statement ending mid-word or
  mid-value is a finding.

QUALITY RULES from the standard's requirements on requirements:
single-subject, quantifiable, verifiable, no prohibited vague terms.
Never silently rewrite. Every violation goes to the findings annex
with a suggested rewrite and a SEVERITY: Blocker (contradiction or
missing top-level requirement), Major (unverifiable or ambiguous as
written), Minor (style). Order findings by severity.

GAPS: never invent values, requirements or interfaces. Unpopulatable
sections state exactly what is missing. The document ends with a
consolidated gap list ordered by what blocks the specification most,
phrased as work to do in the Dalus model, after which the document can
be regenerated.

LAYOUT:
- Default: compact requirement tables, one row per requirement
  (ID, statement, type, parent, allocation, verification, status),
  grouped by ECSS type, so the document stays reviewable. On request
  ("detailed layout"), one block per requirement instead. Requirements
  do not get individual numbered headings in either layout.
- Wide matrices (verification cross-reference, gap list) on landscape
  pages.
- Model constraints and classification notes appear where they exist.

OUTPUT QUALITY, non-negotiable:
- Word document with ECSS-style numbering, a POPULATED table of
  contents readable on first open (static text; a live field may sit
  behind it), page numbers, and a cover page carrying: document ID,
  issue, generation date, source model name and ID, which sources
  were used (standard attached yes/no, program template yes/no),
  tailoring applied, and DRAFT status.
- No instructions to the reader anywhere in the document body.
- Before delivering, render the document and visually verify the
  cover, TOC, one requirement table and one annex. Fix and re-render
  if anything is broken.
- This workflow only reads the model; it writes nothing. After
  delivering, offer (do not execute) turning the gap list 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