The repository was immaculate. Every requirement carried an identifier, an owner, a baseline, a linked design element and at least one test case, and the coverage report on the wall had been sitting at 100% for three straight sprints. Green all the way down. The release went out on schedule, the audit trail would have survived a regulator, and within about ten days the support queue made it clear the team had built the wrong thing for a group of customers nobody had thought to ask about.
Not one control caught it. There was nothing for them to catch. Every check in that system asked the same question in a slightly different accent, which is roughly "does the code match the recorded requirement?", and the code matched the recorded requirement beautifully. The requirement that decided the outcome was not in the tool, was never in the tool, and so it never had an identifier, never joined a baseline, never appeared in a coverage denominator and never failed anything.
I used to think this was a discipline problem. Somebody skipped a step, somebody rushed an interview, tighten the process. After 25 years in enterprise software delivery I no longer believe that, because I have watched it happen on projects where the process was genuinely excellent. It is a category problem. The tools were built to control requirements, and the failure was an absent requirement, and those are different jobs with different inputs. That distinction is what this article is about.
What is requirements management?
Requirements management is the discipline of controlling requirements once they exist as text. Storage. Identifiers, versioning, baselines, change control, approval workflow, review history, and traceability running from a requirement down through design, code, test and evidence. Its governing question is short: are the requirements we hold correct, current, agreed and accounted for?
It is a mature category, and I want to be clear that I mean that as praise rather than as a setup. Platforms like Jama Connect, IBM Engineering Requirements Management DOORS Next, Siemens Polarion and Visure do real engineering work that nothing else in the stack does. In regulated delivery they are not optional at all: ISO 26262 for automotive, IEC 62304 for medical device software and DO-178C for airborne systems all require you to demonstrate traceability, and demonstrating it in spreadsheets across a five-year programme is a losing game. Ask anyone who has tried.
The newer AI capabilities inside these platforms are genuinely useful too. Jama Connect Advisor analyses requirement text against INCOSE rules and EARS notation, scores it, drafts test cases from it and flags missing trace links, and Jama reports that its Advisor customers are increasing test coverage by five to ten times, cutting testing time in half and reducing escaped defects by 20 to 30%. Those are the vendor's own reported customer figures rather than independent research, so read them as such. Even taken entirely at face value, notice what every single one of them is measured against: requirement text that is already in the repository.
What is requirements intelligence?
Requirements intelligence is the discipline of producing the requirements a team does not yet have. It runs before the specification exists, on inputs that are not requirements: interview transcripts, support tickets, policy documents, the observed behaviour of the system people actually use, the exception somebody has been handling by hand since 2019. Its governing question is the uncomfortable one. What is missing, and what have we assumed without noticing that we assumed it?
Its output is not a tidy specification either, which surprises people. The output is candidate requirements, named assumptions, surfaced conflicts between two stakeholders who both believe they agree, and an explicit list of gaps. That material then flows into whatever management platform the team already owns, gets identifiers, and becomes the thing management is good at handling. Intelligence feeds management. It does not compete with it, and any vendor telling you it replaces your traceability layer is selling you a problem for later.
One honest caveat before the comparison. "Requirements intelligence" is a young term and the market is currently full of things wearing the label, including tools that analyse existing requirement text and call the analysis intelligence. That is a real capability with a different name, and we drew that line in detail in automated requirements analysis is not requirements intelligence. A linter grades the sentences you wrote. It has no access to the sentence you never wrote.
Where do the two actually differ?
They act on different populations at different times, and everything else about them follows from that one fact. Management acts on the set that exists. Intelligence acts on the set that does not. Same word in both names, completely different subject.
| Requirements management | Requirements intelligence | |
|---|---|---|
| Question it answers | Are the requirements we hold correct, current, agreed and traced? | Which requirements are we missing, and what did we assume? |
| When it runs | From the moment a requirement is written until the system retires | Before the first requirement is written, and again when the problem changes |
| Failure it prevents | Drift: an approved requirement that is stale, contradicted, untested or untraceable | Absence: a requirement that was never captured and therefore never checked |
| Inputs | Requirement text, change requests, design and test artifacts, review comments | Interviews, tickets, policies, observed work, system behaviour, exceptions |
| Outputs | Baselines, trace matrices, coverage and audit evidence | Candidate requirements, named assumptions, conflicts, an explicit gap list |
| Test for done | Every recorded requirement is traced and verified | The questions stop producing surprises |
Worth pausing on that last row, because it is where the two disciplines separate hardest. Management can define done precisely, and that precision is exactly why teams trust it: coverage is a computable number over a known denominator. Intelligence cannot. Its denominator is unknown by definition, which makes it harder to buy, harder to put on a dashboard, and unfortunately no less necessary.
Why does a perfectly managed requirement still fail?
Because management verifies conformance to the record, and completeness of the record is a different property that no downstream control measures. That is not a criticism of the tools. It is arithmetic: coverage is computed over the requirements that were recorded, so a repository containing 400 requirements when the problem needed 430 reports 100% coverage and is wrong by 30.
There is a second, subtler dependency running the other way, and a 2026 study puts numbers on it. Tobias Hey and Julian Frattini annotated 28 types of quality defect across 189 use case descriptions from two datasets, then ran five different automated traceability link recovery approaches over the same material to see how the defects moved performance. Their finding is more interesting than "bad requirements are bad." Some defects genuinely hurt recovery, and some improved it, so the best-performing tracing approach depends on the quality of the requirements you feed it.
Read that as a dependency rather than as a verdict on traceability. Automated tracing is useful and getting better fast. It is also, structurally, a downstream consumer of requirement text, which means its ceiling is set upstream by the quality and the completeness of what was written. And completeness is the half that no amount of downstream cleverness recovers, because there is no signal to process.
The research field itself splits the work this way, which I find quietly reassuring for anyone who suspects this is marketing taxonomy. A systematic review published in February 2026 in Software: Practice and Experience examined 238 articles on generative AI in requirements engineering from 2019 to 2025. Only 1.3% of them had reached production-level integration, and attention was spread unevenly across the phases: analysis at 30.0%, elicitation at 22.1%, management at 6.8%. Distinct phases. Distinct literature, distinct problems, and almost nothing yet in production.
Two things follow. If you are evaluating vendors this quarter, almost everything on offer is early, so ask which stage of the lifecycle a product operates on and what its inputs are, because that single answer tells you which of these two jobs it is doing. And a category sitting at 6.8% of the research is not unimportant. It is mature. Management got solved well. Absence did not.
Do you need both, and in what order?
Both, and intelligence first. Intelligence decides what enters the system. Management decides what happens to it for the next several years, including whether you can prove any of it to a regulator. Buy only management and you get a beautifully auditable record of an incomplete set, which is the failure at the top of this article. Buy only intelligence and you get good candidate requirements with nowhere durable to live, no change control, and no evidence trail when someone eventually asks how a decision was made.
Most teams I talk to already own the management half. That is the part with a budget line, a procurement process and a vendor shortlist, and rightly so. Fair enough. The discovery half is usually being done in two workshops and a shared document, by whoever has time, with no method and no coverage question anyone can state out loud. If you want a concrete way to see the shape of your own gap, requirements gap analysis is the practical entry point, the fuller definition sits in what is requirements intelligence, and our use cases show what the discovery half looks like on real team shapes.
On May 7, 2024, Sonos shipped a rebuilt mobile app alongside its Ace headphones. The feature inventory was known; this was not a team that had lost track of its own product. Several capabilities went out missing anyway, including local music library browsing, sleep timers, alarm reliability, and the ability to edit playlists and the play queue.
The reaction was not proportional to the feature list. It was proportional to who depended on those features, and that was the part nobody had established beforehand. On July 25, 2024, chief executive Patrick Spence published an apology and a dated roadmap, writing that fixing the app "has been and continues to be our number one priority." Music library configuration was scheduled for the July to September window. Alarm consistency landed in September. Edit mode for playlists and the queue was not scheduled until October, roughly five months after launch.
Read that roadmap as a discovery document. Each restored capability marks a requirement whose importance became knowable only after customers demonstrated it, in public, at some cost, and none of it needed better requirements management, because the feature inventory was already tracked. Sonos delayed two hardware launches to hold focus on the app, and Spence stepped down in January 2025.
What was never produced beforehand was the answer to one discovery question: for each capability in the old app, who relies on it, how often, and what do they do when it disappears? Cheap to ask in April. Expensive to answer in October.
Source: Sonos, "Update on the Sonos App from Patrick Spence," July 25, 2024, the company's own account of the launch, the missing functionality and the dated restoration schedule. Vendor-subject, labeled as such. Industry: consumer audio hardware and software.
One closing test for the shortlist, since this comparison usually happens with three tabs open. Do not ask which product has more artificial intelligence in it. Ask what the tool reads. If the answer is "the requirements in your repository," you are looking at requirements management, possibly excellent requirements management, and it will make what you already wrote better. If the answer is "your interviews, your tickets, your policies, your actual system behaviour," you are looking at something that can tell you what you did not write. Both are worth owning. Only one of them can safely be bought second.
Management improves what is in the system. Intelligence finds what never made it in.
Requirements management controls requirements once they exist as text: identifiers, baselines, change control, traceability, evidence. It is mature, it is necessary, and in regulated delivery it is mandatory. Requirements intelligence works one step earlier, on inputs that are not requirements yet, and produces the candidates, assumptions and conflicts that nobody had written down. The two are sequential, not competing.
Why the distinction has teeth: every management control is keyed to a requirement identifier, so a requirement that was never captured breaks no trace link, fails no test, and leaves coverage reporting at 100%. Feed your management platform better input, and it does its job on a set that is actually complete.
What are the most common questions about requirements intelligence versus requirements management?
