Requirements quality is infrastructure: the foundation that traceability, compliance, and AI workflows are built on. In most organizations, that layer hasn’t been defined. Four elements define it in practice, and they only work when they operate together.

Perspective
~5 min read | Featuring a 4-minute clip from Morgan & Martin

Most of the AI-and-requirements debate has been stuck on a single question: can a language model write a good requirement? In The Wrong Question, our CEO Jordan Kyriakidis argues we’re asking the wrong question. The harder, more useful question is whether your organization can see what’s actually in its engineering artifacts, and what’s missing from them.

When you take that question seriously, the conversation shifts quickly.  As one systems engineer in the standards development industry framed it, the need is for a rules-based quality check that isn’t probabilistic — a consistent measure, not a moving target. That isn’t a rejection of AI. It’s a recognition that AI only works when the layer beneath it is defined.

Once that becomes clear, requirements quality stops being about the shape of a sentence. It becomes infrastructure, the layer that traceability, verification, compliance, and AI all depend on. A one-line diagnostic from the field captures the constraint:  you can only automate what you can clearly define. In regulated engineering, that applies to governance and certifier defensibility just as much as it applies to automation.

So what does this look like in practice? Across industries, four elements show up consistently, and when one is missing, the others lose meaning.

01 Encoded standards

The INCOSE Guide for Writing Requirements and EARS patterns don’t change behavior when they live in a 200-page PDF that authors reference occasionally. They change behavior when they’re encoded, built into the evaluation layer every author works from, so every requirement is checked against them as it’s written. One aerospace team we work with described the gap directly: the standard exists, the training is done, but engineers still don’t consistently apply it in practice. That’s the difference between “we trained our engineers on EARS” and “the standard is encoded.” One asks engineers to carry the standard as a concept. The other makes the standard the standard — every draft, every team, every program. 

The same pattern shows up in organizations that encounter structured methods like EARS through tooling rather than training: the evaluation layer itself becomes the first point of exposure, because the standard is built into the system rather than stored alongside it.

02 Objective scoring

A score only means something if it returns the same answer across reviewers. If quality shifts with the reviewer’s skill, or the processes they’ve been exposed to, you don’t have a score — you have a mood ring. Objective scoring returns the same answer regardless of who’s evaluating or what pressure the program is under. That consistency is also what makes the signal scalable: with a shared, objective standard, you can compare quality across teams, across programs, and over time.

Human review still matters, but it becomes stronger when paired with a stable reference point. This is where organizations begin to treat requirements quality as a policy signal rather than a subjective judgment. One medical device manufacturer compared it to code coverage, where thresholds determine whether a program can progress. That kind of governance is only possible when the score is consistent.

03 Milestone readiness signals

Most gate reviews today come down to a judgment call, one drawn from tacit knowledge the organization can’t see, audit, or reproduce. A quantifiable readiness signal changes the question from “do these look ready?” to “are they ready, and here’s the evidence.” One defense engineering team described the goal as measuring quality at proposal, SRR, PDR, and CDR, so the signal travels with the program rather than appearing only at individual review points.

This matters most where readiness has an external audience. In regulated industries, the final reader of a requirements artifact isn’t the program engineer. It’s the certifier: the FDA investigator working against 21 CFR 820, the FAA Designated Engineering Representative signing off under DO-178C, the notified body auditing under IEC 62304, the EASA inspector reviewing compliance. Every artifact the system produces has to be defensible to someone with no prior context and no obligation to give the benefit of the doubt. In medical device development, requirements feed directly into the Design History File, which regulators examine under audit conditions. A readiness signal that persists across the lifecycle is what lets an organization defend its decisions without reconstructing the narrative under pressure.

04 Continuous evaluation

Quality checked at a milestone is quality checked too late. Continuous evaluation means feedback lives inside the authoring workflow itself, not in a review meeting two weeks later. The cost of a bad requirement compounds the longer it survives. Barry Boehm’s foundational work in Software Engineering Economics (1981), and decades of follow-on analysis captured in the INCOSE Systems Engineering Handbook, put the multiplier at roughly 5–10x by design, 20–70x by verification, and over 100x once a program is in operation. Every phase a defect flows into multiplies what it will cost to remediate. Continuous evaluation also surfaces the defects a gate review would never look for in the first place: missing rationale, orphaned stakeholder needs, and requirements with no verification path. A milestone checks what you know to look for. Continuous evaluation shows you what you missed.

One automotive team we work with described their reviewers spending most of their time correcting quality issues instead of evaluating engineering intent, which signals a systemic gap that can’t be fixed at review time. Embedding evaluation into the authoring workflow changes that dynamic, and compresses the feedback cycle for authors in the process.

Why the four together, not one at a time

These four elements don’t operate independently. Encoded standards without objective scoring produce rules that can be interpreted inconsistently. Objective scoring without milestone signals produces a number nobody acts on. Milestone signals without continuous evaluation produce gate-day surprises. Continuous evaluation without encoded standards produces noise, not guidance. The four don’t just stack. They bind. Together, they make quality visible at the program level, not just the document level.

One medical device organization we work with is running requirements quality as a corporate standard across fifteen operating units. Leadership can ask “where are we?” across every active program and get a consistent, comparable answer. That kind of clarity doesn’t come from isolated practices. It comes from a system that holds its shape across teams and time, and it isn’t possible without all four pillars in place.

With all four pillars in place, knowledge retention also becomes tangible. As senior engineers retire, the standard they carry in their heads leaves with them unless it’s been captured in a form the organization can reuse. Several teams we work with, across oil and gas, defense, and medical devices, described active efforts to encode expert judgment into structured artifacts and rule sets so new engineers inherit a working standard rather than an abstract one. As one systems engineering lead put it:

“A way to tell a new systems engineer what a good requirement looks like, I think, is essential.”

— Systems engineering lead, medical device customer

The four pillars, working together, are what make that inheritance possible.

This is what we mean by requirements quality as infrastructure. Not a writing aide. The foundation  AI guardrails are built on. As AI becomes more embedded in engineering workflows, requirements-level oversight becomes the first layer of organizational defense, and everything downstream (traceability, compliance, artifact quality, certifier defensibility) depends on getting this layer right.

Watch: Morgan & Martin on waht “good” actually looks like

A four-minute conversation covering the four pillars in their own words, and why, together, they change what requirements quality means at the program level.

If your team is already past the writing-aide question and trying to make this layer real, we’d like to hear what you’ve tried.