requirement-review

name requirement-review description Conducts comprehensive requirements review including completeness validation, clarity assessment, consistency checking, testability evaluation, and standards compliance. Produces detailed review reports with findings, gaps, conflicts, and improvement recommendations. Use when reviewing requirements documents (BRD, SRS, user stories), validating acceptance criteria, assessing requirements quality, identifying gaps and conflicts, or ensuring standards compliance (IEEE 830, INVEST criteria). Trigger when users mention "review requirements", "validate requirements", "check requirements quality", "find requirement issues", or "assess BRD/SRS quality". Requirement Review Systematically review requirements to validate quality and identify issues before design and development begins. Ensure requirements are complete, clear, consistent, testable, and traceable. Review Workflow 1. Preparation Gather all relevant documentation: Requirements documents (BRD, SRS, user stories) Non-functional requirements and constraints Requirements Traceability Matrix (if available) Project context (charter, goals) Existing acceptance criteria 2. Quality Assessment Evaluate each requirement using six quality attributes : Completeness : All needs captured, no missing details or TBDs, dependencies identified Clarity : Unambiguous, specific, no vague terms ("user-friendly", "fast", "easy") Consistency : No conflicts, consistent terminology and priorities Testability : Verifiable with measurable acceptance criteria and clear pass/fail Traceability : Links to business goals, design, and tests Feasibility : Technically achievable within constraints (budget, timeline, capability) See quality-checklists.md for detailed assessment criteria and document-specific checklists 3. Issue Identification Identify common requirement problems: Ambiguous : "system shall be fast" → Specify measurable criteria: "< 2s response for 95% of requests" Untestable : "system shall be secure" → Define specific controls: password complexity, encryption standards, audit logging Incomplete : "system shall send notifications" → Specify channel, timing, content, recipients Conflicting : REQ-012 "phone required" vs REQ-089 "phone optional" → Flag for stakeholder resolution See examples.md for extensive before/after examples 4. Quality Scoring Calculate scores for each quality attribute (0-100%): 90-100% : Excellent - minimal issues 75-89% : Good - minor improvements needed 60-74% : Fair - notable gaps exist Below 60% : Poor - major rework required Overall Quality = Average of all six attributes Target : ≥ 90% for production-readiness 5. Report Generation Create structured review report with: Executive Summary : Quality rating, recommendation, key strengths (2-3), critical issues (2-3), top actions Detailed Findings : Quality scores, issues by severity (Critical/Major/Minor), specific examples with requirement IDs Action Items : Prioritized list with owners, due dates, effort estimates, approval conditions See report-templates.md for complete report structure and templates 6. Recommendations Provide clear decision: Approve : Requirements ≥ 90% quality threshold Approve with Conditions : Critical issues must be resolved before design Major Revision : 60-74% quality - substantial rework required Reject : < 60% quality or fundamental issues - complete redesign needed Document-Specific Focus Business Requirements Documents (BRD) Focus on business objectives, stakeholder needs, scope definition, business case, constraints Software Requirements Specifications (SRS) Focus on functional requirements, non-functional requirements (performance, security, scalability), system behaviors, integration points, IEEE 830 compliance User Story Backlogs Focus on INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable), acceptance criteria format (Given-When-Then), story format, prioritization See quality-checklists.md for document-specific assessment criteria Severity Definitions Critical : Blocks progress, must fix immediately (security gaps, fundamental conflicts, missing scope) Major : Significant quality impact, should fix before approval (ambiguous criteria, missing acceptance criteria) Minor : Quality improvements, nice to have (formatting, examples, enhancements) Common Anti-Patterns to Flag Gold Plating : Adding unrequested features Solution-Focused : Specifying "how" instead of "what" (requirements should be technology-agnostic) Scope Creep : Accepting changes without change control Analysis Paralysis : Over-perfecting requirements indefinitely Weak Acceptance Criteria : Vague or missing test conditions No Traceability : Requirements disconnected from business goals Vague Terms to Replace Always replace with measurable criteria: "user-friendly", "intuitive", "easy" → Define usability metrics "fast", "quick", "responsive" → Specify response time targets "secure" → Define specific security controls "scalable" → Define capacity and load targets "reliable" → Define uptime percentage and recovery time Standards Compliance IEEE 830 : SRS structure and content standards INVEST : User story quality criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) ISO/IEC 25010 : Systems and software quality models Industry-Specific : HIPAA (healthcare), PCI-DSS (payments), SOC 2 (SaaS), FDA (medical devices) See quality-checklists.md for standards compliance details Report Format Generate review reports in this structure: Executive Summary (1 page): Overall assessment, key findings, recommendation Quality Metrics (0.5 page): Scores by attribute with targets Detailed Findings (2-5 pages): Issues grouped by attribute with examples and recommendations Action Items (1 page): Prioritized list with owners and due dates Approval Decision (0.5 page): Recommendation with rationale and next steps Keep reports factual, specific, and actionable. Always cite specific requirement IDs when identifying issues. See report-templates.md for complete report templates