Qa Requirement Review

SKILL.md

---
name: qa-requirement-review
version: 1.6.0
description: >-
  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求"评审这份需求"、"看看这个PRD写得怎么样"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说"需求评审"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。

when_to_use: 用户说"需求评审"、"评审需求"、"需求质量"、"PRD评审"、"需求检查"、"需求写得好不好"、"评审这份需求"、需要评审需求文档、需求提交测试前预审时
allowed-tools: Read Grep Glob WebFetch
related_skills:
  upstream:
    - qa-input-validation        # 输入：输入验证结果
    - qa-critical-thinking       # 输入：批判性思维
    - qa-question-framework      # 输入：提问框架
  downstream:
    - qa-req-deconstruction      # 输出：评审结果用于需求解构
    - qa-test-strategy-design    # 输出：评审结果影响测试策略
references:
  - references/report-template.md
  - references/review-standards.md
input_format:
  required:
    - name: 需求描述
      type: string
      description: 功能需求的详细描述文本
  optional:
    - name: 业务背景
      type: string
      description: 业务目标和用户角色
    - name: 历史缺陷
      type: array
      description: 同类功能的历史缺陷记录
output_format:
  traceability:
    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）
    - - 关联需求ID（REQ-XXXX）
  structure:
    - review_report: 需求评审报告
    - completeness_score: 完整性评分
    - clarity_score: 清晰性评分
    - consistency_issues: 一致性问题清单
    - testability_assessment: 可测试性评估
error_recovery_guidance:
  on_failure: "识别到需求不完整时返回缺失清单，要求用户补充信息"
  retry_behavior: "用户补充信息后重新执行需求评审"
categories: ['Development','Requirements']
depth_requirement_quantification:
  reference_value: "根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3"
  minimum: "至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度"
---
# 需求评审专项

## 核心原则

需求评审不是挑刺，而是确保需求可理解、可测试、可实现。

## 五维评审速查

> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。

**评分规则**：每个维度10分，总分≥40分为"有条件通过"，≥45分为"通过"。

| 维度 | 评分核心 | 典型问题 |
|------|---------|---------|
| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |
| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |
| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |
| 可测试性 | 验证/度量/自动化是否可行 | "体验好"不可验证、性能未量化 |
| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |

> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。

## 评审报告模板

> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。

简要结构：
```markdown
# 需求评审报告
## 评审结论：[通过/有条件通过/不通过]
## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10
## 问题清单
### P0（必须修改）
### P1（建议修改）
### P2（可选修改）
## 改进建议
```

## 输出示例

**评审一个PRD：用户登录功能需求**
→ 完整性检查：功能描述完整✅，但缺少非功能需求❌
→ 清晰性检查："登录超时"未定义具体时间❌
→ 一致性检查：前后描述一致✅
→ 可测试性检查："响应要快"不可量化❌，应改为"登录响应<2秒"
→ 可实现性检查：技术方案可行✅
→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）

## 检查清单

需求评审完成后检查：
- [ ] 评审维度是否覆盖？
- [ ] 检查清单是否执行？
- [ ] 问题是否识别？
- [ ] 问题是否分类？
- [ ] 建议是否可行？
- [ ] 报告是否规范？

## 常见评审陷阱

1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议
2. **凭感觉不打分**：说"这块不够好"但不指哪个维度 → 评审结论必须基于五维评分
3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分"格式问题"和"内容问题"，优先评审内容
4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可
5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）