Requirements engineering has a mature framework: EARS notation, ISO/IEC/IEEE 29148, the INCOSE Guide for Writing Requirements, and sector-specific standards spanning aerospace (DO-178C, DO-254), automotive (ISO 26262), medical devices (IEC 62304, ISO 13485), industrial safety (IEC 61508), and US medical device regulation (21 CFR Part 820, now the FDA QMSR). That framework was built for a world of human writers, human reviewers, and human interpretation of standards. Generative AI has changed the environment in which the framework operates. AI governance regulation (ISO/IEC 42001, the EU AI Act, the NIST AI Risk Management Framework) has changed what certification authorities expect to see in an engineering record. The Requirements Operating Model exists to describe the architecture that regulated engineering now requires beneath its existing standards.

The Requirements Operating Model is written for engineering leaders and practitioners in regulated industries: aerospace (civil aviation, defense, space), medical devices, automotive, industrial automation, rail, and adjacent industries where engineering artifacts must be defensible to a certification or regulatory authority. Roles who will benefit most include chief engineers, systems engineers, requirements managers, heads of verification and validation, heads of compliance and certification, quality managers, and Configuration Authority (or equivalent) leads. The book applies whether your organization authors requirements for its own products, receives flow-down from a customer or prime contractor, issues specs to a supply chain, or delivers requirements services on behalf of clients. It is also relevant to engineering leaders adopting AI in requirements work, who need an architectural frame that accommodates AI-assisted generation without abandoning certifier-defensibility.

The Prologue's claim is that AI-assisted requirements work shifts the economics of quality. Well-formed requirements have always been cheaper to fix at authorship than at certification. AI-assisted generation lowers the cost of producing requirements but raises the risk of flawed requirements propagating through a program undetected, where the cost to correct them multiplies. An operating model that enforces governance at the point of admission (see Chapter 3) prevents that amplification. Chapter 5 will develop the empirical case for governance as an investment: industry research consistently shows requirements defects cost 5–10x more to fix at design, 20–70x at verification, and 100x or more in operation.

The shortest version to describe to your organization: bad requirements were already expensive. AI makes them cheap to produce and more expensive to fix downstream.

For engineering teams building their own products, whose work starts with internal user needs or a product concept and ends with design outputs verified against those requirements, the Requirements Operating Model provides the architecture beneath your existing design-control practice. Standards you already follow (29148, EARS, DO-178C, ISO 26262, IEC 62304, ISO 13485) define what a well-formed requirement looks like on the page. The operating model defines the environment in which those requirements exist. Each requirement is treated as an object with attributes, relationships, provenance, and states, carrying a resolved author, source, version, interpretation of applicable regulation, and linked verification method. When AI assists in authoring or refining requirements, the Separation Principle governs the interaction: the system that generates cannot be the system that evaluates. The substrate makes that separation enforceable. Chapter 1 lays out the architecture; Chapter 3 develops the admission discipline that carries through the whole model.

For engineering teams receiving flow-down requirements under contract, whose work must ultimately prove that every contracted requirement is verified and traceable in the delivered product, the Requirements Operating Model changes what you accept at the boundary. Chapter 3's Inputs Layer treats incoming requirements as external artifacts that must be ingested, classified, and made substrate-legible before downstream work can proceed. Three input classes (stakeholder/customer, regulatory/standards, legacy/inherited) each carry distinct provenance concerns. For a Tier 1 automotive supplier receiving OEM specifications, or an aerospace subcontractor receiving prime contractor requirements, the discipline is the same: nothing enters the record without provenance recorded and incompleteness represented. Ambiguity in an inbound requirement is recorded at ingestion as a property of the artifact rather than silently resolved, preserving the audit trail if the ambiguity later matters.

For engineering teams authoring specs, standards, or program requirements to issue down to a supply chain, the Requirements Operating Model raises the bar on what you send. Every requirement you originate should carry the metadata that would allow a recipient to admit it into their own operating model without translation: resolved authorship, source document reference, version identifier, effective date, applicability, and, where the requirement derives from a regulatory clause, the interpretation you have adopted for that clause. Chapter 3's substrate-legible form describes what this looks like structurally. In practice, this means moving away from unstructured PDF specifications toward structured, machine-readable requirement artifacts that carry their own governance context. Organizations that issue substrate-legible requirements make downstream verification, certification, and change management measurably cheaper for their supply chain, which becomes a source of contractual advantage.

For engineering consultancies delivering requirements services to clients, whose work starts with an incoming spec (often unstructured PDF or Word) and ends with a baselined deliverable packaged back to the client or their supply chain, the Requirements Operating Model provides a discipline that is tool-agnostic by design. The Knowledge Substrate is where the tool-independence lives: a structured representation of engineering knowledge that sits above any specific client system, whether Polarion, DOORS, Jama, Word, Excel, or another. Chapter 3's Inputs Layer describes the discipline for admitting unstructured client content: provenance recorded, incompleteness flagged, ambiguity surfaced rather than silently resolved. The result is a baselined deliverable that carries its own governance context, defensible regardless of which client tool it ultimately lives in.

The Inputs Layer is the first of the four process layers of the Requirements Operating Model. It admits external artifacts into the operating model and ensures each admitted artifact is complete enough, sourced enough, and classified enough to participate in the substrate's queries, evaluations, and audits. Three input classes pass through it: stakeholder and customer requirements, regulatory and standards inputs, and legacy and inherited requirements. Legacy requirements are the most operationally difficult, because they often carry knowledge their written form does not fully contain.

Chapter 3 names three strategies for handling legacy requirements when the knowledge behind them is incomplete. Reconstruction: the organization commits engineering effort to rebuild the missing knowledge and admits the reconstruction as a derived artifact. Quarantine: the requirement enters the substrate under a status that flags it as unfit for verification until reconstruction occurs. Explicit Acceptance: the requirement is admitted under a status that records what is known to be missing and what the consequences of that gap are.

Chapter 3's signature line: The quality of governance is determined by the quality of admission.

No. The Requirements Operating Model does not replace ISO/IEC/IEEE 29148, EARS, the INCOSE Guide for Writing Requirements, or the sector standards (DO-178C, ISO 26262, IEC 62304, IEC 61508, ISO 13485). Those standards operate at the level of artifact definition: what a good requirement looks like on the page, what processes should produce it, what documentation should accompany it. The Requirements Operating Model operates at the level of representation and execution context. It defines the environment in which requirements exist, the relationships between them, and the rules governing their admission, transformation, governance, and release.

Standards define what a well-formed requirement looks like on the page. The Knowledge Substrate defines the environment in which that requirement exists.

DO-178C, formally titled Software Considerations in Airborne Systems and Equipment Certification, is the software certification standard for civil aviation. Published by RTCA and EUROCAE in 2011, it is required by certification authorities worldwide including the FAA in the United States and EASA in the European Union. The standard defines five Design Assurance Levels (DAL A through E) based on the failure condition severity of the software: DAL A applies to catastrophic failure conditions such as loss of aircraft, DAL E to no safety impact. Each level specifies objectives for software planning, development, verification, configuration management, and quality assurance. The Requirements Operating Model treats DO-178C as one of the regulatory and standards inputs described in Chapter 3. The book's operating architecture sits beneath DO-178C rather than replacing it, describing the substrate on which DO-178C compliance is demonstrated.

ISO 26262, Road Vehicles — Functional Safety, is the international standard for functional safety of electrical and electronic systems in passenger vehicles. Published in its second edition in 2018, it derives from IEC 61508 and adapts its concepts to automotive context. The standard defines Automotive Safety Integrity Levels (ASIL A through D) based on hazard severity, exposure, and controllability. ISO 26262 covers the full development lifecycle including requirements, architecture, design, implementation, verification, validation, and production. It is one of the standards the Requirements Operating Model integrates with. The substrate provides the traceable representation of engineering knowledge that ISO 26262 assumes exists, without prescribing how that representation is structured. Chapter 3 describes how ISO 26262 requirements enter the operating model at ingestion.

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems, is the international standard on which most sector-specific functional safety standards are based, including ISO 26262 (automotive), IEC 62304 (medical device software), IEC 61511 (process industries), and EN 50128 (rail). Published in its second edition in 2010, it defines Safety Integrity Levels (SIL 1 through 4) and specifies requirements for hardware and software safety across the full lifecycle. IEC 61508 is often described as the parent standard for functional safety, meaning sector standards inherit its principles. The Requirements Operating Model treats IEC 61508 and its sector derivatives as regulatory and standards inputs (see Chapter 3), each ingested with the effective date, applicability, and governing interpretation the organization has adopted.

IEC 62304, Medical Device Software — Software Life Cycle Processes, is the international standard for medical device software development. Published in 2006 and amended in 2015, it defines software safety classes (Class A, B, C) based on the potential harm the software could cause. Class A software cannot contribute to hazardous situations; Class C software can cause death or serious injury. The standard specifies development processes for each class, including planning, requirements analysis, architectural design, implementation, integration, verification, and maintenance. IEC 62304 is closely paired with ISO 13485 (medical device quality management) and 21 CFR Part 820 (US FDA regulation, now transitioning to QMSR). The Requirements Operating Model treats IEC 62304 as one of the regulatory inputs described in Chapter 3.

ISO 13485, Medical Devices — Quality Management Systems — Requirements for Regulatory Purposes, is the international standard defining requirements for a quality management system specific to medical device organizations. Published in its third edition in 2016, it addresses design and development controls, risk management, supplier controls, production and process controls, and post-market surveillance. ISO 13485 is a regulatory expectation in nearly every major medical device market, including the EU (under MDR), the US (as of February 2, 2026, the FDA's Quality Management System Regulation incorporates ISO 13485:2016 by reference, replacing 21 CFR Part 820), Canada, Australia, Japan, and Brazil. The Requirements Operating Model treats ISO 13485 as a regulatory input governing how requirements-related processes are documented and audited.

21 CFR Part 820 is the US Food and Drug Administration's Quality System Regulation, which governed medical device quality management for US-marketed devices from 1996 through early 2026. On February 2, 2026, the FDA's Quality Management System Regulation (QMSR) came into effect, replacing 21 CFR Part 820 by incorporating ISO 13485:2016 by reference. This is one of the most significant regulatory changes in US medical device history. The QMSR harmonizes US medical device requirements with the international ISO 13485 standard, elevates design-input-to-output traceability into US law, and requires manufacturers to demonstrate compliance through documented quality management processes. Chapter 3 uses the QMSR as a working example of how regulatory context can shift while underlying standards remain stable, with the operating model recording both the standard citation and the interpretation at the time of admission.

ISO/IEC/IEEE 29148, Systems and Software Engineering — Life Cycle Processes — Requirements Engineering, is the international standard for requirements engineering process. Published in its 2018 edition, it defines processes and outcomes for stakeholder needs and requirements definition, system requirements definition, and software requirements definition. It also provides guidance on requirements characteristics (necessary, verifiable, unambiguous, complete) and requirements documentation formats. ISO/IEC/IEEE 29148 is the closest thing the requirements engineering discipline has to a canonical process standard. The Requirements Operating Model does not replace 29148. It describes the operating architecture beneath it: the substrate on which 29148 processes operate, and the four process layers that carry out the work 29148 specifies.

EARS (Easy Approach to Requirements Syntax) is a notation developed at Rolls-Royce in the mid-2000s to make natural-language requirements more structured, verifiable, and unambiguous. EARS defines five patterns for requirement statements: ubiquitous ("The system shall…"), event-driven ("When [trigger], the system shall…"), state-driven ("While [state], the system shall…"), unwanted-behavior ("If [unwanted condition], then the system shall…"), and optional feature ("Where [feature] is included, the system shall…"). EARS has been widely adopted in aerospace, defense, and automotive because it produces requirements that are easier to verify, trace, and interpret consistently. The Requirements Operating Model treats EARS as one of the standards defining what a well-formed requirement looks like on the page. The substrate defines the environment in which those requirements exist.

ISO/IEC 42001, Artificial Intelligence — Management System, is the international standard specifying requirements for establishing, implementing, maintaining, and improving an AI management system within an organization. Published in December 2023, it is the first certifiable standard for AI governance. ISO/IEC 42001 covers AI system lifecycle, risk management, impact assessment, transparency, and continuous improvement. Organizations pursuing certification demonstrate that their AI systems are governed by documented processes with defined accountabilities. For regulated engineering, ISO/IEC 42001 is a management-system layer that assumes the underlying engineering artifacts are governable. The Requirements Operating Model describes the substrate that makes ISO/IEC 42001 implementable. Chapter 6 (forthcoming) will develop this connection in full.

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) is the European Union's comprehensive regulation of AI systems, adopted in June 2024. The Act uses a risk-based approach: unacceptable-risk AI systems are prohibited; high-risk AI systems, including AI used in safety components of regulated products, face strict conformity assessment; limited-risk systems face transparency obligations; minimal-risk systems are unregulated. General Purpose AI provisions came into force August 2, 2025, requiring documentation, training-data summaries, and copyright policies from GPAI providers. In June 2026, the EU Council delayed Annex III high-risk AI obligations to December 2, 2027, while Article 50 transparency requirements remained on their original August 2, 2026 schedule. For regulated engineering, the EU AI Act affects both what AI can be used to author or evaluate requirements and what documentation must accompany AI-generated engineering content.

The NIST AI Risk Management Framework, published by the US National Institute of Standards and Technology in January 2023, is a voluntary framework guiding organizations in managing risks associated with AI systems. It defines four core functions: Govern, Map, Measure, and Manage. The framework is descriptive rather than prescriptive. It does not impose compliance obligations, but it is increasingly referenced in US federal AI policy, government procurement, and adjacent regulatory frameworks. Its companion document, the AI RMF Playbook, provides implementation guidance for each function. For regulated engineering organizations, the NIST AI RMF is often the entry point for AI governance discussions in the US context, in the way ISO/IEC 42001 anchors those discussions internationally.

DO-178C governs airborne software; ISO 26262 governs automotive electrical and electronic systems. Both derive from the discipline of functional safety, both use assurance-level tiering (DO-178C's DAL A–E, ISO 26262's ASIL A–D), and both address the full development lifecycle. The differences reflect the industries they serve. DO-178C emphasizes structural coverage analysis and Modified Condition/Decision Coverage (MC/DC) as verification requirements, reflecting the deterministic verification expectations of civil aviation certification. ISO 26262 places greater emphasis on hazard analysis and risk assessment (HARA) and safety concept documentation, reflecting the automotive industry's operational safety model. In requirements terms, DO-178C's higher DALs demand rigorous traceability from high-level requirements down to source code; ISO 26262's higher ASILs demand rigorous traceability from safety goals to safety requirements to software safety requirements. Both are inputs to the Requirements Operating Model, and the substrate carries the required traceability as first-class structural relationships.