# 需求审核规范

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

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

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

## 1. 审核目标

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

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

需求审核员还必须检查需求事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 需求规范、项目本地需求规范，以及该需求直接声明采用的需求方案、架构、模块说明、核心流程、执行和审核规则。

如果需求设计或产物违反规范中的硬约束，例如跳过必要审核、未记录来源聊天或上游依据、越权改写正式产物、需求边界与规范冲突、结论或交付状态超出证据范围，必须反馈为审计问题。

如果只是命名、格式、表达方式等不影响目标、边界、实现、验收和下游使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。

## 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. 暂缓，需补信息或补实验/案例。

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