需求评审

从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求"评审这份需求"、"看看这个PRD写得怎么样"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说"需求评审"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

需求评审专项

核心原则

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

五维评审速查

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

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

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

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

评审报告模板

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

简要结构：

markdown

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

输出示例

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

五维评审判定示范（pass/fail 对照）：

维度	PASS 示例	FAIL 示例	判定要点
完整性	"支持用户名+密码登录、验证码、密码找回，含异常场景"	"用户能登录系统"（无边界/异常/非功能）	主流程+分支+异常+非功能是否齐
清晰性	"密码错误3次锁定15分钟"	"密码错误多次后锁定"（多次=？锁定多久=？）	数量/时间/条件是否有具体值
一致性	全文用"验证码"表述，前后一致	前文"短信验证码"后文"图形验证码"	术语/规则/数据定义前后是否矛盾
可测试性	"登录响应时间<2秒（P95）"	"响应要快"	指标是否可量化、可观测
可实现性	"基于现有统一认证服务实现"	"接入自研AI人脸识别（当前无此能力）"	技术方案在当前栈是否可行

检查清单

需求评审完成后检查：

• 评审维度是否覆盖？
• 检查清单是否执行？
• 问题是否识别？
• 问题是否分类？
• 建议是否可行？
• 报告是否规范？

常见评审陷阱

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