This article is part of the RequiLink project, an open-source requirements intelligence platform for safety-critical engineering teams. Learn more about RequiLink →
For years, engineering teams in regulated industries have had three choices for requirements management: DOORS, Polarion, or Jama. The decision was never about which tool was best; it was about which one hurt the least. Every engineer who has spent an afternoon tracing links across modules, reconciling review comments from three email threads, or preparing an audit evidence package knows the feeling of fighting the tool instead of the problem.
That is starting to change. Open-source LLMs have reached production quality. Vector databases make semantic search practical and fast. The technology stack now exists to build requirements management platforms that help engineers write, review, and trace requirements instead of just storing them. This article explores what that shift looks like and why it matters for teams building safety-critical systems.
The Incumbent Problem
The legacy tools share a common DNA. They were designed in an era when requirements were documents, documents lived on file servers, and the main problem was version control. Over decades, they accumulated features (link modules, baselines, access control, workflow engines), but the core interaction model never fundamentally changed: you fill in fields, you click save, you run a report.
The hidden cost is not the licence. It is the time engineers spend navigating the tool instead of working with requirements. Every context switch between the requirements tool and the engineering tools (IDEs, simulation, test benches) fragments focus. Every change that requires manual downstream impact analysis introduces delay and risk. Every audit that demands stitching together evidence from three different systems adds stress.
Licence costs for DOORS or Polarion run between EUR 2,000 and 5,000 per user per year. Implementations take weeks with paid consultants. AI features, where they exist, are bolt-on integrations that feel disconnected from the actual workflow. For small and mid-sized engineering teams, the ROI equation simply does not add up, but neither does managing critical requirements in spreadsheets.
What AI-Native Actually Means
The difference between a tool with AI added and a tool built AI-native is visible the moment you start working. In an AI-native platform, the model is present on the same surface where the engineer works, suggesting, auditing, and generating requirements in context, not in a separate chat window.
Concretely, this means:
- Inline suggestions that ghost-text the next sentence as you write, grounded in your document's own terminology and domain
- Conformance checks that run INCOSE or similar quality rules on every requirement and explain why a violation matters
- Semantic link proposals that surface related items across modules based on meaning rather than manual tags
- Suspect link detection that flags downstream items automatically when a source requirement changes
These features sound incremental individually. Together, they change how an engineer spends their day. Instead of context-switching between writing and verifying, the verification happens continuously, in the background, while the engineer focuses on the substance.
The Certification Question
Every engineering manager in aerospace, automotive, medical devices, or rail asks the same question: will this pass an audit? The answer depends less on the tool and more on the data model underneath. For DO-178C, ISO 26262, EN 50128, or IEC 62304, a compliant requirements management platform needs three things:
- Append-only audit log, every change recorded with timestamp, user, and previous value. No editing history after the fact.
- Approval chains, baselines that require multi-stage sign-off before they become immutable.
- Deterministic export, a single package that bundles requirements, links, baselines, review records, and the audit trail in a format an auditor can inspect without the tool.
These are not AI features. They are tool confidence level (TQL) requirements that any platform targeting safety-critical industries must satisfy. The AI features sit on top of this foundation: they make the engineer more productive, but the audit evidence comes from the data model, not the model's suggestions.
Deployment and Total Cost of Ownership
One of the quiet frustrations with incumbent tools is the operational overhead. WebSphere application servers. Jazz Team Server. Dedicated database instances. Professional services engagements to configure workflow. The engineering team that wants to evaluate a new tool should not need to schedule a meeting with IT operations first.
Modern requirements platforms are shipping as single Docker Compose files. Postgres, application server, reverse proxy: three containers, one configuration file, under 30 minutes from clone to first requirement entered. For air-gapped environments, the same stack runs entirely offline with a local LLM inference engine. No data ever leaves the customer's network. No licence server to maintain.
Migration matters too. A platform that cannot import existing data is a non-starter, but import must be predictable. ReqIF, Word, Excel, CSV (each format has its own quirks). A preview-and-confirm import session that shows exactly what will be mapped and where prevents the silent corruption that happens when complex link structures cross format boundaries.
What This Means for Engineering Teams
The requirements management market is at an inflection point. The legacy vendors have decades of installed base but their platforms were designed before LLMs, before vector embeddings, before containerised deployment. The newcomers are building from scratch with a different starting assumption: that AI is not a feature to add, it is the medium the tool is built in.
For engineering teams, the practical implications are straightforward. If you are starting a new project or planning a tool migration, evaluate platforms on how they handle the daily workflow, not just the compliance checklist. A tool that saves each engineer an hour per day pays for itself in months, not years. A tool that deploys in 30 minutes and imports your existing data without friction removes the single biggest barrier to switching.
The technology is ready. The question is whether the engineering teams who have tolerated the incumbent pain long enough are ready to move on.