name	requirements-quality
description	Requirements quality assessment and improvement. Use when evaluating requirements against INVEST criteria, improving clarity, detecting ambiguity, or ensuring completeness. Provides quality checklists, refinement patterns, and MoSCoW prioritization guidance.
allowed-tools	Read, Glob, Grep, Write, Edit, Task

Requirements Quality

Requirements quality assessment, INVEST criteria validation, and refinement patterns.

When to Use This Skill

Keywords: INVEST, requirements quality, clarity, ambiguity, completeness, testable, estimable, refinement, MoSCoW, prioritization, acceptance criteria, requirement validation, quality assessment

Use this skill when:

Evaluating requirements against INVEST criteria
Improving requirement clarity and precision
Detecting and resolving ambiguity
Ensuring requirements are complete
Applying MoSCoW prioritization
Refining requirements iteratively
Validating acceptance criteria quality

INVEST Criteria Overview

The INVEST acronym defines six quality criteria for well-formed requirements:

Criterion	Question	Red Flag
Independent	Can this be implemented alone?	"Requires X to be done first"
Negotiable	Is there room for discussion?	Over-specified implementation
Valuable	Does it deliver user value?	Technical-only benefit
Estimable	Can effort be estimated?	Vague or unbounded scope
Small	Can it be done in one iteration?	Multi-sprint scope
Testable	Can we verify it's done?	Missing acceptance criteria

Quick Quality Assessment

Rapid INVEST Check

For each requirement, score 0-2 on each criterion:

Score	Meaning
0	Does not meet criterion
1	Partially meets criterion
2	Fully meets criterion

Interpretation:

10-12: High quality, ready for implementation
7-9: Acceptable, minor improvements needed
4-6: Needs work, significant refinement required
0-3: Not ready, major rewrite needed

Common Quality Issues

Issue	Symptom	Fix
Too vague	"Make it user-friendly"	Add measurable criteria
Too large	Multi-week estimate	Split into smaller requirements
Untestable	No clear success condition	Add acceptance criteria
Dependent	"After X is complete"	Decouple or combine
Technical	"Refactor database"	Reframe as user value
Over-specified	Implementation details	Focus on what, not how

MoSCoW Prioritization

Priority Levels

Priority	Meaning	Guidance
Must	Critical for release	Without this, release fails
Should	Important but not critical	High value, schedule permitting
Could	Nice to have	Include if time allows
Won't	Out of scope (this time)	Explicitly deferred

Prioritization Questions

What happens if we don't include this?
Is there a workaround without this?
How many users are affected?
What's the business impact?
Are there dependencies on this?

Clarity Enhancement Patterns

Ambiguity Detection

Ambiguous Words to Avoid:

Word	Problem	Better Alternative
"should"	Unclear obligation	"SHALL" (mandatory) or "MAY" (optional)
"quickly"	Subjective timing	"within 200ms"
"user-friendly"	Subjective quality	Specific usability criteria
"etc."	Incomplete list	Exhaustive enumeration
"appropriate"	Vague standard	Specific criteria
"some"	Undefined quantity	Explicit count or range
"easy"	Subjective difficulty	Measurable steps

Clarity Checklist

Uses specific, measurable terms
Avoids ambiguous words
Defines all acronyms on first use
Includes units for all quantities
Specifies actors clearly
Defines success conditions

Acceptance Criteria Quality

Good Acceptance Criteria

Each acceptance criterion should be:

Atomic: Tests one thing
Precise: Clear pass/fail
Complete: Covers the requirement
Independent: Tests can run in any order

Given/When/Then Format

Given [precondition]
When [action]
Then [expected outcome]

Quality Check:

Given establishes clear context
When describes specific trigger
Then defines observable outcome
Covers happy path and error cases
Each AC is independently testable

Refinement Workflow

Standard Refinement Process

1. Draft Requirement
   ↓
2. INVEST Assessment (score each criterion)
   ↓
3. Identify Issues (low-scoring criteria)
   ↓
4. Apply Fixes (use patterns below)
   ↓
5. Re-assess (verify improvements)
   ↓
6. Add Acceptance Criteria
   ↓
7. Final Validation

Iteration Patterns

When Independent fails:

Extract dependencies into separate requirements
Or combine tightly coupled requirements

When Negotiable fails:

Remove implementation details
Focus on outcomes, not methods

When Valuable fails:

Reframe in user terms
Connect to business goal

When Estimable fails:

Add constraints and boundaries
Define scope limits

When Small fails:

Split by user type
Split by scenario
Split by CRUD operation

When Testable fails:

Add acceptance criteria
Define success metrics

Completeness Validation

Requirement Completeness

A complete requirement includes:

Element	Description	Required?
ID	Unique identifier	Yes
Title	Brief descriptive title	Yes
Description	Full requirement text	Yes
Priority	MoSCoW level	Yes
Acceptance Criteria	Testable conditions	Yes
Dependencies	Related requirements	If any
Assumptions	Underlying assumptions	If any
Constraints	Limitations	If any

Specification Completeness

A complete specification includes:

All functional requirements identified
Non-functional requirements included
Edge cases considered
Error handling specified
Security requirements addressed
Performance criteria defined
Accessibility requirements included
All requirements prioritized
Dependencies mapped
Assumptions documented

Quick Commands

Action	Command
Assess requirement quality	`/spec:validate <path>`
Refine requirements	`/spec:refine <path>`
Audit specification	`/spec:audit <path>`

Related Skills

ears-authoring - EARS pattern authoring
gherkin-authoring - Given/When/Then criteria
canonical-spec-format - Canonical specification structure
spec-management - Specification workflow hub

References

Detailed Documentation:

INVEST Criteria - INVEST principles with examples
Refinement Patterns - Refinement techniques
Completeness Checklist - Validation checklist

Last Updated: 2025-12-24

Version History

v1.0.0 (2025-12-26): Initial release

requirements-quality

Install Skill

SKILL.md