第3章 需求文档完整性检查清单：功能、非功能、约束条件、验收标准

适用场景

本章节适用于以下具体场景：

• 需求文档定稿前的质量门禁评审——在需求基线建立之前，对照清单逐项核查，确保无遗漏项进入开发阶段。
• 跨团队需求对齐会——产品、研发、测试、运维等多角色共同使用本清单，统一完整性判定口径。
• 需求变更后的补充审查——当已评审的需求发生变更时，使用本清单检查变更波及的范围是否被完整补充。

前置条件

• 需求文档已完成初稿编写，并通过了格式规范性自检。
• 评审团队已确认成员角色（需求分析师、技术负责人、测试代表、业务方代表）。
• 评审会议时间已预定，且文档至少提前 2 个工作日分发给所有评审人。
• 已确定本清单的记录人，负责填写《需求遗漏检查记录表》。

操作步骤

💡 提示：执行四维检查时，建议按 功能 → 非功能 → 约束条件 → 验收标准 的顺序进行，避免跳跃式检查导致遗漏。每个维度检查完成后，记录人立即标记状态，不做跨维度回溯。

步骤一：功能需求完整性检查

核对需求文档是否覆盖了所有预期的业务行为与用户交互路径。

• 业务用例覆盖——对照业务流程图或用户故事地图，逐一确认每个用例是否在文档中有对应的功能描述。
• 功能路径完整性——检查正常路径与备选路径（含异常分支）是否均有描述，避免只写主路径而遗漏分支逻辑。
• 功能依赖关系——识别功能之间的前置/后置依赖，确认文档中是否显式标注了依赖关系，防止因依赖缺失导致功能链断裂。

步骤二：非功能需求完整性检查

验证文档中对系统质量属性与运行约束的描述是否量化和可验证。

• 性能指标量化——响应时间、吞吐量、并发用户数等指标是否给出了具体的数值范围或阈值。
• 安全与合规要求——认证方式、权限模型、数据加密、审计日志等安全相关需求是否明确列出。
• 可用性与可维护性——系统可用性百分比、故障恢复时间、日志与监控接口等运维类需求是否被纳入文档。

步骤三：约束条件完整性检查

审查文档中是否明确了所有限制性的边界条件，避免后续设计与实现出现范围偏差。

• 技术栈约束——编程语言、框架版本、数据库类型、中间件选型等是否已指定。
• 业务与法规约束——行业标准、数据驻留要求、合规审计条款等是否已记录。
• 环境与集成约束——目标部署环境（私有云/公有云/混合）、外部系统集成方式、API 协议等是否已定义。

步骤四：验收标准完整性检查

确认每一个关键需求是否都关联了可测量、可测试的验收条件。

• 通过条件可测量——验收标准是否使用了可量化的指标（如“响应时间 ≤ 200 ms”）而非模糊表述（如“响应快”）。
• 测试覆盖映射——每个验收标准是否能对应到至少一个测试用例或测试场景。
• 临界状态定义——通过/失败的边界条件是否清晰，例如最大并发数下的行为、数据量达到上限时的表现。

输入输出物

类型	名称	说明
输入	需求文档（初稿）	待评审的完整需求说明，含功能、非功能、约束及验收标准章节。
输入	业务流程图 / 用户故事地图	用于功能覆盖度对照的参考材料。
输出	需求遗漏检查记录表	记录每个维度的检查结果、遗漏项描述及责任人。
输出	四维完整性检查报告	汇总各维度检查结论，给出文档完整性等级判定。

责任边界

角色	职责	输出物
需求分析师	提供需求文档并做逐条澄清，配合评审人定位遗漏项。	需求文档修订版
评审专家（主审）	主导四维检查，对照清单逐一判定完整性，给出整改意见。	四维完整性检查报告
记录员	实时填写检查记录表，标记遗漏项状态，会后分发跟踪。	需求遗漏检查记录表
测试代表	从测试可测性角度验证验收标准是否完整、可执行。	验收标准补充建议

记录材料

本章所需的标准记录模板如下，评审前由记录员准备并带入会议：

• 需求遗漏检查记录表（包含维度、检查项、结论、遗漏描述、责任人、状态列）。
• 四维完整性检查报告模板（汇总各维度通过率、主要遗漏项、整改建议）。

以下为检查清单模板的参考格式（JSON 结构，可导入协作工具使用）：

{
  "checklist": {
    "功能需求": [
      "业务用例是否全部覆盖",
      "功能路径（正常+异常）是否完整",
      "功能依赖关系是否显式标注"
    ],
    "非功能需求": [
      "性能指标是否量化",
      "安全与合规要求是否明确",
      "可用性与可维护性是否定义"
    ],
    "约束条件": [
      "技术栈约束是否列出",
      "业务与法规约束是否记录",
      "环境与集成约束是否说明"
    ],
    "验收标准": [
      "通过条件是否可测量",
      "测试覆盖是否映射",
      "临界状态是否定义"
    ]
  },
  "meta": {
    "文档版本": "v1.2",
    "评审日期": "2025-04-09",
    "记录人": "（姓名）"
  }
}

异常处理

异常情形	影响	处理方式
文档版本不一致	评审人手中的文档版本不同，导致检查结论冲突。	立即停止检查，由需求分析师确认唯一有效版本，重新分发并延后评审 30 分钟。
需求描述过于模糊	无法判定是否完整，检查项无法给出结论。	将该条目标记为“待澄清”，指定需求分析师在 2 个工作日内补充量化描述，重新提交审查。
某一维度完全缺失	文档结构不完整，无法执行该维度的检查。	记录为“严重遗漏”，暂停该维度检查，由需求分析师补充章节后再择机评审。
评审人中途离场	检查进度受阻，结论可能缺乏关键角色意见。	记录当前进度，预约补会；离场角色需在 1 个工作日内提交书面检查意见。

验收标准

本章节执行完毕后，必须同时满足以下所有条件方可判定为“通过”：

• ✅ 四维检查（功能、非功能、约束条件、验收标准）均已完成，无遗漏维度。
• ✅ 每个维度下的检查项均有明确的“通过 / 不通过 / 待澄清”结论。
• ✅ 所有“不通过”项均已记录遗漏描述、责任人和整改日期。
• ✅ 阻断性异常已全部解决，无未处理的版本冲突或维度缺失。
• ✅ 《需求遗漏检查记录表》经主审与需求分析师双方签字确认。