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