There is a genre of article that shows up every July, and on the seventh of this one TheNextWeb published a good example of it: eight tools, compared properly, under a headline saying these were the ones leading the AI requirements shift in 2026. Jama Connect first. Then Valispace, IBM DOORS Next, Codebeamer, Polarion, Visure Solutions, Modern Requirements, Innoslate. I read it twice, once for the rankings and once for something that took a second pass to notice.
Nothing in it is wrong. The comparison is careful, the criteria are sensible, and the buyer caution near the end is better than most: the piece warns that nearly every vendor now claims advanced AI in the same "intelligent, smart, AI-powered" register, and tells you to separate real embedded analysis from a chatbot bolted onto a user interface. Good advice. What stopped me was narrower, and it is not a complaint about the article so much as about the category it describes: not one of those eight entries, scored on any of those criteria, answers the question of which tool finds the requirement that nobody ever wrote down.
What did Jama and Visure actually ship?
Two Model Context Protocol servers, a month apart, from two of the most established names in the category. On 4 May 2026 Jama Software announced Jama Connect MCP, positioning Jama Connect as the first engineering management software to deliver an MCP server, so that engineers working in Claude, Codex, Cursor or Copilot can reach governed product data without leaving the environment they already work in. A month later, on 4 June 2026, Visure Solutions introduced Engineering Intelligence, built on the VISURE MCP Server, letting agents interact with requirements, risks, verification evidence and compliance data inside existing lifecycle processes. Both are real. Both are useful.
And both companies are precise about what they built, which matters, because the sloppiness that follows is not theirs. Jama scopes its governance claim to enforcing "existing permissions, lifecycle workflows, and audit requirements" and to exposing a product graph of explicit semantic relationships. Visure's CTO Fernando Valera, in the Engineering Intelligence announcement, frames the problem as AI lacking context, and says the answer is giving agents access to engineering lifecycle information rather than leaving them to operate in isolation. Read them slowly. Neither of them promises to find anything that is not already there, because neither product does, and the vendors do not pretend otherwise.
So this is not a takedown. I have spent 25 years in enterprise software delivery and a fair amount of it inside tools from this category, and connecting an agent to a requirements repository without blowing a hole in the permission model is genuinely hard work that somebody had to do. It is done now. The interesting question is what people will assume it solved.
Is an MCP server the same thing as requirements intelligence?
No. An MCP server is a governed connection to data that already exists, and requirements intelligence is a method for producing data that does not exist yet, which is roughly the difference between a very good library card and going out to do the fieldwork. Both matter. They are not substitutes, and the reason the confusion spreads is that both get described with the same three words: context, governance, intelligence.
Here is the version I keep coming back to. A Model Context Protocol server decides who may read which requirement, logs that they read it, and hands back exactly what the repository holds. Perfect fidelity. If the operating condition was never entered by anyone, the query returns nothing, the traceability matrix flags nothing, and the agent answers anyway in fluent, confident prose, because an absence in the source data does not arrive labelled as an absence. We covered the retrieval half of this in an earlier piece on governing agentic access to requirements, and the tacit-knowledge half in the one on context layers and tribal knowledge. This piece is about the third thing, which is what happens to a market when the word "intelligence" gets attached to the pipe.
What does a 2026 requirements tool evaluation actually measure?
Text that is already in the tool. Every criterion, without exception, and once you see it on a scorecard you cannot unsee it. The TheNextWeb roundup compares its eight platforms across natural language quality analysis, automated test generation, risk scoring, live traceability, compliance framework support, ecosystem integration and enterprise scalability, which is a fair and fairly complete list of what these products do. Seven dimensions. A buyer could run that evaluation rigorously, score eight vendors, pick a defensible winner, and never once ask whether the requirements being scored were the right set.
8 tools · 7 criteria · 0
Eight platforms compared across seven evaluation criteria in TheNextWeb's July 2026 roundup of AI requirements management software: quality analysis, test generation, risk scoring, live traceability, compliance support, ecosystem integration and scalability. Not one of the seven measures whether a requirement is missing. Each one takes the contents of the repository as its input, which means a tool can score perfectly on all seven while the set it is scoring has a hole in it.
Source: TheNextWeb, "The best AI requirements management software: 8 tools leading the shift in 2026", published 7 July 2026. Tools covered: Jama Connect, Valispace, IBM DOORS Next, Codebeamer, Polarion, Visure Solutions, Modern Requirements, Innoslate. Industry: requirements and engineering management software. The criteria list is the article's own; the count of criteria that measure absence is our reading of it, and you are welcome to check.
I want to be careful here, because there is a cheap version of this argument and I do not want to make it. The cheap version says traceability is theatre. It is not. In regulated engineering it is a legal obligation, it catches real defects every day, and the teams who maintain it are doing serious work under real audit pressure. The honest version is narrower and harder to dismiss: a traceability matrix proves internal consistency between requirements, design outputs and verification results, and internal consistency is simply a different property from completeness. A flawless chain of custody for a set that is missing three items is still flawless. It is also still missing three items.
What is the difference between accessing requirements and discovering them?
Access answers "what do we have written down about this?" Discovery answers a question that sounds similar and is not: "what is true about this that nobody has written down?" Two different jobs. Genuinely different. The first is a retrieval problem with a correct answer sitting in a database. The second is an interrogation problem, closer to investigative work than to querying, where the answer exists only in somebody's working memory and has to be dragged out by asking the question that makes them say "well, obviously, except when..."
That word "obviously" is the tell. Every time. It is the sound a tacit requirement makes on its way out of somebody's mouth, and no repository query will ever produce it, because the reason it was never written down is precisely that it seemed too obvious to be worth writing.
From the field
Medical devices are where this gets tested hardest. Traceability there is not a best practice, it is a legal obligation with auditors attached, which is exactly why I went hunting in that industry instead of in software, half expecting to come back empty. I did not. Smiths Medical found that its CADD-Solis and CADD-Solis VIP ambulatory infusion pumps could raise a false Upstream Occlusion alarm, locking the pump, when no blockage existed at all. Now read the trigger conditions, because the whole argument is sitting in them. Four things have to be true at once. Four: a CADD administration set is used rather than a medication cassette reservoir, and the Upstream Occlusion Alarm is enabled, and neither Keep Vein Open nor Continuous rate is programmed, and priming or infusing happens shortly after attaching the set while the next infusion does not occur for roughly an hour or more. Every one of those is an ordinary, documented, individually correct clinical choice. The combination was the requirement. Nobody wrote it down. No traceability matrix could have flagged it, because there was no entry to trace. And the company behaved well once it knew, which matters to say out loud: it issued an Urgent Medical Device Notification dated 10 April (the FDA notice does not state the year) with a simple mitigation (remove the set, confirm there is no real occlusion, re-attach, restart), and to the date of the FDA notice no serious injuries or deaths had been reported.
Source: U.S. Food and Drug Administration, "Infusion Pump Recall: False Alarm Issue with Infusion Pump from Smiths Medical", published 5 June 2025; FDA identifies it as the most serious type of recall, and the four trigger conditions are quoted from the notice. Industry: medical device software, an industry with mandated end-to-end requirements traceability, cited here because the traceability obligation is what makes the case worth reading and not because the failure mode is unique to healthcare.
Four ordinary settings, each one correct. A nurse on a Tuesday afternoon picks them without thinking twice and is right not to think twice, because nothing in the four is wrong and nothing in the four is unusual. The trouble is that they can show up together. Somebody had to think to write that sentence down, and nobody did, which is duller than the failure stories people tell at conferences and far more common than them. Ask the repository. You get back a confident nothing.
Why does "intelligence" keep getting attached to governance features?
Because governance is measurable and discovery is not, at least not yet. You can demo a permission model. You can show an audit log filling up in real time, put a traceability percentage on a slide, and let a buyer verify all of it inside a thirty-minute call, whereas "we found the requirement you did not know was missing" is almost impossible to demonstrate to somebody who, by definition, does not know it is missing. So the word migrates to the thing that can be shown. Naturally. I would probably do the same in their position, and I want to be fair about it: Visure's use of "Engineering Intelligence" describes a real capability set, and Jama's MCP announcement makes no intelligence claim at all.
The cost lands on the buyer. Not the vendor. If your evaluation scorecard inherits the market's vocabulary, you will end up scoring seven dimensions of access quality and calling the total "intelligence", then discovering eighteen months later that the requirement that sank the release was never in any of the systems you so carefully compared. I laid out the underlying distinction in requirements intelligence versus requirements management, and the definition itself in what requirements intelligence actually means. This is the same boundary showing up one layer higher, in the procurement conversation rather than the product one.
So add a column. One is enough, and it costs nothing to ask, because every vendor on your shortlist already has an answer to it whether or not they have ever said it out loud: what does this tool do about a requirement that exists nowhere in it? Then run something real through the demo, in three steps.
- Take a defect your own team shipped last year, and find the sentence that was never written.
- Ask each vendor which feature would have surfaced that sentence, and at what point in the process.
- Note which of them answers honestly that their product begins only after that sentence exists.
That third answer is the useful one. Genuinely useful. A vendor who gives it is being straight with you, and it tells you precisely what you still have to buy, build or staff, which is the actual output you wanted from the evaluation in the first place.
That gap is the work Specira does: five specialist agents interrogate interviews, tickets and policies from deliberately different expert angles, and a Red Team Critic attacks what they produce, hunting for the combination nobody enumerated. Before the tool. It runs before the requirement reaches Jama or Visure or DOORS, and then you put what it finds into whichever of those tools you already bought. I build it, so weigh the pitch accordingly and judge the mechanism instead.
Key takeaway
Jama and Visure both shipped serious infrastructure in 2026, and both describe it accurately: a governed, audited connection between AI agents and the requirements already stored in their platforms. That is access. Requirements intelligence is the other problem, the one where the answer is not in the repository because nobody ever put it there, and no permission model, traceability score or context protocol can retrieve a sentence that was never written. Keep the tool. Add the column your evaluation is missing: what happens to the requirement that exists nowhere in it?
What column would you add to a 2026 requirements tool evaluation?
Requirement origin. Access is a row every serious platform can now fill, and Specira fills it too, with two-way sync into Confluence and Jira and the usual pending authorizations. The interesting column is the one before it. A discovery session with five agents questioning a stakeholder produces requirements that did not exist in any system beforehand, and the requirements list shows exactly that, marking which lines came from a session, which were AI-suggested, and which a person typed.
What you are looking at. The integrations are the access column every vendor can fill, the session is the column that comes before it, and the requirements list is where the difference between the two is visible.
Send us your evaluation grid. We will tell you which column separates the products you are comparing.
Book a DemoScreens are from a seeded Specira demo workspace; counts and scores are sample data.
What are the most common questions about requirements intelligence vs AI-agent context layers?
