需求审核规范

创建人员：Codex
文件职责：定义需求体系的设计审核、产物审核、复审、阻断标准和审核员权限边界。
管理规范/模板：../../全局规范.md；需求规范.md；需求审核规范.md。
引用文件：需求规范.md；需求审计报告模版.md；需求问题记录模版.md。
记录方式：全局需求审核规范；审核口径变化时更新。

统一依赖：本规范必须同时遵守 ../../全局规范.md 和 ../project-doc/项目规范.md；项目本地需求审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。

需求审核员可以维护项目本地 需求审核规范.md，仅限修正需求审核流程、审计口径和阻断标准；不得借此修改被审的 需求规范.md、需求设计、需求执行日志、需求文档或主产物。如确需修改需求执行规范，应创建规范维护事项，或额外授予需求体系维护 / 规范维护角色。

1. 审核目标

需求审核的目标是判断需求事项是否目标清楚、设计合理、证据链完整、产物可交接。

审核员不应为了形式完美而层层加码。只阻断会影响目标、边界、实现、验证或结论的问题。

2. 设计审核

设计审核发生在正式执行或交给下游前。

必须检查：

1. 来源聊天记录或上游依据是否写入需求总纲。
2. 需求目标是否清楚。
3. 需求设计是否能满足目标。
4. 输入、输出、消费方是否清楚。
5. 边界和不做事项是否清楚。
6. 验收方式是否合理。
7. 如果要进入开发，需求是否符合 需求规范.md。
8. 如果要进入实验或案例分析，是否写清要验证什么。

2.1 需求方案审核

大量需求修改时，需求审核员必须先审核需求方案文档。

检查重点：

1. 修改背景是否清楚。
2. 修改范围是否清楚。
3. 修改前后口径是否清楚。
4. 影响哪些需求文档、模块、流程是否清楚。
5. 是否有需求文档改写清单。
6. 是否存在直接改需求会漏项或冲突的风险。

需求方案审核通过后，才能进入需求文档书写流程。

2.2 三大文档审核

第一版复杂需求交付时，需求审核员必须审核：

1. 架构文档。
2. 模块说明文档。
3. 核心流程文档。

检查重点：

1. 架构是否说明整体结构和模块关系。
2. 模块说明是否说清功能、作用、边界和上下游。
3. 核心流程是否说清输入到输出的流转顺序。
4. 三大文档之间是否冲突。
5. 三大文档是否足以指导后续需求文档拆分。

三大文档审核通过后，才能进入需求文档书写流程。

3. 产物审核

产物审核发生在需求文档、策略说明或规则说明完成后。

必须检查：

1. 产物是否按设计完成。
2. 产物路径是否写入需求执行日志。
3. 产物是否能被下游理解。
4. 结论等级是否清楚。
5. 是否存在和来源聊天要求不一致的地方。
6. 是否存在会导致下游走两条路线的模糊点。
7. 如果是需求文档，是否已对照需求方案或三大文档做一致性检查。
8. 如果存在需求方案或三大文档，需求是否漏写必须实现的内容。
9. 如果不存在需求方案或三大文档，是否说明不适用且理由合理。

4. 阻断问题

以下问题必须阻断：

1. 没有来源或来源和目标不一致。
2. 目标不清导致无法设计。
3. 输入输出不清导致下游无法执行。
4. 边界不清导致实现或实验范围失控。
5. 未审核就要求进入开发。
6. 将草案、讨论或未确认内容写成正式需求。
7. 需求验收方式缺失，无法判断是否完成。

5. 不应阻断的问题

以下问题通常不应阻断：

1. 不影响理解的措辞问题。
2. 非关键格式偏好。
3. 输出变量名和内部变量名不同，但输出合同清楚。
4. 可后续优化的低影响项。
5. 不影响下游执行的小型说明缺失。

6. 审计记录

需求审核员发现的问题主记录写入 需求审计报告.md。

非审计人员发现的问题写入 需求问题记录.md。

如果问题需要长期跟踪，可以在问题记录中建立索引，但不能替代审计报告的主记录。

7. 审核结论

审核结论只能是：

1. 通过。
2. 不通过，需修改。
3. 暂缓，需补信息或补实验/案例。

审核不通过时，必须说明阻断原因和最小必要修复方向。