Why Analyse Requirements
This is document 1 of the analysis guide. It explains what requirement analysis is for. Document 2, What Each Analysis Step Looks For, covers what each individual step checks.
The problem is not that requirements are badly written
Most requirements read perfectly well. That is exactly the difficulty.
A requirement is written by someone who understands the need, and it makes complete sense to them. It is then read by a developer, a tester, an architect and a regulator, none of whom share the author's assumptions. Every reader fills the gaps differently, and every reader believes they have understood.
The defects that matter are almost never obvious. They are:
- a term used in two senses in the same document
- a rule with three conditions and two stated outcomes
- a boundary that says "large files are rejected" without saying what large means
- a requirement that states how rather than what, quietly foreclosing a design nobody evaluated
- an obligation that no test could ever prove was met
None of these look wrong. They look finished.
Why review meetings do not find them
Requirement reviews are the standard answer, and they have three well-documented weaknesses.
Reviewers read for sense, not for gaps. The human reading system is built to construct meaning from incomplete information. That is a feature everywhere except here, where the job is to notice that the information is incomplete.
Attention is finite and unevenly spent. The first three pages get scrutiny; page fourteen gets a nod. Defect density is not distributed to match.
Reviewers share the author's context. The people best placed to spot a missing assumption are usually the people who share it.
None of this is a criticism of reviewers. It is a description of what reviews are good at — judgement, priority, disagreement about intent — and what they are bad at, which is exhaustive, uniform, unglamorous checking.
What REQQA actually does
REQQA reads a requirement the way a hostile, tireless, slightly pedantic reviewer would, and it does so the same way every time.
That last part is the point. The value is not that the machine is cleverer than your reviewers. It is that it applies the same fourteen questions to requirement one and requirement two hundred, at four in the afternoon on a Friday, without getting bored and without deciding that this one is probably fine.
Each analysis step asks one narrow question and reports what it finds as an issue with a severity, a location and a recommendation. You then decide what to do about each one — accept it, fix it, or mark it not-an-issue with a reason. REQQA does not change your requirements. It tells you what it noticed.
What it is honest about not knowing
This matters more than the list of things it checks.
REQQA analyses one artefact at a time. When it reads a requirement it can see that requirement, its parent chain, and the application mission. It cannot see the other two hundred requirements in the set.
So there are whole classes of problem it cannot reach, and it says so rather than pretending otherwise:
| It can judge | It cannot judge |
|---|---|
| Is this requirement ambiguous? | Does it contradict requirement 47? |
| Is it testable as written? | Is the set complete? |
| Does it state a need or a solution? | Is the terminology consistent across the corpus? |
| Does it conform to its template? | Is it affordable? |
| Does it derive from a stated source? | Is it true — of the regulation, the domain, the world? |
When a step finds something it cannot confirm, it does not suppress the finding and it does not overstate it. It raises it at reduced severity and says what it could not check. A finding that reads "not defined in this requirement — verify parent or sibling coverage" is doing something more useful than either silence or a confident HIGH.
This is a deliberate design principle: an analyser should grade its findings by its own reach, not by how serious the gap sounds.
Coverage against the standard
ISO/IEC/IEEE 29148:2018 defines nine characteristics that each individual requirement should possess. REQQA verifies seven of them:
| Characteristic | Checked by |
|---|---|
| Necessary | R-N |
| Appropriate | R-P |
| Unambiguous | R-A |
| Complete | R-M |
| Singular | R-W |
| Verifiable | R-Q, R-B |
| Conforming | R-W |
| Correct | R-N, in part — traceability yes, factual truth no |
| Feasible | Not checked — needs cost and schedule context REQQA does not hold |
The standard also defines five characteristics of a requirement set — complete, consistent, feasible, comprehensible, able to be validated. REQQA checks none of these, because every one of them requires reading the whole corpus at once. That is a known boundary, not an oversight.
What this is worth
Analysis does not replace thinking about requirements. It removes the part of the job that humans are worst at, so the review meeting can be spent on the part they are best at.
Put plainly: it is cheaper to find an ambiguous term now than to find it in a defect report after two developers interpreted it differently.
Next: What Each Analysis Step Looks For — the fourteen requirement steps and seven story steps, and what each one actually checks.