By the early 2010s, requirements engineering had reached a stable form. International standards described the properties of requirements.1 Authoring guidance described how they should be written.2

Requirements management platforms provided the infrastructure for storing and tracing them. Sector-specific standards defined the conditions requirements had to satisfy in aerospace, automotive, medical devices, industrial systems, defense, rail, and energy.3 The framework was mature, and it provided a common basis on which regulated programs could produce certifiable engineering artifacts.

The environment in which the framework operated has since changed. Generative AI now produces engineering artifacts at a pace and volume that human review at the framework's traditional rhythm cannot absorb. New regulatory frameworks, including ISO/IEC 42001,4 the EU AI Act,5 and the NIST AI Risk Management Framework,6 have introduced obligations that presume automated systems and human systems both participate in the engineering work. The pace at which engineering practices are advancing has compressed the time available for organizations to adapt.

Under these conditions, the relationships and judgments that once existed primarily as human knowledge must become explicit engineering artifacts that automated systems can read, evaluate, and operate upon. That transition requires an operating architecture. This book calls it the Requirements Operating Model.

What an Operating Model Is

An operating model describes how a system functions in practice. It defines the components of the system, the responsibilities assigned to them, the information exchanged between them, and the principles governing their interaction. The Requirements Operating Model does not redefine requirements engineering. It describes how the discipline's existing practices operate together under the engineering conditions of the mid-2020s.

The Central Assertion

The operating model begins from a single assertion.

A requirement is a governed artifact with computable structure.

It 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.

Everything that follows in the operating model is derived from this assertion. If a requirement is a governed artifact with computable structure, then the environment that holds it must itself be structured to support computation. The processes that act upon requirements must operate on governed artifacts rather than isolated documents. The principles governing those processes must accommodate both human and automated participants. The organization operating the environment must make its engineering policy explicit rather than relying on tacit knowledge. The architecture presented throughout this book follows from these consequences.

The Architecture

The Requirements Operating Model is a reference architecture for governed requirements engineering.

It consists of five architectural elements. At its foundation is the Knowledge Substrate, the structured environment in which requirements exist as governed artifacts. Above the substrate are four process layers that describe how engineering information enters the system, is transformed, is governed, and is ultimately released as engineering outputs. A governing principle defines the separation between generation and evaluation. A Configuration Authority maintains the operational policy that governs the environment. A maturity model describes progressive stages through which organizations adopt the architecture.

Together these elements describe how a governed requirements system operates under the engineering conditions of the mid-2020s. They do not displace existing standards or methods. They provide the operating architecture within which those standards are applied.

The Knowledge Substrate

The substrate is the layer beneath the four process layers. It is not a database schema. It is not a tool. It is the structured and computable representation of the engineering knowledge that requirements, decisions, constraints, and evidence are derived from. The substrate contains the requirements themselves and the source clauses they trace to, the rationale that produced them, the verification methods that satisfy them, the reviewers that approved them, the change events that modified them, and the downstream artifacts in the lifecycle that depend on them. Every layer above the substrate reads from it and writes to it.

The substrate has three defining properties. It is legible: every artifact within it is expressed in a form that a human reviewer, a deterministic rules engine, and an AI-based system can all read the same way. It is structured: artifacts carry explicit and typed relationships to each other, so that traceability, decomposition, verification linkage, and change dependence become queryable properties rather than manual reconstructions. And it is complete in a specific and unusual sense. The substrate makes its own gaps visible. A governed system does not only check what is present. It surfaces what is absent. Chapter 2 describes each of these properties in full detail, along with the operating principle that governs the substrate and the architectural conditions under which it functions in a working engineering environment.

The Four Process Layers

Above the substrate are the four process layers. Each performs a distinct set of operations on the substrate.

The Inputs layer describes how artifacts enter the system. Requirements arriving from customer specifications, regulatory citations, standards references, or inherited programs are classified according to their source and risk, and are made substrate-legible before they can be operated on by the layers above. What passes through Inputs sets the ceiling for what the rest of the system can produce.

The Transformations layer describes how requirements are shaped once inside the substrate. New requirements are authored. Existing requirements are refined. High-level requirements are decomposed into the derived and low-level requirements that guide design. This is the layer at which generative activity concentrates, and the layer at which AI-based generation is most active in current engineering environments. The relationship between transformation and evaluation is where much of the operating model's architectural work happens, and where the principles introduced later apply most consequentially.

The Governance layer performs the principal architectural work of the operating model. It receives dedicated treatment in the section that follows.

The Outputs layer describes what the system produces. A governed requirements system produces requirements that are verified against quality standards, traceable to their sources, verifiable against defined methods, and defensible to the certification authorities the industry operates under. Outputs inherit the properties of the substrate they are derived from. Certifier-defensibility is not a property added at the end of the process. It is the cumulative consequence of every layer of the operating model behaving correctly.

Chapters 3 through 6 describe the four process layers in the order they appear here.

The Governance Layer

The Governance layer performs the principal architectural work of the operating model.

Deterministic quality rules evaluate governed artifacts against defined policy. AI-assisted evaluation operates within explicitly bounded responsibilities. Milestone gates connect engineering quality to program progression. Audit records preserve the evidence supporting engineering decisions. The substrate continuously exposes incomplete, inconsistent, or conflicting information before those conditions propagate into downstream activities.

This changes how governance is represented within the operating model.

Under a document-oriented view, governance consists primarily of reviews performed at defined points within a project lifecycle. Under the operating model, governance is represented as a continuous computational capability operating across the engineering environment. Quality is no longer established only through periodic human inspection. It is represented as an observable property of the governed system itself.

Under this representation, the role of reviewers, the purpose of quality gates, the meaning of audit evidence, and what certification authorities evaluate when assessing engineering programs are each reframed. Chapter 5 examines these implications in detail.

Two Views of a Requirement

The Separation Principle

The model is governed by the Separation Principle. The function that generates a requirement and the function that evaluates it must be architecturally separate systems. The principle applies to human writers and reviewers, to deterministic tooling, and to AI-based generation and evaluation. Chapter 2 develops the principle in full detail, including its antecedents in adjacent fields and the specific failure modes that appear when generation and evaluation are collapsed into a single system.

Configuration Authority

Increasing automation changes the amount of engineering policy that must be represented explicitly.

Human teams routinely rely on tacit knowledge, shared conventions, and informal interpretation. Automated systems cannot. Policies governing generation, evaluation, traceability, approval, quality thresholds, certification obligations, and acceptable AI participation must therefore exist as governed engineering artifacts subject to version control, review, and organizational governance.

The necessity of this function is architectural rather than organizational. Operational policy in a computable engineering system takes the form of executable structure. It cannot remain implicit in tool configuration or team practice, because automated systems have no mechanism to interpret implicit behavior. This policy must be maintained as a distinct class of artifact. The responsibility for maintaining it is architecturally separable from the engineering work that operates against it, because the artifact class it produces is distinct from the artifacts engineering work produces.

The operating model refers to responsibility for maintaining this operational policy as the Configuration Authority.

Organizations may distribute this responsibility across multiple existing positions or assign it to a dedicated individual. Systems engineers, requirements managers, quality leads, process owners, and tool administrators frequently perform portions of this responsibility today. The operating model identifies these activities as a single architectural concern regardless of where they reside organizationally.

The defining responsibility of the Configuration Authority is not participation in engineering work. It is configuration of the engineering environment within which that work occurs.

The Configuration Authority establishes and maintains the policies governing artifact structure, mandatory quality rules, AI usage boundaries, governance thresholds, milestone criteria, traceability expectations, certification mappings, and other operational constraints. These policies constitute governed artifacts in their own right and define how the engineering system behaves.

Chapter 7 examines the Configuration Authority in detail, including organizational patterns through which this responsibility can be implemented.

The Maturity Path

The model describes four states organizations occupy as they progress toward operating the full system. At Level One, requirements exist as documents and are reviewed manually. At Level Two, a requirements methodology has been adopted and peer review is in place. At Level Three, quality scoring exists at defined milestones. At Level Four, 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. Chapter 8 describes the levels in detail and provides the diagnostic by which a reader can locate their organization on the path.

The Model and the Existing Framework

The Requirements Operating Model complements rather than displaces the existing requirements engineering framework.

EARS, ISO/IEC/IEEE 29148, the INCOSE Guide to Writing Requirements, and sector-specific certification standards continue to define the characteristics of well-formed requirements and the practices used to produce them.

The operating model addresses a different question. It describes the operating architecture within which those requirements are created, governed, evaluated, and sustained throughout their lifecycle.

The two therefore operate at different levels of abstraction. Existing standards describe the properties of the engineering artifact. The Requirements Operating Model describes the architecture of the engineering system to which that artifact belongs.

The relationship with AI governance frameworks follows the same pattern. ISO/IEC 42001, the EU AI Act, and the NIST AI Risk Management Framework define organizational obligations for governing artificial intelligence. The Requirements Operating Model describes the engineering architecture required to implement those obligations within regulated engineering environments. The governance frameworks specify what must be governed. The operating model specifies the engineering environment through which that governance is operationalized.

The chapters that follow examine each element of the model in turn. Chapter 2 establishes the Knowledge Substrate and the Separation Principle that governs it. Chapters 3 through 6 walk the four process layers. Chapter 7 describes the Configuration Authority. Chapter 8 presents the maturity path. Chapter 9 returns to the question of AI's role in the system and resolves it against the architecture the prior chapters establish. An appendix on integration across heterogeneous toolchains is provided for organizations whose engineering environments span multiple platforms.

The next chapter begins with the foundation. If a requirement is a governed artifact with computable structure, then the environment that holds it must be structured to enable computation over it. That structured environment is what Chapter 2 names and describes: the Knowledge Substrate.