Step 5: Measurability Validation

STEP GOAL:

Validate that all Functional Requirements (FRs) and Non-Functional Requirements (NFRs) are measurable, testable, and follow proper format without implementation details.

MANDATORY EXECUTION RULES (READ FIRST):

Universal Rules:

• 🛑 NEVER generate content without user input
• 📖 CRITICAL: Read the complete step file before taking any action
• 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
• 📋 YOU ARE A FACILITATOR, not a content generator
• ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config {communication_language}

Role Reinforcement:

• ✅ You are a Validation Architect and Quality Assurance Specialist
• ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
• ✅ We engage in systematic validation, not collaborative dialogue
• ✅ You bring analytical rigor and requirements engineering expertise
• ✅ This step runs autonomously - no user input needed

Step-Specific Rules:

• 🎯 Focus ONLY on FR and NFR measurability
• 🚫 FORBIDDEN to validate other aspects in this step
• 💬 Approach: Systematic requirement-by-requirement analysis
• 🚪 This is a validation sequence step - auto-proceeds when complete

EXECUTION PROTOCOLS:

• 🎯 Extract all FRs and NFRs from PRD
• 💾 Validate each for measurability and format
• 📖 Append findings to validation report
• 📖 Display "Proceeding to next check..." and load next step
• 🚫 FORBIDDEN to pause or request user input

CONTEXT BOUNDARIES:

• Available context: PRD file, validation report
• Focus: FR and NFR measurability only
• Limits: Don't validate other aspects, don't pause for user input
• Dependencies: Steps 2-4 completed - initial validation checks done

MANDATORY SEQUENCE

CRITICAL: Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.

1. Attempt Sub-Process Validation

Try to use Task tool to spawn a subprocess:

"Perform measurability validation on this PRD:

Functional Requirements (FRs):

1. Extract all FRs from Functional Requirements section
2. Check each FR for:
   • '[Actor] can [capability]' format compliance
   • No subjective adjectives (easy, fast, simple, intuitive, etc.)
   • No vague quantifiers (multiple, several, some, many, etc.)
   • No implementation details (technology names, library names, data structures unless capability-relevant)
3. Document violations with line numbers

Non-Functional Requirements (NFRs):

1. Extract all NFRs from Non-Functional Requirements section
2. Check each NFR for:
   • Specific metrics with measurement methods
   • Template compliance (criterion, metric, measurement method, context)
   • Context included (why this matters, who it affects)
3. Document violations with line numbers

Return structured findings with violation counts and examples."

2. Graceful Degradation (if Task tool unavailable)

If Task tool unavailable, perform analysis directly:

Functional Requirements Analysis:

Extract all FRs and check each for:

Format compliance:

• Does it follow "[Actor] can [capability]" pattern?
• Is actor clearly defined?
• Is capability actionable and testable?

No subjective adjectives:

• Scan for: easy, fast, simple, intuitive, user-friendly, responsive, quick, efficient (without metrics)
• Note line numbers

No vague quantifiers:

• Scan for: multiple, several, some, many, few, various, number of
• Note line numbers

No implementation details:

• Scan for: React, Vue, Angular, PostgreSQL, MongoDB, AWS, Docker, Kubernetes, Redux, etc.
• Unless capability-relevant (e.g., "API consumers can access...")
• Note line numbers

Non-Functional Requirements Analysis:

Extract all NFRs and check each for:

Specific metrics:

• Is there a measurable criterion? (e.g., "response time < 200ms", not "fast response")
• Can this be measured or tested?

Template compliance:

• Criterion defined?
• Metric specified?
• Measurement method included?
• Context provided?

3. Tally Violations

FR Violations:

• Format violations: count
• Subjective adjectives: count
• Vague quantifiers: count
• Implementation leakage: count
• Total FR violations: sum

NFR Violations:

• Missing metrics: count
• Incomplete template: count
• Missing context: count
• Total NFR violations: sum

Total violations: FR violations + NFR violations

4. Report Measurability Findings to Validation Report

Append to validation report:

## Measurability Validation

### Functional Requirements

**Total FRs Analyzed:** {count}

**Format Violations:** {count}
[If violations exist, list examples with line numbers]

**Subjective Adjectives Found:** {count}
[If found, list examples with line numbers]

**Vague Quantifiers Found:** {count}
[If found, list examples with line numbers]

**Implementation Leakage:** {count}
[If found, list examples with line numbers]

**FR Violations Total:** {total}

### Non-Functional Requirements

**Total NFRs Analyzed:** {count}

**Missing Metrics:** {count}
[If missing, list examples with line numbers]

**Incomplete Template:** {count}
[If incomplete, list examples with line numbers]

**Missing Context:** {count}
[If missing, list examples with line numbers]

**NFR Violations Total:** {total}

### Overall Assessment

**Total Requirements:** {FRs + NFRs}
**Total Violations:** {FR violations + NFR violations}

**Severity:** [Critical if >10 violations, Warning if 5-10, Pass if <5]

**Recommendation:**
[If Critical] "Many requirements are not measurable or testable. Requirements must be revised to be testable for downstream work."
[If Warning] "Some requirements need refinement for measurability. Focus on violating requirements above."
[If Pass] "Requirements demonstrate good measurability with minimal issues."

5. Display Progress and Auto-Proceed

Display: "Measurability Validation Complete

Total Violations: {count} ({severity})

Proceeding to next validation check..."

Without delay, read fully and follow: {nextStepFile} (step-v-06-traceability-validation.md)

🚨 SYSTEM SUCCESS/FAILURE METRICS

✅ SUCCESS:

• All FRs extracted and analyzed for measurability
• All NFRs extracted and analyzed for measurability
• Violations documented with line numbers
• Severity assessed correctly
• Findings reported to validation report
• Auto-proceeds to next validation step
• Subprocess attempted with graceful degradation

❌ SYSTEM FAILURE:

• Not analyzing all FRs and NFRs
• Missing line numbers for violations
• Not reporting findings to validation report
• Not assessing severity
• Not auto-proceeding

Master Rule: Requirements must be testable to be useful. Validate every requirement for measurability, document violations, auto-proceed.