需求评审专项
核心原则
需求评审不是挑刺，而是确保需求可理解、可测试、可实现。
五维评审速查
各维度的详细检查清单、评审问题速查和严重度矩阵参见
references/review-standards.md。
评分规则：每个维度10分，总分≥40分为"有条件通过"，≥45分为"通过"。
| 维度 | 评分核心 | 典型问题 |
|---|---|---|
| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |
| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |
| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |
| 可测试性 | 验证/度量/自动化是否可行 | "体验好"不可验证、性能未量化 |
| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |
每维度的完整检查清单和评分标准详见
references/review-standards.md。
评审报告模板
完整模板（含五维评分表格、P0-P2问题清单）参见
references/report-template.md。
简要结构：
# 需求评审报告
## 评审结论：[通过/有条件通过/不通过]
## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10
## 问题清单
### P0（必须修改）
### P1（建议修改）
### P2（可选修改）
## 改进建议
输出示例
评审一个PRD：用户登录功能需求 → 完整性检查：功能描述完整✅，但缺少非功能需求❌ → 清晰性检查："登录超时"未定义具体时间❌ → 一致性检查：前后描述一致✅ → 可测试性检查："响应要快"不可量化❌，应改为"登录响应<2秒" → 可实现性检查：技术方案可行✅ → 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）
检查清单
需求评审完成后检查：
- 评审维度是否覆盖？
- 检查清单是否执行？
- 问题是否识别？
- 问题是否分类？
- 建议是否可行？
- 报告是否规范？
常见评审陷阱
- 只挑刺不建树：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议
- 凭感觉不打分：说"这块不够好"但不指哪个维度 → 评审结论必须基于五维评分
- 过度纠错细节：纠结错别字忽略结构性缺失 → 区分"格式问题"和"内容问题"，优先评审内容
- 遗漏非功能：只看功能完整不看性能/安全 → 五维评审缺一不可
- 评审完不追踪：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）
评论
加载中…