skills.rest
jgsystemsconsulting
jgsystemsconsultingCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

requirements-writing

Write and review unambiguous, verifiable requirements using EARS syntax patterns and quality checklists.

5|1|Updated Jun 19, 2026
Search Tags:#traceability#requirements engineering#ears#systems engineering#verifiability#requirements writing#defect review
One-click install
npx skills add https://github.com/jgsystemsconsulting/jgs-se-knowledge-packs --skill requirements-writing-jgsystemsconsulting
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: requirements-writing
Source: https://github.com/jgsystemsconsulting/jgs-se-knowledge-packs/tree/main/packs/requirements-writing
Command: npx skills add https://github.com/jgsystemsconsulting/jgs-se-knowledge-packs --skill requirements-writing-jgsystemsconsulting

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Requirements written in free-form prose are often ambiguous, compound, or unverifiable, and these defects surface late as costly change requests. This Skill provides structured guidance for authoring and reviewing requirements so each statement is singular, unambiguous, and testable before baseline. ## Core Features & Use Cases - EARS Pattern Guidance: Apply the Ubiquitous, Event-driven (When), State-driven (While), Optional-feature (Where), and Unwanted-behaviour (If/Then) templates, choosing the pattern from the trigger. - Quality & Defect Review: Check requirements against nine quality characteristics and a defect catalogue covering ambiguity, compounding, embedded design, weak words, and unverifiability, with a banned-words list and cheatsheet. - Verifiability & Traceability: Assign Test/Analysis/Inspection/Demonstration methods at write time, make responses measurable, and maintain bidirectional traceability. - Use Case: When converting a legacy specification, ask for the EARS conversion of a vague requirement like "the system should quickly recover on failure" and receive a measurable If/Then requirement with a named system, trigger, and timed response. ## Quick Start Ask the agent to rewrite a vague requirement into the correct EARS pattern with a measurable, verifiable response.

Frequently Asked Questions about requirements-writing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write unambiguous requirements with EARS?▼

Choose the EARS pattern from the trigger: Ubiquitous for always-on behaviour, When for events, While for states, Where for optional features, and If/Then for faults. Every pattern ends with a named system and a single measurable response clause.

How do I convert vague legacy requirements into EARS format?▼

Identify the implicit trigger and response, name the responsible system, and recast the statement into the matching EARS template. Split any compound statements joined by 'and', and replace vague verbs with measurable criteria including value, units, and tolerance.

What makes a requirement verifiable?▼

A requirement is verifiable when a finite, affordable method can confirm it was met: Test, Analysis, Inspection, or Demonstration. Assign a method at writing time and make the response measurable with value, units, tolerance, and applicable conditions.

Which weak words should be avoided in requirements?▼

Avoid untestable terms like user-friendly, robust, fast, minimal, flexible, support, handle, etc., and as appropriate. Replace each with a measurable criterion such as a numeric threshold, time limit, or completion rate that a pass/fail test can check.

Does this pack reproduce ISO/IEC/IEEE 29148 or the INCOSE requirements guide?▼

No. This is original guidance that cites its methods rather than reproducing them: EARS is credited to Mavin et al. (2009) and quality guidance aligns with NASA public-domain material. Consult ISO/IEC/IEEE 29148 or the INCOSE guide directly for authoritative text.

When should I use the If/Then unwanted-behaviour pattern?▼

Use If/Then for faults, errors, out-of-range inputs, and safety responses, such as 'If outlet pressure exceeds 8 bar, then the controller shall stop the motor.' These conditions are the requirements most often omitted in free-form prose.

Related Skills

Explore More Software Engineering Skills→
qa-amanqa-aman
19

requirements-elicitation

Facilitate structured stakeholder requirement elicitation across interviews, workshops, observation, and document analysis.

Community
Advanced
terraphimterraphim

requirements-traceability

Generate a requirements traceability matrix linking requirements to design, implementation, tests, and evidence.

Official
Basic
zphzph
20

technical-spec

Convert natural-language requirements into EARS syntax for systems engineering.

Community
Basic
santosomarsantosomar
1

formal-spec-generator

Routes formal specification requests to appropriate tools like TLA+ and Dafny based on input type and verification goals.

Community
Intermediate