System Requirements Specification (SyRS)

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 formal System Requirements Specification (SyRS) for the system modeled in [model name] in Dalus, following ISO/IEC/IEEE 29148:2018.

SOURCES, resolve in this order before doing anything else:
1. Check whether a copy of ISO/IEC/IEEE 29148:2018 has been made available in the model’s attached documents or this conversation. If present, derive structure and content expectations from it and cite specific clause or figure numbers only when you are reading them from that copy. Use of licensed standards content with AI tooling is subject to the user’s licence terms.
2. If the user has uploaded their program’s own template or an example SyRS, that file governs APPEARANCE and numbering (cover page, headers, document ID scheme, table layout, styles). ISO/IEC/IEEE 29148 governs CONTENT and section intent. Merge the two.
3. If no standard text is available, generate from the well-known 29148 SyRS structure (Introduction, References, System Requirements organised by category, Verification, Appendices including Assumptions & Dependencies and Traceability) and state clearly on the cover that the document was generated without the standard text present and that clause references have therefore been omitted.

READ THE MODEL fully: part hierarchy, connections with ports, flows and variable units, all requirements with IDs, statements, attributes (including rationale, source, priority, risk, status, verification method, allocation/subsystem), satisfy / parent relationships, verification items, test cases and which requirements they reference, states, modes, mission/operational cases, hazards, assumptions, dependencies, and constraints.

READ-BACK, always, before generating: report in a short message what the document will be built from:
- requirement counts broken into (a) requirements with complete statements, (b) grouping / container records with no “shall” statement, (c) records with empty or placeholder statements — the three must add up to the model total;
- verification coverage (how many requirements have a method assigned vs missing);
- presence of rationale, source, and priority attributes;
- architecture and behavior counts (parts, interfaces, states/modes);
- 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/revision 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 and context derived from the part hierarchy, connections, and any operational concept information in the model.
- Default organisation is category-primary using the classic 29148 SyRS categories:
  Functional, Usability, Performance, Interface (External / Internal), System Operations, Modes & States, Physical Characteristics, Environmental Conditions, Security, Information Management, Policy & Regulation, Life-cycle Sustainment, Packaging/Handling/Shipping/Transportation.
  Within each category, group or tag by subsystem / allocation. Subsystem-primary ordering is available only on explicit request (“group by subsystem”).
- Where a model requirement type does not map cleanly, mark the classification as “inferred” and show the original model type alongside.
- Grouping / container records are rendered once in a dedicated structure or traceability section, not as individual requirements. Empty-statement records are listed in a dedicated final subsection so the total reconciles; state the reconciliation arithmetic explicitly.
- Categories that contain no requirements are collapsed into a single short list titled “Categories with no requirements in the current model” rather than generating empty stub sections.
- Interface requirements are cross-checked against actual ports and flows in the model; every external interface present in the model must appear, with units where defined.
- Operational content (modes, states, mission cases) is derived from the corresponding model elements.
- Assumptions, dependencies and constraints are populated from the model where recorded and explicitly stated as missing where not.

VERIFICATION MAPPING, apply strictly:
- Only a verification entry recorded on the requirement itself counts as populated. Render the method using the classic vocabulary (Inspection, Analysis, Demonstration, Test) unless the model or an attached template dictates different terms; in that case use the model/template terms and note the mapping.
- Never render a model Action as a verification method. If an entry points at an Action or test case, render the implied method and name the Action / test case as the reference.
- A test case that references the requirement but is not yet linked as the formal verification method is rendered as “candidate: Test, via [TE-x / TestCase-ID]”, visibly distinct from a populated verification method.
- Verification entries attached to non-requirements (grouping records or empty-statement records) are themselves findings.

UPWARD TRACEABILITY:
- Where the model holds stakeholder needs, an StRS, or links to higher-level requirements, show the upward trace for each system requirement.
- System requirements that have no upward trace are flagged as “derived without recorded source”.

CONSISTENCY CHECKS, run across the whole model, not per statement:
- Requirement against requirement: contradictory values, inverted logic, overlapping or conflicting scope.
- Requirement against model attributes: units and magnitudes, mass vs mass limits, power vs budgets, timing consistency.
- Suspected data truncation: any statement that ends mid-word, mid-value, or with an obvious incomplete phrase is a finding.
- Missing parent, broken satisfy links, or missing upward trace where hierarchy is claimed.

QUALITY RULES (characteristics of well-formed requirements):
- Necessary, implementation-free, clear & concise, complete, singular (single subject), achievable, verifiable, correct.
- No prohibited vague terms (“adequate”, “sufficient”, “user-friendly”, “etc.”, “and/or” without clear meaning, unbounded “maximize/minimize”).
- Missing rationale is recorded as a Minor finding when the model supports the attribute.
Never silently rewrite a requirement. Every violation is recorded in the findings annex with:
- the original text,
- a suggested rewrite,
- SEVERITY: Blocker (contradiction, missing top-level need, or unverifiable critical requirement), Major (ambiguous or non-verifiable as written), Minor (style, singular, missing rationale, or wording).
Order findings by severity.

GAPS: never invent values, requirements, interfaces, verification methods, or traces. Sections that cannot be populated state exactly what is missing from the model. The document ends with a consolidated gap list ordered by what most blocks a complete, reviewable specification, phrased as concrete work to do in the Dalus model, after which the document can be regenerated.

LAYOUT:
- Default: compact requirement tables, one row per requirement with columns:
  ID | Statement | Category | Subsystem / Allocation | Parent | Upward Trace | Rationale (if present) | Verification Method | Status | Priority (if present)
  Grouped by 29148 category. On explicit request (“detailed layout”), use one block per requirement instead. Requirements do not receive individual numbered headings in either layout.
- Wide matrices (full bidirectional traceability, verification cross-reference, gap list) on landscape pages.
- Model constraints, classification notes, and tailoring notes appear where they exist.

OUTPUT QUALITY, non-negotiable:
- Word document (.docx) with clear section numbering, a POPULATED table of contents readable on first open (static text is acceptable; a live field may sit behind it), running headers, page numbers, and a cover page that carries:
  document ID, issue/revision, generation date, source model name and ID, which sources were used (standard text available yes/no, program template yes/no), tailoring applied (yes/no + short note), and clear DRAFT status.
- No instructions to the reader and no “TODO” or placeholder instructional text left in the body of the finished document.
- Before delivering, render the document and visually verify at least: the cover page, the table of contents, one populated requirement table, the assumptions/dependencies section, and one annex. Fix and re-render if anything is broken or incomplete.
- This workflow only reads the model; it writes nothing back. After delivering the document, offer (do not execute) turning the gap list into tracked tasks or model cleanup actions.

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