jgsystemsconsulting Requirements Writing Guidance — EARS & Requirement Quality
Source: Original guidance by JG Systems Consulting Ltd. (methods cited: EARS / Mavin et al. 2009; quality & verification guidance per NASA public-domain SE guidance) | Chapters: 6
When to use
Use this pack when you are writing or reviewing requirements and want them unambiguous, singular, and verifiable. It gives you the quality characteristics a requirement must pass, the EARS sentence patterns that remove most ambiguity, a defect catalogue for review, and how to make requirements verifiable and traceable. Best for behavioural/functional requirements; it points to the authoritative standards rather than reproducing them.
Prerequisites: none — this pack is plain Markdown; no MCP server, API key, or licence tier is needed at runtime.
How to Use This Skill
- Without arguments — load the EARS patterns and the quality checklist below.
- With a topic — ask about
EARS event-driven,unambiguous,weak words,verifiability. - With a chapter — ask for
ch03(the EARS patterns).
Supporting files: glossary.md, patterns.md, cheatsheet.md (the EARS pattern-picker + banned-words list).
Core Frameworks & Mental Models
The quality characteristics (Ch 1). Every single requirement should be necessary, appropriate (what not how), unambiguous, complete, singular, feasible, verifiable, correct, conforming. The two-question gate that catches most damage: is it necessary? and can I write a pass/fail test?
EARS — Easy Approach to Requirements Syntax (Ch 2–4). A small set of natural-language templates (Mavin et al., 2009) that keep requirements in plain English while forcing a named system, an explicit trigger, and a single response. Choose the pattern by the trigger:
- Ubiquitous — always on: The
<system>shall<response>. - Event-driven (When) — When
<trigger>, the<system>shall<response>. - State-driven (While) — While
<state>, the<system>shall<response>. - Optional-feature (Where) — Where
<feature>, the<system>shall<response>. - Unwanted-behaviour (If/Then) — If
<condition>, then the<system>shall<response>. (faults & safety) - Complex — combinations, kept readable.
The defect catalogue (Ch 5). EARS fixes the shape; content defects need a separate pass: ambiguity, compound requirements, embedded design, weak/vague words, unverifiability, missing rationale — each with a standard remedy.
Verifiability & traceability (Ch 6). Assign a verification method (Test / Analysis / Inspection / Demonstration) as you write; make responses measurable (value + units + tolerance + condition); maintain bidirectional traceability up to the need and down to evidence. Keep verification ("thing right") distinct from validation ("right thing").
Chapter Index
| # | Section | Key content |
|---|---|---|
| ch01 | What makes a good requirement | the nine quality characteristics; the necessary+verifiable gate |
| ch02 | EARS overview | constrained natural language; why a small ruleset works |
| ch03 | The EARS patterns | Ubiquitous / When / While / Where / If-Then / Complex + examples |
| ch04 | Applying EARS | pattern selection; convert-in-place; before/after examples |
| ch05 | Defects & anti-patterns | ambiguity, compounding, embedded design, weak words, unverifiability |
| ch06 | Verifiability & traceability | T/A/I/D methods; measurable responses; bidirectional trace |
Topic Index
- EARS patterns (When/While/Where/If-Then) → ch03, ch04
- Quality characteristics (necessary, unambiguous, singular…) → ch01
- Ambiguity / weak words / compound requirements → ch05
- Embedded design in requirements → ch05, ch01
- Verifiability / verification methods (T/A/I/D) → ch06
- Traceability / verification vs validation → ch06
- Converting legacy requirements → ch04
- Measurable response / tolerances → ch06, ch03
Supporting Files
- glossary.md — key terms (EARS patterns, quality characteristics, verification methods)
- patterns.md — the EARS patterns + review techniques, as when/how/trade-offs
- cheatsheet.md — EARS pattern-picker table, quality checklist, decision rules, banned-words list, tells & smells
Scope & Limits
This is original guidance written by JG Systems Consulting Ltd., synthesising widely-taught requirements practice. It cites its methods rather than reproducing them: the EARS patterns are credited to Mavin et al. (2009) and described in original words; the quality and verification material aligns with NASA public-domain SE guidance (NPR 7123.1 / SE Handbook). It is not a reproduction of ISO/IEC/IEEE 29148, the INCOSE Guide for Writing Requirements, or the EARS conference paper — for the authoritative text, consult those sources directly. The pack covers behavioural/functional requirement writing; it is not a full requirements-management or elicitation methodology.