Requirements Compliance Checker

Part 1: Wording, Anatomy & Quality  ·  Part 2: 9 Questions to Write Better Requirements

One requirement per line. Empty lines ignored. Ctrl+Enter to analyse.
Analysis Results
Pass (80–100%)
Needs work (50–79%)
Poor (<50%)
What this validator checks A guide to every rule applied to your requirements
SMART Every requirement is scored on 5 criteria

Each result carries a SMART verdict, derived from the detailed checks below. It is a quick, familiar lens on the same analysis.

  • SSpecific — clear, complete, single requirement (no vague or ambiguous wording).
  • MMeasurable — has a testable, quantitative bound (number, unit, or threshold).
  • AAchievable — realistic; avoids impossible absolutes like "100%" or "zero defects".
  • RRelevant — mandatory ("shall") and states a genuine need, not an implementation detail.
  • TTime-bound — specifies an explicit deadline or timing (e.g. "within 500 ms").
Part 1 Wording · Anatomy · Quality

Wording — the modal verb

Each requirement is graded on the keyword that sets its level of obligation.

  • shall / shall not Correct keyword for a mandatory, verifiable requirement.
  • must Flagged — replace with "shall" to avoid ambiguity.
  • should Non-mandatory — use "shall" if it is truly required.
  • will Non-binding — establishes context only.
  • may Optional, non-binding provision.

Anatomy — the 5 building blocks

A well-formed requirement contains all five parts; the checker detects each one.

Condition when / if / upon / during … Subject the entity that acts Action what it does Object what the action applies to Constraint a measurable bound

Quality — common writing pitfalls

  • Vague language — subjective terms like "fast", "reliable", "user-friendly".
  • Multiple requirements — "and shall / shall also" signals it should be split.
  • Too short — fewer than 6 words is likely incomplete.
  • Passive voice — "shall be …" hides who is responsible.
  • Purpose / rationale — "to ensure / so that" is noted as helpful context.
Part 2 The 9 Questions for a good requirement

Every requirement is scored against nine quality attributes drawn from systems-engineering practice.

1NecessaryStates an essential capability using mandatory wording.
2AppropriateSays what is needed, not how — no design detail.
3UnambiguousReads only one way; no vague or fuzzy connectors.
4CompleteContains all five anatomy components; self-contained.
5SingularExpresses exactly one requirement, not several.
6FeasibleRealistic — avoids absolutes like "100% uptime".
7VerifiableHas measurable criteria that can be objectively tested.
8CorrectProperly structured with subject, action, and "shall".
9ConformingFollows formal conventions; no informal language.

Grading: Pass 80–100% · Needs work 50–79% · Poor <50%.  Everything runs locally in your browser — nothing you type is sent anywhere.