Automated requirements engineering: reviewing requirements with the RE Assistant
Automotive software programmes accumulate requirement sets with thousands of entries that are reviewed manually. We build the RE Assistant – an AI system that automatically checks requirements for clarity, testability and contradictions, with a justification for every finding. The decision stays with the engineer.
The situation
In automotive software development, requirement sets grow to thousands of entries, spread across DOORS Next, Polarion, codebeamer or Jama Connect. Every entry is supposed to be unambiguous, testable and structurally complete – actor, condition, measurable quantity – and to follow the organisation's ASPICE-oriented writing rules.
Reviewing these sets manually ties up exactly the engineers whose time is scarcest. In practice, spot checks are often all that remains, and contradictions between requirements surface late – in testing or in the field, where they are most expensive.
Typical data basis
Requirement sets from DOORS Next, Polarion, codebeamer or Jama Connect, via export or API integration. Requirement and system specifications as Word and PDF documents, processed by a document pipeline that preserves layout, tables and numbering.
On top of that, the customer's internal writing guidelines and review catalogues – they turn a generic checking tool into a company-specific one – and historical review comments as a reference for typical objections.
Why such initiatives fail
Domain language without context. A language model misinterprets domain-specific terms and abbreviations unless it is prepared for them. Without a connection to the organisation's terminology it produces spurious findings.
Conflicts only show up in context. Requirements reference each other across document and system boundaries. Checking all pairs is computationally pointless at thousands of entries – the check has to be narrowed to promising candidates.
Black-box verdicts. A finding without justification and text reference is rightly rejected by requirements engineers. Every assessment has to be traceable.
Confidential data. Requirements data must not leave the company boundary. The system has to run entirely inside the customer's IT environment.
Approach
Rule set plus language model. Formal criteria – passive constructions, vague terms, missing measurable quantities, forbidden phrasings – are checked reliably and reproducibly by a deterministic rule set. Beyond that, the language model assesses comprehensibility and testability and delivers a justification with a text reference for every finding.
Conflict candidates instead of all pairs. A hybrid search combining keyword search (BM25) and embeddings finds the semantically nearest neighbours for each requirement; cross-encoder reranking sorts the candidates. Only this pair set enters a targeted contradiction check. The result is a list of conflict candidates with justifications, which the reviewer confirms or discards.
An agent for ad-hoc questions. For questions such as "Which requirements for this function are potentially in conflict?" or "Which of these requirements are not phrased testably?", an agent chains the checking steps.
Operation inside the customer boundary. The language model runs within the customer's IT environment – as an open-weight model such as Mistral or Llama on the customer's own GPU infrastructure served via vLLM, or as a contractually safeguarded EU service such as Azure OpenAI within the EU Data Boundary. The customer's IT makes that call; the rest of the architecture is unaffected by it.
What you get
Justified findings directly in the requirements management tool: per requirement, the assessment of clarity, testability and structural completeness, plus conflict candidates with justifications. Classification and summarisation come along automatically and make large requirement sets faster to grasp.
As the success criterion we agree on two metrics at project start: the reviewers' adoption rate for proposed findings and the false-finding rate against a labelled reference package. Both are measured in the pilot and fixed as the acceptance criterion.
Where our experience comes from
We have been mining technical and scientific text corpora for years and know automotive development from prediction and analytics projects with OEMs and suppliers.
Last updated: 13 August 2026
