writing-requirements

Write clear, testable software requirements using EARS templates and quality checklists.

23|1|Updated Mar 19, 2026
One-click install
npx skills add https://github.com/jdm4pku/RE-Skills --skill writing-requirements-jdm4pku
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: writing-requirements
Source: https://github.com/jdm4pku/RE-Skills/tree/main/skills/writing-requirements
Command: npx skills add https://github.com/jdm4pku/RE-Skills --skill writing-requirements-jdm4pku

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Vague, ambiguous, or untestable requirements cause misinterpretation, rework, and defects. This Skill guides you through drafting individual requirements that are unambiguous, verifiable, and traceable using proven sentence patterns and quality criteria. ## Core Features & Use Cases - EARS Sentence Patterns: Apply five templates (Ubiquitous, Event-Driven, Unwanted Behavior, State-Driven, Optional Feature) to standardize requirement language. - Quality Self-Check: Validate each requirement against the ten characteristics of excellent requirements (correct, feasible, unambiguous, verifiable, and more). - Ambiguity Detection: Use the TBD watchlist to flag and replace vague terms like "appropriate", "efficient", or "user-friendly" with measurable criteria. - Use Case: A reviewer flags your requirement "The system shall generate appropriate reports" as untestable. Use this Skill to rewrite it as an event-driven EARS statement with a concrete trigger, quantified behavior, and a fit criterion. ## Quick Start Ask the agent to rewrite your draft requirement using the EARS pattern and run it through the ten-characteristic quality checklist.

Frequently Asked Questions about writing-requirements

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

FAQPage Schema
How do I write testable software requirements?▼

Use EARS sentence patterns to state a clear trigger and expected behavior, then verify a test case can be written for each requirement. Quantify every adjective and include a fit criterion describing how implementation will be verified.

What is the EARS requirements syntax?▼

EARS (Easy Approach to Requirements Syntax) defines five sentence patterns: Ubiquitous, Event-Driven (When...), Unwanted Behavior (If...then...), State-Driven (While...), and Optional Feature (Where...). Each pattern forces explicit triggers, states, and responses.

When should I use shall vs should vs will in requirements?▼

Use "shall" for binding requirements that must be tested and verified, "should" for desired but non-mandatory goals, and "will" for statements of fact about the environment or declarations of purpose.

How do I fix ambiguous requirements wording?▼

Replace vague terms like "appropriate", "efficient", or "user-friendly" with measurable criteria such as thresholds, response times, or task completion metrics. The TBD watchlist maps each ambiguous term to a concrete fix.

What are common mistakes when writing functional requirements?▼

Common pitfalls include compound requirements joining multiple behaviors with "and", missing triggers, ambiguous adjectives, prescribing implementation technology instead of needs, and inconsistent terminology across requirements.