Requirements Gathering and Engineering

Every system this series has discussed, the model in MBSE, the twin in digital twins, the thread connecting them, exists to satisfy something. That something starts as a requirement, and getting requirements right is the part of systems engineering with the longest paper trail of things going wrong when it's done badly.

Requirements come in a rough hierarchy. A stakeholder need describes a problem or goal in the stakeholder's own language, before anyone has committed to a specific solution. A stakeholder requirement translates that need into something closer to a testable statement about what the system must do for that stakeholder. A system requirement restates that in engineering terms precise enough to design against. A derived requirement falls out of a design decision made further down and has to trace back up to something that justified it. Miss a level, or lose the traceability between them, and you get exactly the kind of requirement nobody can explain the reason for.

INCOSE's Guide to Writing Requirements, now in its fourth version, defines fifteen characteristics of well-formed needs and requirements, nine that apply to an individual statement and six more that apply to the set as a whole, plus dozens of rules for achieving them (International Council on Systems Engineering, 2023). Five of them do most of the practical work. Necessary: tied to an actual stakeholder or system need, not something that sounded good in a meeting. Unambiguous: allowing exactly one interpretation, which rules out words like "fast," "user-friendly," and "adequate" outright. Verifiable: there has to be a concrete way, inspection, analysis, demonstration, or test, to prove it's been met. Singular: one requirement per statement, not three ideas joined by "and." Traceable: linked to whatever justified it above and whatever satisfies it below.

Writing requirements this precisely by hand, every time, doesn't scale, which is why a small set of sentence templates has become the industry's default answer. The Easy Approach to Requirements Syntax was developed in 2009 by Alistair Mavin and colleagues at Rolls-Royce while analyzing airworthiness regulations for a jet engine control system, work involving thousands of components and up to twenty different suppliers, where ambiguity in a requirement isn't an inconvenience, it's a certification risk (Mavin et al., 2009). EARS constrains a requirement to a fixed clause order, an optional precondition, an optional trigger, the system name, and the system's response, and organizes every requirement into one of five patterns.

The approach has since been adopted by Airbus, Bosch, Dyson, Honeywell, Intel, NASA, and Siemens, among others, a wider footprint than most requirements methodologies ever reach.

The most quoted statistic in this entire field traces back to one source, and that source's own methodology has been directly challenged. The Standish Group's 1994 CHAOS report reported a 16 percent project success rate and identified a clear statement of requirements as one of the top factors separating successful projects from failed ones, a finding repeated in every edition since and cited constantly across the industry. In 2010, two researchers at Vrije Universiteit Amsterdam applied Standish's own definitions to a dataset of over 5,000 real project forecasts and found the figures don't hold up: Standish's success and failure rates rest on a one-sided estimation-accuracy measure that rewards optimistic lowballing, average together numbers from organizations with very different and unknown biases, and are, in the authors' own words, meaningless for benchmarking (Eveleens & Verhoef, 2010).

None of that means requirements don't matter. The mechanism for why unclear requirements cause expensive downstream problems is straightforward and doesn't depend on Standish's numbers at all. It means the specific statistic used to prove it in nearly every slide deck on the subject is weaker evidence than its constant repetition suggests.

Getting to a good requirement starts before anyone writes a sentence. Interviews, workshops, prototyping, and direct observation of how people actually work are the standard tools, and ISO/IEC/IEEE 29148 formalizes the front end of this as a business or mission analysis process: define the problem or opportunity space before committing to a solution, so requirements trace back to a real need rather than a solution someone already had in mind (International Organization for Standardization et al., 2018).

The practical difficulty isn't a lack of technique. It's that stakeholders are often genuinely bad at describing what they want in the abstract, and reliably better at reacting to something concrete, a prototype, a mockup, a rough demo, than at answering "what do you need" cold. Good elicitation plans for that instead of fighting it.

The clearest current example of AI meeting requirements engineering is a commercial product, not a research prototype. Amazon's Kiro, an agentic coding IDE launched in July 2025, deliberately refuses to generate code from a raw prompt. It first turns the request into a formal specification, with acceptance criteria written in EARS notation, before design and implementation happen at all (Swaminathan & Singh, 2025). The reasoning given for the constraint is the same one systems engineers have used for over fifteen years: unconstrained natural language is where ambiguity gets introduced, and formal syntax is what catches it before it propagates.

This closes a loop the rest of this series has been circling. Two lessons ago, an AI agent reading and writing to a system model needed the model to be structured enough to act on reliably. Requirements written in EARS are exactly that kind of structure, applied to the very first artifact in the lifecycle instead of the model at the end of it.