The quality of your requirements set is a project risk?

Not every project mandates Systems Engineering. But nearly every project is shaped by a requirements set written by the client or their consultant — and that requirements set largely determines how the project unfolds.

A requirement that cannot be verified leads to disputes at handover. A requirement that covers two subjects leads to conflicting interpretations during design. A requirement with an absolute value — "the system shall always be available" — is contractually untenable. And a requirement that is missing, but implicitly expected, leads to rework.

These are not edge cases. Industry research shows that 68% of organisations have structural quality problems with their requirements specifications, and that 70–85% of rework costs in projects can be traced back to errors in or around requirements. Those costs start with the client, but land with everyone involved in the project.

The RQA makes those risks visible — before they materialise.

What the RQA does

The Requirements Quality Analyser automatically assesses each requirement against INCOSE quality rules. Not as a general grammar check, but as a domain-specific analysis that understands what a requirement is, what it needs to be able to do, and what it must not be.

Each requirement receives a quality score from 1 to 5, one or more findings that pinpoint exactly what is wrong, and a concrete improvement suggestion. The output is traceable and explainable — not "this requirement is poor", but "this requirement flags R7 vagueness because the word 'sufficient' provides no measurable threshold."

Before a requirement is analysed, the RQA first classifies what it is. Three categories:

A genuine requirement contains a modal verb — shall, must, may not — and expresses an obligation. These receive full INCOSE analysis.

A latent requirement contains an implicit obligation through quantitative information or referenced standards, but lacks a modal verb. The RQA recognises these and reformulates them into explicit requirements.

Not a requirement — process descriptions, definitions, explanatory notes, table of contents entries — are filtered out. They are not analysed, but they are made visible so you know what is being set aside.

The quality rules

The RQA tests each requirement against seven INCOSE rules, like;

• Vagueness — terms such as "sufficient", "adequate", "reasonable" or "minimal" without a number provide no verifiable criterion. The RQA flags them and proposes a sharper formulation.

• Open ends — phrases such as "etc.", "among others" or "including but not limited to" leave scope undefined. That is a risk for verification and for contractual disputes.

• Absolutes — "always", "never", "fully", "100%" are technically unachievable and contractually dangerous. The RQA marks these as feasibility risks.

• Singularity — a requirement that combines two or more subjects via "and" or "or" is effectively two requirements. The RQA identifies this and generates a split proposal.

• Verifiability — a requirement without a measurement criterion, test method or acceptance criterion cannot be verified. The RQA indicates what is missing.

• Solution prescription — a requirement that prescribes the solution rather than the need unnecessarily restricts design freedom. Unless it is a constraint, this is a design decision that does not belong in the requirement.

• Formulation — in English, requirements must use "shall". Alternatives such as "will", "should" or "can" are not compliant with INCOSE standards. In Dutch, "dient" is the required modal verb.

• 

Set-level analysis: beyond the individual requirement

Individual requirement quality is one thing. But a set of a hundred well-written requirements can still have internal problems.

The RQA also analyses the full requirements set for near-duplicates and contradictions. Two requirements that are semantically similar are flagged as potential duplicates — with the similarity score and an explanation of where the overlap lies. Two requirements that contradict each other are flagged as conflicting — with a reference to both requirements and the nature of the conflict.

This matters for large specifications running to hundreds of requirements, where manual control for overlap and contradiction is practically impossible.

Two perspectives on the same requirement

The RQA offers two lenses on every requirement: that of the author and that of the executor.

As the author, you see formulation improvements — what the requirement lacks, what sharper or more consistent wording would look like, and whether it conforms to the applicable standard.

As the executor, you see the questions a requirement raises in practice — what does this mean concretely for my design, what assumptions lie beneath it, and what derived requirements follow from it. Those questions are the precursor to later disputes. Making them visible early is more valuable than resolving them later.

What you get back

The output of the RQA is an annotated requirements set: each requirement with its score, findings per quality rule and a concrete improvement suggestion. Split requirements are presented as separate rows. The table is exportable to Excel and feeds back into your own requirements management system.

The systems engineer or review lead decides what happens with the findings. The RQA analyses and advises — the decision stays with the person.

Go to the RQA product page

You won't regret it

RQA

Part of a broader workflow

The RQA does not stand alone. Input can come directly from the DRE — requirements extracted from contracts or specifications feed automatically into quality analysis. The output feeds the REF, which finds and links verification evidence to requirements in the project documentation.

From extraction to quality check to verification — as a connected process.

Curious what the RQA does with your requirements set? Book a demo and we will show you using a real document.