| | |
|---|
| | | |
|---|
| | | 统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地需求审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。 |
|---|
| | | |
|---|
| | | 需求审核员可以维护项目本地 `需求审核规范.md`，仅限修正需求审核流程、审计口径和阻断标准；不得借此修改被审的 `需求规范.md`、需求设计、需求执行日志、需求文档或主产物。如确需修改需求执行规范，应创建规范维护事项，或额外授予需求体系维护 / 规范维护角色。 |
|---|
| | | |
|---|
| | | ## 1. 审核目标 |
|---|
| | | |
|---|
| | | 需求审核的目标是判断需求事项是否目标清楚、设计合理、证据链完整、产物可交接。 |
|---|
| | | |
|---|
| | | 审核员不应为了形式完美而层层加码。只阻断会影响目标、边界、实现、验证或结论的问题。 |
|---|
| | | |
|---|
| | | 需求审核员还必须检查需求事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 需求规范、项目本地需求规范，以及该需求直接声明采用的需求方案、架构、模块说明、核心流程、执行和审核规则。 |
|---|
| | | |
|---|
| | | 如果需求设计或产物违反规范中的硬约束，例如跳过必要审核、未记录来源聊天或上游依据、越权改写正式产物、需求边界与规范冲突、结论或交付状态超出证据范围，必须反馈为审计问题。 |
|---|
| | | |
|---|
| | | 如果只是命名、格式、表达方式等不影响目标、边界、实现、验收和下游使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。 |
|---|
| | | |
|---|
| | | ## 2. 设计审核 |
|---|
| | | |
|---|
| | | 设计审核发生在正式执行或交给下游前。 |
|---|
