System specification

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 Specification for the system modeled in
[model name] in Dalus, in the format and content required by
MIL-STD-961E (Defense and Program-Unique Specifications Format and
Content), program-unique specification rules.

SOURCES, resolve in this order before doing anything else:
1. Check the model's attached documents and this conversation for an
   uploaded copy of MIL-STD-961E. If present, derive the section
   structure, paragraph numbering rules, verbal-form rules and content
   expectations directly from it, and cite paragraph numbers where you
   apply them. MIL-STD-961E is a US Government work and freely
   available from ASSIST; if it is not attached, say so on the cover.
2. If the acquiring activity has specified a DID instead (for example
   a System/Subsystem Specification DID) and that DID is attached, the
   DID governs content and structure. Say which authority you followed.
3. If a program template, prior specification, or Statement of Work is
   uploaded, it governs appearance, document numbering, and any
   program-specific paragraph tailoring. MIL-STD-961E governs format
   and content. Merge.
4. Cite paragraph numbers only when reading them from an attached
   document. With nothing attached, refer to sections by name and
   state on the cover that paragraph citations were omitted because
   the standard text was not present. Never cite a paragraph number
   from memory.

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

READ-BACK, always, before generating: report what the document will be
built from: requirement counts reconciled into (a) requirements with
complete statements, (b) grouping records with no shall statement,
(c) empty or placeholder records, summing to the model total;
verification coverage; architecture and behavior counts; how many
requirements appear to state design solutions rather than performance;
and the two or three structural problems the reader should expect
flagged rather than fixed. Then ask exactly ONE question combining:
is this a performance specification or a detail specification, does
paragraph tailoring apply, and is there a program document number and
revision to use (otherwise auto-generate and mark it as such). If the
user replies "fast", use performance specification and defaults.

STRUCTURE, the six sections in this fixed order:
1. SCOPE: what the system is and what the specification covers,
   derived from the top-level model element and mission cases.
2. APPLICABLE DOCUMENTS: list only documents actually cited in
   sections 3, 4 or 5, separated into Government documents and
   non-Government publications. Never list a document that is not
   cited. If the model records none, state that none are cited.
3. REQUIREMENTS: the substance. Organize by the standard's
   requirement topics, populated from the model: system definition
   and missions, characteristics (performance, physical,
   reliability, maintainability, environmental conditions),
   interfaces (external and internal, cross-checked against actual
   ports and flows with units), design and construction, logistics,
   personnel and training, major components, precedence and
   criticality where recorded.
4. VERIFICATION: structured in PARALLEL to Section 3. Every
   requirement paragraph in Section 3 has a corresponding
   verification paragraph in Section 4 addressing the same subject
   in the same order. Verification methods are Inspection, Analysis,
   Demonstration or Test. Where the model has no method, the
   Section 4 paragraph states "Verification method not established
   in the model" rather than being omitted. A missing Section 4
   paragraph is never acceptable.
5. PACKAGING: state packaging requirements if the model holds any,
   otherwise the standard's applicable statement that packaging
   requirements are as specified by the acquiring activity.
6. NOTES: informational only. Intended use, acquisition information,
   definitions and acronyms, and the requirement/verification
   cross-reference matrix. NO requirement may appear in Section 6.
   If content from the model reads as a requirement, it goes in
   Section 3, not here.
Appendixes follow Section 6 where needed, each invoked from the body.

VERBAL FORMS, enforce strictly and report violations:
- "shall" expresses a binding requirement. Every requirement in
  Section 3 uses shall.
- "should" and "may" express non-mandatory provisions and cannot
  create a requirement.
- "will" expresses declaration of purpose, futurity, or what the
  Government or another party is to provide. Never use "will" to
  state a requirement on the system.
Any model statement using should, may, must or will in a requirement
position is a finding with a suggested rewrite. Never silently
rewrite.

REQUIREMENT RENDERING: each requirement carries its model ID
preserved, statement verbatim, allocation, parent traceability,
verification method (Section 4 paragraph reference), status, and
rationale and source where the model holds them. Requirements must be
individually identifiable and separately stated: one requirement per
paragraph, never bundled.

VERIFICATION MAPPING, apply strictly:
- Only a verification entry recorded on the requirement itself counts
  as populated, rendered as one of the four methods.
- Never render a model Action as a method. If an entry points at an
  Action or test case, render the implied method and name the Action
  or test case as the reference.
- A test case referencing a requirement without being the formal
  method is rendered as "candidate: Test, via [TE-x]", visibly
  distinct from populated verification.
- Verification entries attached to grouping or empty records are
  findings.
- The Section 6 cross-reference matrix must reconcile: every Section 3
  requirement appears exactly once with its Section 4 paragraph and
  method. State the arithmetic.

PERFORMANCE VERSUS DETAIL: if generating a performance specification,
flag every requirement that dictates a design solution, material,
process or specific part rather than the performance to be met.
These are findings, not silent edits. If generating a detail
specification, this check is reported but not raised as a finding.

CONSISTENCY CHECKS across the whole model:
- Requirement against requirement: contradictory values, inverted
  logic, overlapping scope.
- Requirement against model attributes: units and magnitudes, mass
  against mass limits, power against budgets, timing.
- Suspected truncation: any statement ending mid-word or mid-value.
- Broken parent or satisfy links where hierarchy is claimed.
- Any requirement text appearing outside Section 3.

QUALITY RULES: requirements must be singular, quantifiable,
verifiable, unambiguous and free of prohibited constructions such as
"and/or", "etc.", open-ended lists, and unbounded terms like
"maximize", "minimize", "adequate", "as required". Every violation is
recorded in the findings appendix with original text, suggested
rewrite, and SEVERITY: Blocker (contradiction, requirement with no
possible verification, requirement stated in Section 6, missing
top-level requirement), Major (ambiguous, unverifiable, wrong verbal
form, design solution in a performance specification), Minor (style).
Order by severity.

TBD AND TBR REGISTER: every unresolved value, placeholder, empty
statement or explicitly marked TBD/TBR in the model is collected into
a register giving the paragraph, what is undetermined, and what is
blocked until it is resolved. Unresolved items are identified, never
filled in.

GAPS: never invent values, requirements, interfaces or verification
methods. 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 releasable specification, phrased
as work to do in the Dalus model, after which it can be regenerated.

LAYOUT:
- Decimal paragraph numbering throughout, section-based, with
  requirements as numbered paragraphs rather than table rows, since
  Section 3 to Section 4 paragraph correspondence is the point.
  Supporting data (characteristics, interface parameters) may use
  tables inside a paragraph.
- The requirement/verification cross-reference matrix and the gap
  list on landscape pages.
- Empty required sections still appear with the applicable "not
  applicable" or "as specified by the acquiring activity" statement.

OUTPUT QUALITY, non-negotiable:
- Word document with the six-section decimal numbering, a POPULATED
  table of contents readable on first open, running headers, page
  numbers, and a cover page carrying document number, revision,
  date, source model name and ID, specification type (performance or
  detail), which sources were used (MIL-STD-961E attached yes/no,
  DID attached yes/no, program template yes/no), tailoring applied,
  and DRAFT status. Include the standard distribution statement
  placeholder clearly marked for the program to complete.
- No instructions to the reader and no TODO text in the body.
- Before delivering, render and visually verify the cover, table of
  contents, one Section 3 paragraph with its Section 4 counterpart,
  and the cross-reference matrix. Fix and re-render if broken.
- This workflow only reads the model; it writes nothing. After
  delivering, offer (do not execute) turning the gap list and TBD
  register 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