Document 85

SEBoK *Requirements*, Distilled

framework

SEBoK Requirements, Distilled

Third-batch distillation, batch 1 doc 6. The keeper-supplied article Requirements resolves on the SEBoK to the System Requirements Definition page in Part 3, with the standalone Requirements and System Requirements URLs functioning as redirect-or-404 navigation pointers. The article carries the INCOSE NRM 2022 definition of a requirement statement 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 with acceptable risk." The five-category requirement taxonomy (Function/Performance, Fit/Operational, Form, Quality, Compliance) is universal-sibling lattice (Cluster A) at the requirement rung — this is the structural sibling of SE-024's enumeration but at finer grain. The three-function purpose-statement (foundation for design, integration-and-verification basis, communication tool) is universal-sibling at the requirement-purpose rung. Co-production at sub-rungs (Cluster D) is the canonical structural reading: requirements are formally transformed from needs, with the keeper supplying the rung-2 obligation form and the engagement supplying the rung-1 substrate. Six corpus forms compose; Cluster A reaches eleven; Cluster D anchor candidacy strengthens.

I. Source

II. Source Read

System Requirements Definition is the opening phase of the System Definition Process (Part 3). It transforms stakeholder needs into technical specifications. INCOSE NRM 2022: a requirement statement is "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 with acceptable risk."

System requirements serve three major functions: (a) foundation for design (basis for system architecture and design activities); (b) integration and verification (guide for system integration and verification efforts); (c) communication tool (dialogue among project team members throughout development).

Five primary requirement categories: (1) Function/Performance — primary functions and performance characteristics addressing intended use, capability, feature expectations; (2) Fit/Operational — secondary and enabling capabilities for system integration with external systems; (3) Form — physical characteristics (shape, size, dimensions, mass, weight); (4) Quality — fitness for use, including the "-ilities" such as reliability and maintainability; (5) Compliance — conformance with design standards and regulations.

Key planning activities: verification planning (defining success criteria and verification methods during requirement generation), interface analysis (identifying interactions across system boundaries through a three-step process), traceability management (relationships to needs, parent requirements, design elements), attribute tracking (rationale, ownership, criticality, verification approach). Requirements management ensures ongoing alignment throughout the lifecycle. Position: Part 3 SE and Management > System Concept Definition.

III. Structural Read

Cluster A (universal-sibling lattice, Doc 572 Appendix D). Two universal-sibling instances co-present. First, the five-category requirement taxonomy (Function/Performance, Fit/Operational, Form, Quality, Compliance) is universal-sibling lattice at the requirement-type rung. Each category binds every requirement universally as one aspect-of-specification. Second, the three-function purpose-statement (foundation, integration-and-verification, communication) is universal-sibling at the requirement-purpose rung. The two axes compose: every requirement instantiates one or more types and serves one or more purposes simultaneously. Cluster A reaches eleven independent instances. The article is structurally adjacent to SE-024 (Types of System Requirements) but at finer grain — SE-024 enumerates within Function/Performance, Fit/Operational, etc.; SE-085 enumerates the macro-categories. The two-doc pair is the canonical hierarchical-Cluster-A worked example.

Cluster D (co-production at sub-rungs, Doc 573) — anchor candidate. The INCOSE NRM 2022 definition is the canonical Cluster D articulation. A requirement is "a formal transformation of one or more needs or parent requirements into an agreed-to obligation." The keeper-side supplies the rung-2 obligation form (the "agreed-to" structure, the stakeholder need, the parent requirement); the engagement-side supplies the rung-1 substrate (the entity to perform the function, the system carrying the quality). Neither alone produces the requirement; the requirement is co-produced. SE-039 D7 (anchor-article-per-cluster) candidate refinement reaches strong support for Cluster D anchored by SE-085.

Cluster B (multi-keeper composition, Doc 604). "Agreed-to obligation" implies multi-keeper agreement: the keeper imposing the obligation and the keeper bearing it must compose. Traceability management ("relationships to needs, parent requirements, design elements") is the explicit reconciliation-rung discipline. Cluster B extends through the requirement-as-agreement structural reading.

Cluster H (hypostatic boundary, Doc 372). "An obligation for an entity to perform some function or possess some quality within specified constraints" is functional-and-qualitative specification, never ontological claim. Doc 372 reads NRM 2022 as native discipline: requirements describe what the system must do or be qualified-by, not what the system is.

Cluster I (pin-art / temporal-concurrency, Doc 270, SE-022). "Verification planning during requirement generation" is the canonical pin-art articulation: the verification action is pinned at requirement-generation time, not deferred to verification time. SE-022 temporal-concurrency lattice composes naturally — requirements activity and verification activity are concurrent at requirement-generation rung.

Cluster F (pulverization, Doc 445). "Requirements management ensures ongoing alignment throughout the system lifecycle" is longitudinal-pulverization: requirements are not produced once but maintained across time. Doc 445 D longitudinal axis composes.

IV. Tier-Tags

  • INCOSE NRM 2022 requirement-statement definition — π / α; μ / β under Cluster D as canonical articulation.
  • Three-function purpose-statement (foundation, integration-and-verification, communication) — π / α as cited; μ / β under Cluster A.
  • Five-category requirement taxonomy — π / α as cited; μ / β under Cluster A.
  • Verification planning during requirement generation — π / α; μ / β under Cluster I.
  • Traceability management — π / α as cited; μ / β under Cluster B reconciliation-rung.
  • Requirements management as lifecycle discipline — π / α; μ / β under Cluster F longitudinal-pulverization.

V. Residuals

R1 — The keeper-supplied article Requirements is structurally a redirect-or-disambiguation page on the SEBoK; the canonical content lives in System Requirements Definition. The corpus apparatus reads the SEBoK's editorial choice as keeper-side school discipline (one canonical page, multiple navigation pointers) and accepts the redirect without contesting it.

VI. Provisional Refinements

Cluster D anchor formalization. SE-039 D7 (anchor-article-per-cluster) candidate refinement reaches strong support for Cluster D anchored by SE-085. The INCOSE NRM 2022 requirement-statement definition is the canonical Cluster D articulation across the SEBoK distillations; "formal transformation of one or more needs or parent requirements into an agreed-to obligation" is precisely co-production at sub-rungs in NRM language. Worth formalizing.

Hierarchical Cluster A pair. SE-024 (Types of System Requirements) enumerates within macro-categories; SE-085 enumerates the macro-categories themselves. The pair is the canonical hierarchical-Cluster-A worked example. Cluster A admits hierarchical instances; the entracement should track this.

Cluster A reaches eleven instances. The cluster is now the densest by a wide margin; saturation suggests the universal-sibling lattice is the dominant structural form across the SEBoK surface.

VII. Cross-Links

Form documents. Doc 572 Appendix D (Cluster A, eleventh instance, hierarchical pair with SE-024), Doc 573 (Cluster D, anchor candidate), Doc 604 (Cluster B, agreement-as-composition), Doc 372 (Cluster H, functional specification discipline), Doc 270 / SE-022 (Cluster I, verification-planning at generation time), Doc 445 (Cluster F, lifecycle-pulverization).

Part-level reformulation. Part 3 SE and Management > System Concept Definition > System Requirements Definition.

Related distillations. SE-024 (Types of System Requirements, hierarchical Cluster A pair). SE-030 (Stakeholder Needs Definition, upstream co-production). SE-082 (Stakeholder Identification, upstream stakeholder source). SE-039 (Entracement, D7 anchor candidate).

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

Methodology refinement candidates. SE-039 D7 (anchor-article-per-cluster) — formalize Cluster D with SE-085 as anchor. Hierarchical-Cluster-A entracement entry.

Appendix: Originating Prompt

"Apply refinements; report back for next 40" / "Continue"

(SE-085 is one of the third-batch next-40 SEBoK distillations. Batch 1/5.)

Referenced Documents

More in framework