Back to The Requirements Operating Model
Companion Resource
Working Glossary
Definitions for the terms used across the Requirements Operating Model book. Terms defined here have preferred usage; near-synonyms are called out and either differentiated or normalized. A living document, updated with each new chapter.
Core Concepts
- Requirements Operating Model
- The book's central proposal. A reference architecture for governed requirements engineering, consisting of five architectural elements: the Knowledge Substrate; four process layers (Inputs, Transformations, Governance, Outputs); the Separation Principle; the Configuration Authority function; and a maturity path. Chapter 1.
- Knowledge Substrate
- The structured and computable representation of engineering knowledge from which requirements, decisions, constraints, and evidence are derived. Not a database schema, a repository, or a software product. The foundation layer of the operating model. Chapter 2.
- Configuration Authority
- The function responsible for authoring and maintaining the operational policy that governs the substrate. Not a job title. An architectural responsibility that may be distributed across existing roles or assigned to a dedicated individual. Chapter 7.
- Separation Principle
- The principle that the function that generates a requirement and the function that evaluates it must be architecturally separate systems. Applies to human writers and reviewers, deterministic tooling, and AI-based systems. Chapter 2. Referenced in earlier QRA writing as the Scribe-and-Gavel principle; this book uses the literal formulation.
- Maturity Path
- The four-level model describing the states organizations occupy as they progress toward operating the full system. Levels are Document, Process, Measured, and Governed System. Chapter 8.
Architectural Terms
- Operating Model
- The description of how a system functions in practice: the components of the system, the responsibilities assigned to them, the information exchanged between them, and the principles governing their interaction. Applied to requirements engineering by this book.
- Operating Architecture
- The structural design that supports the operating model. Preferred term for the architecture the model provides.
- Engineering Architecture
- Deprecated. Where "engineering architecture" appears in the draft, normalize to "operating architecture" unless the broader engineering practice context is specifically intended.
- Operating Environment
- The scope within which the operating model functions. Includes the substrate, the process layers, the governing principle, the Configuration Authority, and the interactions among them.
- Engineering Environment
- The broader engineering practice context within which requirements engineering operates. Distinct from operating environment. Engineering environment is where engineering work happens in general; operating environment is the specific scope of the operating model.
- Reference Architecture
- A generic architectural pattern that organizations adapt to their circumstances. The Requirements Operating Model is described as a reference architecture for governed requirements engineering.
Substrate Properties
- Legibility
- The property of substrate artifacts by which they can be interpreted consistently by engineers, deterministic analysis tools, and AI-based systems. One of the three defining properties of the substrate.
- Structure
- The property of the substrate by which relationships between artifacts are explicit, typed, and queryable. Traceability, decomposition, verification linkage, dependency analysis, and change impact become computable properties. One of the three defining properties.
- Completeness (Visible Incompleteness)
- The property of the substrate by which it does not simply represent what is known but also exposes what is missing. Missing rationale, incomplete traceability, absent verification methods, and unresolved dependencies become visible properties of the engineering system itself. One of the three defining properties.
Artifact Terms
- Requirement
- A governed artifact with computable structure. Has a provenance, a rationale, a lifecycle state, downstream obligations, and semantic relationships to other engineering artifacts. Its representation to a human reader may take the form of a sentence in a document, but that sentence is only one representation of the underlying artifact.
- Governed Artifact
- An artifact managed within the operating model's substrate under active governance. Preferred usage when referring specifically to artifacts inside the substrate.
- Engineering Artifact
- The broader category of any artifact produced by engineering work. Includes governed artifacts but also artifacts that live outside the operating model's substrate. Use when the broader category is intended.
- Computable Structure
- The property of a requirement, or other governed artifact, that allows it to be reasoned about by automated systems. Preferred when emphasizing the substrate's support for computation.
- Structured Representation
- The form of the substrate's content. Near-synonymous with computable structure. Preferred when emphasizing the form of the content rather than the computational support that form provides.
Process Layer Terms
- Inputs Layer
- Layer 1 of the four process layers. Describes how artifacts enter the operating model, including classification by source and risk, and the transformation of arriving artifacts into substrate-legible form. Chapter 3.
- Transformations Layer
- Layer 2. Describes how requirements are authored, refined, and decomposed once inside the substrate. The layer at which generative activity concentrates. Chapter 4.
- Governance Layer
- Layer 3. Performs the principal architectural work of the operating model. Includes deterministic quality rules, AI-assisted evaluation within bounded responsibilities, milestone gates, audit records, and gap visibility. Chapter 5.
- Outputs Layer
- Layer 4. Describes what the system produces: requirements that are verified, traceable, verifiable, and certifier-defensible. Chapter 6.
Governance Terms
- Deterministic Rules
- Encoded rules that return consistent results regardless of reviewer or context. Foundation of the governance layer's evaluation capability.
- AI-Assisted Evaluation
- Probabilistic checks operating within explicitly bounded responsibilities. Complementary to deterministic rules. Not a replacement.
- Milestone Gates
- Points in program progression at which quality state must satisfy defined thresholds. Connect governance to program flow.
- Audit Records
- The record of judgment events preserved across the lifecycle. Support external audit and internal review.
- Gap Visibility
- The capacity to expose what is missing from the substrate before it propagates downstream. A property of the substrate; a capability of the governance layer.
- Governed System
- An operating model instance in which the substrate, process layers, and governance are integrated and functioning together. The name of the fourth level of the maturity path.
Outcome Terms
- Certifier-Defensibility
- The output state in which artifacts can be handed to an external reviewer with no prior context and survive scrutiny against the applicable standard. The cumulative consequence of every layer of the operating model behaving correctly, not a property added at the end.
Maturity Terms
- Level 1 — Document
- Requirements exist as documents and are reviewed manually. No substrate.
- Level 2 — Process
- A requirements methodology has been adopted and peer review is in place. Partial substrate.
- Level 3 — Measured
- Quality scoring exists at defined milestones. Substrate not yet integrated across the lifecycle.
- Level 4 — Governed System
- The substrate is computable, the process layers are integrated, deterministic and AI-assisted governance operate together within a defined envelope, and the outputs are certifier-defensible by default.
External Standards and Frameworks (Reference)
- EARS
- Easy Approach to Requirements Syntax. Published 2009 by Mavin, Wilkinson, Harwood, and Novak in the proceedings of RE'09. Widely adopted authoring template in regulated industries.
- ISO/IEC/IEEE 29148
- International standard for the engineering of requirements. First published 2011, revised 2018.
- INCOSE Guide to Writing Requirements
- INCOSE's canonical reference on well-formed requirements. Editions V1 (2009), V2 (2012), V3 (2017), V4 (2023). Contains 42 rules organized in 14 categories.
- DO-178C
- RTCA standard for software considerations in airborne systems and equipment certification. Published 2011, replacing DO-178B (1992).
- DO-254
- RTCA standard for design assurance guidance for airborne electronic hardware.
- ISO 26262
- International standard for automotive functional safety. First edition 2011, second edition 2018.
- IEC 61508
- International standard for functional safety of electrical, electronic, and programmable electronic safety-related systems. First published 1998.
- IEC 62304
- International standard for medical device software lifecycle processes. Published 2006.
- ISO 13485
- International standard for medical device quality management systems.
- 21 CFR Part 820
- U.S. Food and Drug Administration Quality System Regulation for medical devices. Current form since 1996.
- ISO/IEC 42001
- International standard for artificial intelligence management systems. Published 2023.
- EU AI Act
- Regulation (EU) 2024/1689. Passed 2024, phased implementation through 2027.
- NIST AI Risk Management Framework
- NIST AI 100-1, January 2023. Organized around four functions: Govern, Map, Measure, Manage.