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.
This skill is limited to using the following tools:
references/completeness-checklist.mdreferences/invest-criteria.mdreferences/refinement-patterns.mdRequirements quality assessment, INVEST criteria validation, and refinement patterns.
Keywords: INVEST, requirements quality, clarity, ambiguity, completeness, testable, estimable, refinement, MoSCoW, prioritization, acceptance criteria, requirement validation, quality assessment
Use this skill when:
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 |
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:
| 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 |
| 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 |
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 |
Each acceptance criterion should be:
Given [precondition]
When [action]
Then [expected outcome]
Quality Check:
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
When Independent fails:
When Negotiable fails:
When Valuable fails:
When Estimable fails:
When Small fails:
When Testable fails:
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 |
A complete specification includes:
| Action | Command |
|---|---|
| Assess requirement quality | /spec:validate <path> |
| Refine requirements | /spec:refine <path> |
| Audit specification | /spec:audit <path> |
ears-authoring - EARS pattern authoringgherkin-authoring - Given/When/Then criteriacanonical-spec-format - Canonical specification structurespec-management - Specification workflow hubDetailed Documentation:
Last Updated: 2025-12-24