检查需求规格说明书模板的追溯字段和变更记录，核心做法是先把字段清单和判定标准定下来，再抽样逐条核对，最后用可复算的覆盖率给出结论。检查对象是模板的字段设计与记录要求，不是文档排版。下面给出三类追溯方向、两组字段表、两个覆盖率公式和一个完整算例，读者可以直接照做。
要点总览（TL;DR）
- 检查追溯字段和变更记录，先固定字段清单与判定口径，再抽样逐条核对，最后用覆盖率给出可复算的结论。
- 追溯字段要覆盖三个方向：需求到来源、需求到设计或任务、需求到测试用例，每个方向都要能定位到唯一编号与对应条目。
- 变更记录区分“有记录”和“记录可用”，版本号、变更时间、修改人、变更原因、影响范围、评审结论六项齐全且对应到具体需求条目才算合格。
- 覆盖率按“齐全条数÷抽样条数×100%”计算，分母为零时说明本期无对象、不计算比率；字段为空记为缺失，不按默认正确计入。
- 覆盖率只反映字段与记录的齐全程度，不直接等于需求质量或变更受控水平，模板合格还需结合实际填写与评审记录判断。
检查目标：模板要能支撑哪几类追溯与变更核验
这次检查要回答一个问题：拿这份模板写出来的需求规格说明书，能不能支撑日常的追溯查询和变更还原。判断对象是模板中的字段设置、必填约束和记录要求，结论落到具体条目上，不停留在“格式是否规范”。
追溯字段要覆盖三个方向。第一是向上追溯，每条需求能定位到它的来源，例如用户访谈记录、上级需求、合同条款或缺陷单。第二是横向追溯，每条需求能对应到承接它的设计文档或开发任务。第三是向下追溯，每条需求能对应到验证它的测试用例。三个方向都要求找到唯一编号和对应条目，只写“见相关文档”不算可查。
变更记录要支撑三件事：每次修改可还原到修改前后的内容，可追责到具体修改人，可评估影响范围。对应到字段上，就是版本号、变更时间、修改人、变更原因、影响范围、评审或批准结论六项要素。
检查结论建议分三档输出。全部抽样条目符合判定标准为通过；存在缺失但缺失项集中在非关键字段、且有明确整改计划为有条件通过；关键追溯方向断裂或变更记录无法对应到具体需求条目为不通过。无论哪一档，都要附上需整改的具体条目清单，写明条目编号、缺失字段和整改要求，避免结论只有一句话。
追溯字段清单与判定标准
追溯字段的检查表可以按下面的结构建立。字段名一列固定下来后，后续每次检查都用同一张表，结果才可比较。
| 字段名 | 用途 | 是否必填 | 编号规则要求 | 判定标准 |
|---|---|---|---|---|
| 需求唯一编号 | 作为所有追溯关系的锚点 | 必填 | 全文档唯一，发布后不随内容修改而变更 | 存在且必填为合格；存在但可空为有条件合格；缺失为不合格 |
| 来源编号 | 向上追溯到需求来源 | 必填 | 引用来源系统的编号或文档章节号，可定位到具体条目 | 同上 |
| 父/子需求编号 | 表达需求层级与拆分关系 | 有层级时必填 | 引用已存在的需求编号，不出现悬空引用 | 存在且引用有效为合格；引用指向不存在编号为不合格 |
| 关联设计或任务编号 | 横向追溯到承接工作 | 必填 | 引用设计文档编号或任务编号，可反查 | 同上 |
| 关联测试用例编号 | 向下追溯到验证活动 | 必填 | 引用用例库编号，支持一条需求对多条用例 | 同上 |
判定时有三点需要固定口径。编号规则要唯一且稳定，需求内容修改后编号不变，否则历史追溯关系会断。跨文档引用要可定位，写“参见设计文档”属于不可定位，写“设计文档 DS-012 第 3.2 节”才算合格。字段存在但允许为空，只能判为有条件合格，因为空值在实际使用中会直接造成追溯断链。
如果模板用表格承载这些字段，还要检查表格是否随需求条目逐行填写，而不是在文档开头集中列一张汇总表。汇总表在需求增删后容易失同步，逐条承载更利于核对。
变更记录字段与证据要求
变更记录检查要区分“有记录”和“记录可用”。只写一句“本次修改了需求描述”，属于有记录但不可用；能说清改了什么、为什么改、影响哪些条目、谁批准，才算可用。
| 要素 | 记录内容 | 可接受的证据形式 | 常见不合格情形 |
|---|---|---|---|
| 版本号 | 修改前后的版本标识 | 变更历史条目、基线版本对比 | 只写“最新版”，无版本序列 |
| 变更时间 | 修改发生的日期 | 变更历史条目的时间戳 | 时间缺失或与评审时间矛盾 |
| 修改人 | 具体责任人 | 变更历史条目、评审签到记录 | 只写团队名或角色名 |
| 变更原因 | 触发修改的业务或技术原因 | 变更申请单、评审记录 | 写“优化”“调整”等无法判断的表述 |
| 影响范围 | 受影响的关联需求、用例、发布计划 | 关联条目清单、影响分析记录 | 只写“无影响”但无分析依据 |
| 评审或批准结论 | 谁评审、结论是什么 | 评审记录、批准意见 | 有修改无评审，或评审结论未回填 |
六项要素齐全，并且能对应到具体需求条目，判为合格。影响范围一项要特别留意：它应当列出受影响的关联条目编号，而不是一句定性描述。评审结论要能看出通过、有条件通过或退回，只留一个签名无法判断结论。
证据形式建议在检查时同步收集。变更历史条目证明记录存在，评审记录证明决策过程，基线版本对比证明修改内容可还原。三类证据中缺少任何一类，相应要素只能判为有条件合格。
检查步骤：抽样、核对与计算覆盖率
执行步骤按以下顺序进行，每一步都留下可复查的记录。
- 确定抽样范围与时间窗。例如抽取最近一个发布周期内新增或修改的 20 条需求、8 条变更记录，写明起止日期。
- 按字段表逐条核对。每条需求对照追溯字段表打勾，每条变更对照六项要素打勾，缺失项记录条目编号和缺失字段名。
- 记录缺失项。字段为空记为缺失，不按“默认正确”计入；引用指向不存在的编号也记为缺失。
- 计算覆盖率。按下面两个公式分别计算，保留一位小数。
- 汇总整改项。按缺失字段归类，写明整改责任人和复算时点。
两个覆盖率公式如下：
- 追溯字段完整率 = 字段齐全的需求条数 ÷ 抽样需求条数 × 100%，单位为百分比，统计口径为本次抽样时间窗内的需求条目。
- 变更记录完整率 = 六项要素齐全的变更条数 ÷ 抽样变更条数 × 100%，单位为百分比，统计口径为同一时间窗内的变更记录。
分母为零时要单独处理。本期无变更时，变更记录完整率不计算，改为逐条说明“本期无变更记录，未做比率统计”；抽样范围内没有可核对对象时同理。把零分母写成 0% 或 100% 都会误导读者。
在工具中执行这套核对时，需求条目、变更历史和评审记录需要能互相对应。ONES Wiki 支持页面组关联项目，需求与文档互相对应，并记录所有页面版本、支持随时查看与回滚，可作为核对版本与变更历史的依据；ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，需求变化时可沿关联关系分析受影响的任务、测试和交付内容。这些能力帮助检查者取到证据，覆盖率仍要按本文口径自行计算。
算例：一份模板的抽样核对过程
设定某项目在 3 月 1 日至 3 月 31 日的时间窗内，抽样 20 条需求和 8 条变更记录，用前文的字段表逐条核对。
追溯字段核对结果：20 条需求中，需求唯一编号全部存在且必填；来源编号有 2 条为空；关联设计或任务编号有 1 条指向已删除的任务编号；关联测试用例编号有 3 条为空，其中 1 条与来源编号为空的是同一条需求。按“任一必填字段缺失即该条不齐全”的口径，不齐全的需求共 5 条，字段齐全 15 条。
追溯字段完整率 = 15 ÷ 20 × 100% = 75.0%。
变更记录核对结果：8 条变更中，版本号、变更时间、修改人三项全部齐全；变更原因有 1 条只写“优化”；影响范围有 2 条只写“无影响”且无分析记录；评审结论有 1 条缺失。按“六项要素齐全才算合格”的口径，不合格变更共 3 条，合格 5 条。
变更记录完整率 = 5 ÷ 8 × 100% = 62.5%。
结论表述可以写成：本次抽样追溯字段完整率 75.0%，变更记录完整率 62.5%，判定为有条件通过。需整改条目包括需求 R-007、R-012 补填来源编号，R-015 修正失效的任务引用，R-018、R-019 补填测试用例编号；变更 C-003 补充具体变更原因，C-005、C-006 补充影响范围分析，C-008 补做评审并回填结论。整改完成后按同一时间窗和同一口径复算，两个比率均达到 100% 方可转为通过。
结果解读与检查限制
覆盖率反映的是字段与记录的齐全程度，不能直接当作需求质量或变更受控水平的结论。一份模板字段齐全，写出来的需求仍可能描述含糊、验收标准缺失；变更记录六项齐全，也不代表每次变更都经过了充分的影响分析。指标回答的是“记录是否完整”，不是“内容是否可靠”。
结果的可比性依赖口径一致。抽样范围、时间窗、判定标准任何一项变化，都会改变比率。例如把“字段存在但可空”计为合格，完整率会明显上升；把时间窗从一个月拉长到一个季度，变更记录的构成也会变化。跨项目或跨版本比较时，要先确认字段表、判定口径和时间窗相同，否则只做各自项目的纵向对比。
模板合格不等于执行到位。检查时建议同时抽取若干条实际填写的需求条目，核对字段是否真的被使用，而不是模板里有、文档里空着。评审记录和变更历史条目的实际存在情况，比模板设计更能说明执行水平。
复检时点建议与整改闭环绑定：整改完成后立即按原口径复算一次，下一个发布周期结束时再抽查一次，确认没有回退。若连续两个周期完整率稳定，可适当降低抽样比例，把检查重点转向内容质量。
常见问题
抽样时发现某条需求的来源编号为空，但需求描述里写明了来源，这条算合格吗？
按字段口径判为不合格。检查对象是模板字段是否被实际填写，描述里提到来源属于正文内容，无法被稳定检索和反查。建议把该条记为缺失，整改要求是补填来源编号并指向可定位的条目，例如访谈记录编号或上级需求编号。若来源确实无法编号，应在模板中约定替代写法并统一执行，而不是个案处理。
变更记录只有修改人和时间，没有评审结论，能算有条件合格吗？
要看变更的性质。六项要素中评审或批准结论缺失，说明这次修改的决策过程没有留下证据，通常只能判为不合格。若该变更属于错别字、格式一类不影响需求含义的修订，可以在模板中单列“编辑性修订”类别，明确这类修订不需要评审，但要在记录中标注类别。把编辑性修订和实质性变更混在同一套判定标准里，会让完整率失真。
两个覆盖率都达到100%，是不是说明这份模板可以直接推广？
不能直接下这个结论。覆盖率只说明抽样条目里字段和记录齐全，不说明字段设计是否合理。例如模板要求填写的关联测试用例编号，如果实际项目中测试用例迟迟不建立，字段齐全也可能只是填了占位编号。推广前建议再核对两点：字段是否真的被用于查询和影响分析，评审记录是否与实际决策对应。这两点无法从覆盖率看出来。
不同项目用同一份模板检查，结果可以直接横向比较吗？
需要先确认口径一致。字段表、判定标准、抽样范围和时间窗任何一项不同，比率就不可直接比较。例如一个项目把“字段存在但可空”计为合格，另一个项目计为不合格，完整率会明显不同。建议横向比较前统一字段表和判定口径，并写明各自的抽样时间窗；口径无法统一时，只做各项目自身的纵向对比。
整改后复算，抽样范围要不要换一批需求？
建议先用原抽样范围复算，确认缺失项是否补齐，这样能直接对应整改清单。原范围全部达标后，再在下一个时间窗抽取新样本做一次独立检查，验证整改是否形成习惯。只换新样本复算，会掩盖原缺失项是否真正修复；只查原样本，又看不出新条目是否重复出现同类问题。两步结合更稳妥。
