What Each Analysis Step Looks For
Document 2 of the analysis guide. Document 1, Why Analyse Requirements, explains what analysis is for and what it deliberately cannot reach.
Every step asks one narrow question. You choose which to run; each requirement template carries a recommended set, so most of the time you can accept the defaults.
The two kinds of step
The distinction matters when you are choosing what to run.
Universal steps apply to every requirement without exception. There is no requirement that does not need to be necessary, appropriately pitched, singular and conformant. These are on by default everywhere.
Dimensional steps apply only where the requirement has the content they examine. R-E is meaningful only if there are data entities; R-C only if there is decision logic. Running them on a requirement with no such content produces findings about things that are legitimately absent — noise, and it costs tokens.
Requirement steps
The universal four
R-D — Definitions
Asks: is every significant term either defined, or clear enough not to need defining?
Finds undefined domain terms, the same concept named two ways, and terms used inconsistently with the glossary. Terms you have deliberately ruled out go on the junk list and are never raised again.
It grades by what it can establish. A term defined by a standard your requirement cites is at most LOW — citing your sources is the behaviour REQQA should reward, not penalise. A HIGH needs three things demonstrated: the term is load-bearing, the text does not define it, and a competent reader could genuinely take it two ways.
R-N — Necessity and Traceability
Asks: should this requirement exist, and does it come from where it says?
Checks that a rationale is present and substantive — that it says something the requirement statement does not. "This improves quality" is not a rationale; it names no beneficiary and no consequence of removal. It also looks for signs of obsolescence, and whether the requirement is an orphan with no parent, no recorded source and no mission linkage.
It will never tell you a requirement is factually wrong about your domain. It has no access to your domain. Every finding is about the requirement's stated justification and lineage.
R-P — Appropriateness
Asks: does this state a need, or a solution? And is it pitched at the right level?
A requirement that specifies how rather than what forecloses design options nobody evaluated. But the standard permits design constraint where there is a reason for it, so R-P looks for unjustified constraint — not every mention of a technology.
"Because the existing billing system exposes only a SOAP interface" is a stated reason and raises nothing. "For performance reasons" is not — it is unverifiable, and it will be flagged.
Detection is semantic, not a list of technology names. "A relational store with row-level locking" names an implementation without naming any product, and is treated exactly the same as naming one. Every finding must quote the span it judged and the need that span appears to serve, so you can check the reasoning rather than take it on trust.
R-P does not have your other requirements, so it cannot tell whether this one is pitched consistently with its peers. Its findings say so.
R-W — Writing and Conformance
Asks: does this state one thing, and does it follow its template?
R-W is a hybrid, and the split is deliberate.
Most of it needs no AI at all. Escape clauses ("adequate", "as appropriate"), open-ended lists ("etc."), unachievable absolutes ("100%", "always"), superfluous infinitives ("shall be able to"), purpose phrases, oblique symbols, unexpanded acronyms — all decided by pattern, in milliseconds, for nothing.
A little of it needs judgement. Whether "and" joins two capabilities or merely two objects cannot be pattern-matched: "the name and address fields" and "log the event and notify the administrator" are lexically identical and semantically opposite. Only sentences flagged by the deterministic pass are sent to the model, so a clean requirement costs nothing.
It also checks conformance to your template through three independent probes — section presence, sentence pattern, and unfilled placeholder text. Each is gated on the template actually declaring what it needs. A probe that cannot run is recorded as skipped, never as passed. The difference between "checked and conformant" and "not checked" is the whole value of the step.
The dimensional steps
| Step | Asks | Run it when |
|---|---|---|
| R-G Goals and Users | Who is this for, and what business goal does it serve? | Almost always |
| R-F Features | What implementable features does this imply? | The requirement describes system behaviour |
| R-I Interfaces | What must this talk to, and is the exchange specified? | There are integrations or UI touchpoints |
| R-R Rules | Are the business rules complete and unambiguous? | There is logic, calculation or policy |
| R-E Entities and Data | What data does this involve, and is it specified? | There are entities, attributes or lifecycles |
| R-C Conditions and Decisions | Does every branch have a stated outcome? | There is conditional behaviour |
| R-B Boundaries | What happens at the edges and extremes? | There are ranges, limits or states |
| R-Q Quality Attributes | Are the non-functional obligations measurable? | Performance, security, availability matter |
| R-A Ambiguity | Can any of this be read two ways? | Almost always |
| R-M Missing Elements | What is absent across every dimension? | Last — it is a completeness sweep |
A note on R-M. It is a full re-analysis, not a residual sweep — it re-checks every dimension the other steps cover. That makes it thorough and it makes its findings overlap with theirs, so do not read "R-M found the most issues" as "R-M is the best step".
Story steps
Applied to user stories rather than requirements. Same philosophy, different artefact.
| Step | Asks |
|---|---|
| D-D Definitions | Are the terms in this story defined? |
| D-F Features | Is the story the right size, with clear boundaries? |
| D-O Outcomes | Is the outcome stated, and can you observe it? |
| D-S Scenarios | Are the scenarios complete — happy path, alternatives, errors, boundaries? |
| D-P Prediction | Does every scenario map to a predictable outcome? |
| D-A Ambiguity | Are there duplicate, conflicting or inconsistent scenarios? |
| D-M Missing | What is absent across all dimensions? (a full re-analysis, like R-M) |
And one for the application itself:
| Step | Asks |
|---|---|
| M-V Mission Validation | Is the mission statement complete enough to generate from? |
Reading the results
Every finding carries a severity and a category.
Severity is not comparable across steps. Some steps carry an explicit rubric that reasons about what they cannot see; others do not. A HIGH from R-A and a HIGH from R-M were assigned under different policies. Read severity within a step, not across them.
Category tells you what kind of thing it is:
- defect — a genuine fault: ambiguity, contradiction, missing precision
- suggestion — a recommendation for something non-textual (a diagram, a schema). The requirement is not faulty for lacking it
- scope_query — a question about whether this detail belongs here or in another document
That last category exists because "this requirement doesn't specify the database schema" is usually not a defect in the requirement — it is a note about where that content belongs.
See also: The Analysis Engine for how to run an analysis and manage the results · The Glossary for defined terms and the junk list.