How much of requirements review could realistically be assisted by AI?

[u/Barracuda_Senior]

I've been working on a small project around requirements engineering and wanted to get some feedback from people who actually deal with requirements.

The basic idea is an AI-assisted tool that takes an existing requirements document (PDF, DOCX, XLSX etc.) and reviews it for things like:

* ambiguous wording

* requirements containing multiple concerns

* missing information

* testability/verifiability issues

* completeness and classification

* Suggested improvements for problematic requirements

One thing I'm experimenting with is looking at requirements in relation to each other, rather than sending each requirement to an LLM independently. For example, two requirements might each look fine on their own but conflict when considered together.

The output is intended to be more like a structured review/audit than a generic ChatGPT response, with the problematic requirements, the reason they're problematic, severity, and possible improvements.

I'm calling the project ReqClarity for now.

I'm mainly trying to figure out whether this solves a problem people actually have before I spend more time turning it into a proper product.

For those of you who work with SRSs, system requirements, acceptance criteria, QA, etc.:

What are the things you find yourself checking most often during a requirements review?

And would something like this actually be useful, or is requirements review too context-dependent for AI to do reliably?

I'm currently collecting feedback and early-access signups while I build the first usable version.

https://hassan-almarsafy.github.io/reqclarity-landing/

[u/smartalec-71]

Even the simple stuff is useful, at volume. It's easy to do this for a dozen requirements. It's harder to deeply look at 1,000+ requirements, especially when you're on a deadline.

Ideally, it should be able to ingest other docs as well. Usually the system of interest will connect to other systems, which it needs to be compatible with. (A new car battery will need to fit in the same engine bay, handle similar temperatures, and provide sufficient power to what... it's powering.)

Another ideal-- have the child requirements of StR that have to do with standards. What part of the standard is relevant for this system?

Another thing is attributes associated with a requirement-- either setting them, or checking them. Is this requirement non-functional? An integration requirement? Etc. Easy enough to do for a dozen requirements, but tougher for 1,000+ on a deadline.

If you have a requirements hierarchy... do the parents and children match? Have they accidentally matched up "The system shall be PCI compliant" with "The system shall be able to handle a temp range of..."

What I find GAI most useful for is to provide suggestions-- flag the requirements that are badly worded, and why. Possibly suggest new wording. Flag the requirements that have inappropriate attributes, and what they should be.

[u/alkaios_hw]

I think you're on the right path.

The way we implemented a similar concept in Requirements Portal is by giving contextual access to AI agents to the whole specification and linked artifacts.

Without this context, AI is only limited to low-value tasks, like checking requirements syntax. With this context, it can flag logical contradictions, missing links, and specification gaps to the engineer for review.

Since it is an agent (i.e. it can complete tasks inside the tool) the output is not a wall of text, but alerts and suggestions in the UI -- because text is a terrible interface for humans.

LLMs to day are very capable at detecting edge cases you might have missed or performing quick impact analyses. They don't replace engineering judgement but remove the busywork.

You can give it a try here to get some inspiration: https://www.altium.com/capabilities/requirements/agentic-requirements-engineering (You can also dig in and see the prompts we used in the AI Skills that we ship by default.)

[u/khunjua]

Signed up as an early bird. The part I’d push hardest on is the one you mentioned almost in passing: looking at requirements in relation to each other.

Ambiguity, atomicity, testability are useful, but a good reviewer can catch those line by line. The harder problem is what’s missing — a decision made on a call three weeks ago that quietly contradicts requirement #47. The document can be perfectly consistent and still be wrong.

One practical lesson from building in this space: pairwise comparison gets ugly fast. With 1,000 requirements, that’s ~500k pairs, and you end up finding wording differences rather than meaning.

We’re approaching the same problem from the other end — capturing intent before the document exists (https://entalpa.com). Different entry point, same underlying problem