The report was green. Ninety-four requirements, four weak-word warnings and one flagged duplicate, and we cleared the entire list in about twenty minutes on a Tuesday afternoon before handing the package to the build team with a note that said, more or less, this one is clean. Six weeks later a support ticket arrived that nobody could route. A customer had moved from Ontario to Quebec partway through a subscription, the sales tax treatment was supposed to change at the next billing cycle, and not one requirement in that clean package had ever said what "next cycle" meant for somebody who had already been invoiced. Not ambiguous. Absent.
Let me be fair to the tool, because I have watched people blame the wrong thing for this. It read ninety-four requirements and it graded ninety-four requirements. There was never a ninety-fifth for it to read. A requirements analyzer that invented the requirements you forgot would be a considerably worse product than one that stays quiet, so the silence was correct behaviour, and reading that silence as a completeness signal was my error rather than the vendor's. Mine. Not theirs.
That distinction sounds pedantic until it costs you a quarter. Automated requirements analysis is a real category doing real work: tools like ScopeMaster parse what you wrote, score it for ambiguity and testability, flag duplicates and size the functional content, faster and far more consistently than a human reviewer on day three of a review. I recommend that layer. What I am arguing against is not a product but a category error: the belief that a clean analysis report says anything at all about the requirements that are not in it.
What does automated requirements analysis actually do?
It parses the requirements you already wrote and grades them against linguistic and structural rules. Weak words. Passive constructions, pronouns with no clear antecedent, acceptance criteria that no test could ever falsify, two requirements saying the same thing in different vocabulary, a functional size that bears no resemblance to the estimate somebody put in the plan. This is unglamorous, high-value work, and the honest summary is that machines are better at it than we are, because consistency at 4pm is a machine property and not a human one.
The performance numbers are also better than the skeptics assume, though not as good as a dashboard implies. Max Unterbusch and Andreas Vogelsang at the University of Duisburg-Essen tested defect prediction against the QuRE benchmark in January 2026, using 1,266 Mercedes-Benz requirements annotated for weak wording by up to three company-internal testers. Their best configuration reached 0.686 precision at 0.967 recall. Read that slowly. Roughly three flags in ten were not actually defects at all, which the authors explain rather than bury: basic smell rules over-approximate on purpose, because in practice most of what they match turns out to be contextually harmless.
Hold both facts together, because the argument depends on it. The layer works. And every check it runs, without a single exception across ambiguity, testability, duplication and functional sizing, takes as its input a sentence that somebody has already typed.
What can a requirements linter never catch?
The requirement that was never written. That is the entire answer, and it is not a limitation anyone is going to engineer away with a better model, because it is a property of the input rather than the algorithm. A linter cannot flag the exception nobody documented, the stakeholder nobody interviewed, the regulatory condition everyone assumed was somebody else's problem, or the state your system enters twice a year during reconciliation. No sentence announces its own absence. Nothing to score.
I want to resist overstating this, because the honest version is more interesting than the absolutist one. Some absences do leave a trace: a requirement referencing a status that never gets defined, a glossary term used once and never bound, an acceptance criterion whose precondition appears nowhere. Good analyzers catch those. What none of them can catch is the clean, self-consistent, well-formed specification that simply stops early, which is the failure mode that survives review precisely because it looks finished.
On July 19, 2024, CrowdStrike shipped Channel File 291. An automated Content Validator checked it. It passed. Millions of Windows machines then failed to boot, in what Microsoft later put at roughly 8.5 million devices, while airlines, hospitals and banks spent the weekend recovering them by hand.
The mechanism is the part worth sitting with. CrowdStrike's own root cause analysis describes a template type that defined 21 input parameter fields, while the code invoking it supplied only 20. The validator checked the file against 21. The interpreter received 20. When a template instance finally stopped using a wildcard and actually reached for that twenty-first value, there was nothing there, and an out-of-bounds read took the machine straight down.
Here is what makes it a requirements story rather than a memory-safety story. The mismatch had been latent through build validation, stress testing and several successful field deployments, because earlier instances used wildcard matching on that twenty-first field and never actually reached for a value. The validation ran. The validation passed. What was never stated anywhere was the contract itself: that the number of fields the template declares must equal the number the caller provides. Nobody wrote that requirement, so nothing tested it, so every green check that weekend was a true statement about the wrong question.
Sources: CrowdStrike, External Technical Root Cause Analysis, Channel File 291, published August 6, 2024, for the mechanism (vendor analysis of its own incident, labelled as such), and Microsoft, "Helping our customers through the CrowdStrike outage", July 20, 2024, for the 8.5 million device estimate. Industry: endpoint security software.
Why is a clean analysis report not a complete requirement set?
Because quality and coverage are different measurements, and only one of them was taken. A clean report is a precise and trustworthy statement carrying a scope that almost nobody reads: the requirements present in this document are well formed. Scope, not coverage. We know how to say this in every other engineering context, and we say it constantly: one hundred percent of the tests passing tells you nothing whatsoever about the behaviour nobody thought to write a test for.
The Infineon numbers make the point uncomfortably concrete. What a linter measures best is the linguistic surface of a requirement, and in that dataset the surface correlated only weakly with how hard the requirement actually turned out to be to refine. Contextual incompleteness correlated more than twice as strongly. Wordiness barely mattered. The tooling is aimed at the variable that matters least, not because anyone designed it badly, but because it is the only variable a document exposes.
There is a psychological cost on top of the measurement one, and I suspect it is the larger of the two. Green ends conversations. The review that would have surfaced that tax edge case never happens, because the artifact came back clean and the meeting invite quietly gets declined, and confidence is exactly the wrong output to hand a team whose real risk is invisible to the instrument that just reassured them.
How does requirements intelligence produce what analysis only checks?
By working one layer earlier, on the material that existed before the specification did. Interview transcripts. Ticket threads, the policy document nobody has opened since the last audit, the argument in a channel that got settled by whoever typed last, the constraint that lives in one architect's head. Analysis takes a document as input and returns a grade. Intelligence takes the mess as input and returns the questions that should have been asked, which is a different job entirely and produces the artifact the analyzer will later validate.
Mechanically, finding an absence means comparing against something, since absence is invisible on its own. Three methods help. Run an explicit coverage checklist of context categories against every requirement, the way the Infineon researchers did, and the gaps stop being invisible and start being a list. Put reviewers with genuinely different jobs on the same source material, which is the argument we made for multi-agent AI in business analysis and the reason those agents have to be allowed to disagree. Then treat every unresolved thread in a transcript as an open question rather than a settled one.
None of that replaces the analyzer, and I would be selling something dishonest if I implied otherwise. Run both. Discovery first, so the set is right, then analysis, so the set is well written, which is the sequence requirements intelligence describes and the sequence most teams currently run in reverse or with the first half missing. The failure I opened this piece with was not caused by a bad tool. It was caused by a good tool answering a question I had not asked it.
Analysis grades the page. Intelligence decides what belongs on it.
Automated requirements analysis parses, lints and scores the requirements a team already wrote, and it is genuinely useful: ambiguity detection, testability, duplicates, functional sizing, all faster and more consistently than a human reviewer. Every one of those checks needs an existing sentence as input. It cannot flag the requirement that was never written. Absence leaves no trace.
Not a rounding error. Across the 3,688 Infineon stakeholder requirements approved for refinement, operational context was missing from 81.5% of them, and contextual incompleteness predicted refinement difficulty more than twice as strongly as wordiness, which is the thing linters measure best. Treat a clean report as one gate passed rather than a completeness certificate. Run discovery first so the set is right, then analysis so the set is well written.
What are the most common questions about automated requirements analysis?
