Requirements Writing · EARS and Quality

Requirements Writing Guidance is a plain-Markdown pack for writing and reviewing requirements that are unambiguous, singular, and verifiable. Its six chapters combine EARS sentence patterns, requirement quality characteristics, a defect catalogue, and verification and traceability guidance. The material is original guidance by JG Systems Consulting Ltd., with EARS credited to Mavin et al. (2009) and quality and verification guidance aligned with NASA public-domain systems engineering material.

The quality review asks whether each requirement is necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct, and conforming. Appropriate means describing what is needed rather than embedding the implementation. A compact initial gate asks whether the requirement is necessary and whether a pass/fail test can be written for it.

EARS, the Easy Approach to Requirements Syntax, supplies constrained natural-language templates while keeping statements in plain English. Pattern selection follows the trigger. Ubiquitous requirements state behavior that always applies. Event-driven statements use When for a triggering event; state-driven statements use While for an active state. Optional-feature requirements use Where, and unwanted-behaviour requirements use If and Then for conditions such as faults and safety cases. Complex patterns combine these structures while keeping the result readable. The templates make the system, applicable trigger, and response explicit.

Syntax is only one review layer. A separate defect pass addresses ambiguous wording, compound requirements, embedded design, weak or vague words, unverifiable statements, and missing rationale. Each defect class has a remedy in the pack. Structured sentences reduce ambiguity but cannot eliminate it on their own.

Verification is assigned while writing, using Test, Analysis, Inspection, or Demonstration. Responses become measurable through a value, units, tolerance, and condition. Bidirectional traceability connects the requirement upward to its originating need and downward to verification evidence. The guidance distinguishes verification, checking the thing is built right, from validation, checking it is the right thing.

Use the pack when drafting or reviewing behavioral and functional requirements, selecting an EARS pattern, converting legacy statements, or checking whether a response can be verified. It is also relevant when a review finds weak language, multiple obligations in one statement, implementation detail mixed with need, or missing traceability.

This is guidance for requirement writing rather than a complete requirements-management or elicitation methodology. It does not reproduce ISO/IEC/IEEE 29148, the INCOSE Guide for Writing Requirements, or the EARS conference paper. Consult those authoritative sources directly when their exact text is required. NASA references include NPR 7123.1 and the SE Handbook.

Invoke the skill without arguments to load the EARS patterns and quality checklist. A topic can target event-driven EARS, unambiguous wording, weak words, or verifiability. A chapter request such as ch03 selects the pattern chapter.

The chapter progression covers quality characteristics, the EARS overview, the patterns themselves, applying EARS through pattern selection and before-and-after conversion, defects and anti-patterns, and verifiability and traceability. A topic index routes questions about complex state-and-event patterns, tolerances, verification methods, and legacy conversion to the relevant material.

Supporting glossary.md defines key terms, patterns.md covers patterns and review techniques with trade-offs, and cheatsheet.md provides a pattern picker, quality checklist, decision rules, and banned-word guidance. No MCP server, API key, or runtime licence tier is required to use this Markdown material.