需求审核规范
创建人员：Codex
文件职责：定义需求体系的设计审核、产物审核、复审、阻断标准和审核员权限边界。
管理规范/模板：../../全局规范.md；需求规范.md；需求审核规范.md。
引用文件：需求规范.md；需求审计报告模版.md；需求问题记录模版.md。
记录方式：全局需求审核规范；审核口径变化时更新。
统一依赖：本规范必须同时遵守 ../../全局规范.md 和 ../project-doc/项目规范.md；项目本地需求审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
1. 审核目标
需求审核的目标是判断需求事项是否目标清楚、设计合理、证据链完整、产物可交接。
审核员不应为了形式完美而层层加码。只阻断会影响目标、边界、实现、验证或结论的问题。
2. 设计审核
设计审核发生在正式执行或交给下游前。
必须检查：
- 来源聊天记录或上游依据是否写入需求总纲。
- 需求目标是否清楚。
- 需求设计是否能满足目标。
- 输入、输出、消费方是否清楚。
- 边界和不做事项是否清楚。
- 验收方式是否合理。
- 如果要进入开发，需求是否符合
需求规范.md。
- 如果要进入实验或案例分析，是否写清要验证什么。
2.1 需求方案审核
大量需求修改时，需求审核员必须先审核需求方案文档。
检查重点：
- 修改背景是否清楚。
- 修改范围是否清楚。
- 修改前后口径是否清楚。
- 影响哪些需求文档、模块、流程是否清楚。
- 是否有需求文档改写清单。
- 是否存在直接改需求会漏项或冲突的风险。
需求方案审核通过后，才能进入需求文档书写流程。
2.2 三大文档审核
第一版复杂需求交付时，需求审核员必须审核：
- 架构文档。
- 模块说明文档。
- 核心流程文档。
检查重点：
- 架构是否说明整体结构和模块关系。
- 模块说明是否说清功能、作用、边界和上下游。
- 核心流程是否说清输入到输出的流转顺序。
- 三大文档之间是否冲突。
- 三大文档是否足以指导后续需求文档拆分。
三大文档审核通过后，才能进入需求文档书写流程。
3. 产物审核
产物审核发生在需求文档、策略说明或规则说明完成后。
必须检查：
- 产物是否按设计完成。
- 产物路径是否写入需求执行日志。
- 产物是否能被下游理解。
- 结论等级是否清楚。
- 是否存在和来源聊天要求不一致的地方。
- 是否存在会导致下游走两条路线的模糊点。
- 如果是需求文档，是否已对照需求方案或三大文档做一致性检查。
- 如果存在需求方案或三大文档，需求是否漏写必须实现的内容。
- 如果不存在需求方案或三大文档，是否说明不适用且理由合理。
4. 阻断问题
以下问题必须阻断：
- 没有来源或来源和目标不一致。
- 目标不清导致无法设计。
- 输入输出不清导致下游无法执行。
- 边界不清导致实现或实验范围失控。
- 未审核就要求进入开发。
- 将草案、讨论或未确认内容写成正式需求。
- 需求验收方式缺失，无法判断是否完成。
5. 不应阻断的问题
以下问题通常不应阻断：
- 不影响理解的措辞问题。
- 非关键格式偏好。
- 输出变量名和内部变量名不同，但输出合同清楚。
- 可后续优化的低影响项。
- 不影响下游执行的小型说明缺失。
6. 审计记录
需求审核员发现的问题主记录写入 需求审计报告.md。
非审计人员发现的问题写入 需求问题记录.md。
如果问题需要长期跟踪，可以在问题记录中建立索引，但不能替代审计报告的主记录。
7. 审核结论
审核结论只能是：
- 通过。
- 不通过，需修改。
- 暂缓，需补信息或补实验/案例。
审核不通过时，必须说明阻断原因和最小必要修复方向。
