Stage 3 — Requirements

Functional, performance, interface, constraint reqs + MOPs and TPMs.

Requirements translate stakeholder needs (NGOs) into system obligations. This is the most artifact-dense stage; a Phase-1.4 run on a moderate Brief typically generates 20–60 requirement nodes.

Requirement types

TypeWhat it specifiesExample
FunctionalWhat the system does"The system shall classify visible targets by type."
PerformanceHow well it does it"Classification shall complete within 250 ms of target acquisition."
InterfaceWhat it exchanges with adjacent systems"Telemetry shall be transmitted via CCSDS Space Packet Protocol."
ConstraintBounds it cannot violate"Mass shall not exceed 8 kg."

Every requirement is written in the imperative ("shall") and carries:

  • A unique ID
  • A type (one of the four above)
  • A statement
  • Traceability to at least one NGO
  • A verification method (Inspection / Analysis / Demonstration / Test)
  • An acceptance criterion

MOPs and TPMs

Alongside the requirements, this stage emits:

  • MOPs — Measures of Performance, sitting between MOEs and system requirements
  • TPMs — Technical Performance Measures, lower-level engineering budgets (mass margin, power margin, link margin, etc.)

TPMs are what get tracked in the design phase as the team allocates budgets across components.

Why quality matters here

WARNING
A bad requirement at this stage poisons everything downstream. Decomposition, design, trade studies, and verification all consume this output. Spot-check 5–10 requirements at random before relying on the full bundle.

Things to check:

  1. Singularity — does each requirement state one thing? "The system shall be fast and small" is two requirements
  2. Verifiability — can it actually be measured or demonstrated? "User-friendly" is not verifiable; "operator can complete the nominal procedure with ≤ 3 errors" is
  3. Traceability — does the requirement cite at least one NGO? Orphan requirements often indicate over-generation
  4. No designs in disguise — "The system shall use a Kalman filter" is design, not requirement. Requirements specify the "what", design picks the "how"

Traceability

Every requirement has a traces_to: [...] field listing the NGO IDs it's derived from. The Requirements Traceability Matrix (RTM) in render/requirements.md shows this in a table form — auditors love this view.

Next

Decomposition →