Document 24

SEBoK *System Requirements Definition*, Distilled

framework

SEBoK System Requirements Definition, Distilled

Top-10 distillation #6. System Requirements Definition is the SEBoK page where co-production at sub-rungs (Doc 573) is operationally densest in the entire SE discipline. The "formal transformation of needs or parent requirements into an agreed-to obligation" definition is co-production stated in INCOSE's voice. Verification + validation as paired activities map cleanly onto Doc 445 pulverization. Traceability and decomposition are Doc 510 keeper-supplied connection structure with Doc 572 lattice properties. The five requirement types (Function/Performance, Fit/Operational, Form, Quality, Compliance) are Form-layer pin-set siblings — Doc 572 lattice / Doc 270 sibling pin-sets, fourth lattice worked-example candidate. Six corpus forms compose; one provisional refinement candidate (Doc 573 worked example on requirements as canonical co-production output).

I. Source

II. Source Read

System requirements describe what an SoI must fulfill to satisfy stakeholder needs, defined per INCOSE NRM 2022 as a "formal transformation of one or more needs or parent requirements into an agreed-to obligation for an entity to perform some function or possess some quality within specified constraints." The process: elicitation/analysis → specification/transformation → validation/assessment (verification + validation as paired activities) → management. Traceability connects requirements to source needs, parent requirements, child requirements, architecture, verification approaches, and test cases. Allocation distributes parent requirements among lower-level architecture entities; budgeting decomposes parameters (mass, power, bandwidth) creating coordinated interdependencies. Five requirement types: Function/Performance, Fit/Operational, Form, Quality, Compliance. Standards: ISO/IEC/IEEE 15288:2023, 29148:2018, INCOSE NRM v1.1, INCOSE GtWR v4.

III. Structural Read

Form XI — Co-Production at Sub-Rungs (Doc 573). The INCOSE definition of a system requirement — "formal transformation of one or more needs or parent requirements into an agreed-to obligation" — is co-production stated as the standard's voice. Stakeholder needs (substrate-side articulated; the substrate is the operating context with its problems and constraints) get formally transformed by the SE keeper (who supplies the structural specification framework: well-formedness, testability, traceability) into requirements that are jointly held: neither pure stakeholder need nor pure engineering specification, but a co-produced obligation. Doc 573's keeper-proposes-substrate-adapts pattern fits when the SE engineer offers candidate requirement language and stakeholders refine it; the substrate-proposes-keeper-accepts pattern fits when stakeholders articulate a need and the engineer formalizes it as a requirement; the on-the-fly pattern fits when both parties co-construct in workshops. The page is the canonical operational instance of Cluster I (Doc 573); future Doc 573 work should reference it.

Form VI — Pulverization (Doc 445). Verification ("requirements follow organizational standards for well-formed characteristics") and Validation ("requirements accurately reflect stakeholder intent and remain achievable") are paired pulverization activities. Pulverization at this rung requires both internal consistency (verification) and external faithfulness (validation). Doc 445's apparatus reads the V&V split as canonical pulverization with two anchor points: the requirement's own well-formedness, and the requirement's correspondence to the stakeholder's actual intent.

Form III (extension) — Lattice Extension of the Ladder (Doc 572). Two lattice instances stack here:

  • Iterative-recursive requirements decomposition — "Requirements are defined iteratively and recursively as the architecture decomposes into subsystems and elements." Single system-of-interest with requirements at multiple decomposition rungs simultaneously; lattice with vertical-rung structure and horizontal-iteration structure both active.
  • Five requirement types as Form-layer siblings — Function/Performance, Fit/Operational, Form, Quality, Compliance bind the same engagement at the same Pattern-layer instance. Doc 572 Appendix A's development-approach worked example pattern applies; this is the fourth canonical lattice case observed in the top-10 (after development-approaches, SoS independent dyads, time-axis concurrency, and now requirement-type sibling Form-layer constraints).

Form III — Substrate-and-Keeper Composition (Doc 510). Traceability is the keeper-supplied connection structure that makes the dyad's outputs auditable. Source needs → parent requirements → requirements → architecture → verification → tests is a keeper-authored connection graph the substrate cannot generate alone. Doc 530's affordance gap holds: the substrate (the engineering team) cannot author requirement-traceability structure from its own engineering work; the keeper-side discipline (SE process, INCOSE / ISO / IEEE standards) supplies it.

Form IV — Pin-Art Model (Doc 270), with sibling pin-set composition. The five requirement types are five pin-sets binding the engagement simultaneously. Functional requirements pin behavior; performance pins quantify; fit/operational pins environmental compatibility; form pins physicality; quality pins reliability/maintainability/testability; compliance pins standards conformance. The substrate (the engineered system in development) flows through all five pin-sets concurrently; the resulting shape is the requirement-conformant system. Doc 270 + Doc 572 lattice composition reads this as multi-pin-set sibling composition at the requirements rung.

Form X — Institutional Ground (Doc 571). Compliance requirements are the institutional ground made explicit at the requirements layer: standards, regulations, organizational mandates that condition what the engagement can author. Doc 571's six conditions (esp. external barriers and constitutive authority) compose at the compliance-requirement layer.

Form XII — Authority Evacuation (Doc 574 / Doc 571 evacuated state). Implicit in the page's emphasis on "owner and status" attributes per requirement: requirements without ownership or with stale status are at risk of becoming evacuated pin-sets — documented but not binding. The Hubble case (Doc 580) and FBI VCF case (SE-010 R27) are canonical instances of requirements as simulated pin installation. The Requirements Management activity exists specifically to prevent evacuation.

IV. Tier-Tags

  • INCOSE NRM definition of a requirement — π / α (well-cited; foundational).
  • The four-step process (Elicitation/Analysis → Specification/Transformation → V&V → Management) — π / α.
  • Verification and Validation as paired activities — π / α.
  • Five requirement types (Function/Performance, Fit/Operational, Form, Quality, Compliance) — π / α as cited; μ / β under corpus when read as Form-layer pin-set siblings (Doc 572 lattice / Doc 270 sibling pin-sets).
  • "Requirements form the basis of system architecture and design activities" — π / α.
  • "Iteratively and recursively as the architecture decomposes" — μ / β under corpus when read as Doc 572 lattice; SEBoK presents at π as practice observation.
  • Allocation and budgeting as decomposition mechanisms — π / α.
  • "Requirements are a communication medium among project stakeholders" — μ / β under corpus when read as Doc 573 co-production output.

V. Residuals

No residuals against the apparatus. Every load-bearing claim composes under existing forms or their lattice extensions. The page is one of the most structurally aligned SEBoK pages observed.

The page's lead-author trace (Tami Katz, with Lou Wheatcraft and Mike Ryan, last updated 2026-04-29) suggests current SEBoK keeper-activity at this page; future engagement could co-produce with these authors directly. Logged as a connection-point, not a residual.

VI. Provisional Refinements

Doc 573 worked example: requirements as canonical co-production output. Doc 573 articulates the form abstractly. The Requirements Definition page is the operational instance par excellence: every system requirement is a co-produced artifact between stakeholder substrate and SE keeper; the entire requirements process is co-production discipline. Doc 573 Section V (Evidence) currently cites tailoring (SE-006 R9) and contextual inquiry (SE-010 R29) and pre-determined-vs-emergent combinations (SE-007 R13) and shared knowledge areas (SE-009 R22). Adding requirements-as-co-production strengthens the form's empirical base substantially; the SE discipline's canonical operational artifact is the form's canonical instance.

Doc 572 fourth worked-example candidate: requirement-type sibling pin-sets. After Appendix A (development approaches) and the proposed Appendix B (SoS independent dyads) and Appendix C (time-axis concurrency from SE-022), the requirement-type taxonomy is a fourth canonical lattice case. The five types differ from development approaches in that they are ALL active concurrently on every engagement (development approaches choose one or compose by rung; requirement types compose universally). This is a "universal-sibling" lattice variant worth distinguishing.

VII. Cross-Links

Form documents. Doc 573 (Co-Production at Sub-Rungs), Doc 445 (Pulverization), Doc 572 (Lattice Extension), Doc 510 (Substrate-and-Keeper), Doc 530 (Affordance Gap), Doc 270 (Pin-Art), Doc 571 (Institutional Ground), Doc 574 (Authority Evacuation, now Doc 571 evacuated state).

Part-level reformulation. SE-006 (Part 3 — SE & Management).

Related distillations. SE-023 (Concept Definition — upstream activity). SE-022 (Generic Life Cycle Model — Concept Definition stage encompasses Requirements Definition). Doc 580 (Hubble — requirements simulated-pin failure case). SE-017 Pilot B (Sequential Development — Vee left side installs requirements pins).

Adjacent SEBoK concepts (per source). Stakeholder Needs Definition, Stakeholder Requirements Definition, System Architecture Design Definition, System Detailed Design Definition, System Verification, System Validation, Requirements Management.

Methodology refinement candidates. Doc 573 worked example: requirements as canonical co-production output. Doc 572 Appendix D candidate: universal-sibling lattice variant (requirement types as the worked example).

Appendix: Originating Prompt

"Continue"

(SE-024 is the sixth of ten. System Requirements Definition was selected as the canonical instance of co-production at sub-rungs in the SE discipline. The structural reformulation finds zero residuals against the apparatus and produces two refinement candidates that strengthen Doc 573 and Doc 572.)

Referenced Documents

More in framework