做需求追溯表并验证覆盖度

目标

从访谈整理稿中提取需求并编号，制作需求跟踪表（RTM），然后用脚本验证覆盖率和遗漏项。

为什么重要

在 SI 项目中，需求 ID 是贯穿需求定义书 → 画面定义书 → 程序清单 → 测试场景 → 验收确认书的唯一一条线。这条线断掉的地方，就会冒出“已开发但未测试的功能”和“需求中没有却被做出来的功能”。而且这些问题总是在验收前 2 周才被发现。500 条的跟踪表不可能靠肉眼逐条对照，所以在现场，最终总会有人把这项验证写成脚本。这个实验就是让你成为那个人。

步骤

创建 /root/req 目录，并将 /opt/lab/fixtures/si-process/req-src.md 复制为 /root/req/req-src.md。
创建 /root/req/requirements.csv。首行必须恰好是 req_id,category,title,priority,source，数据为 8 行。 req_id 取 REQ-001 到 REQ-008，priority 为 상/중/하（韩文，依次意为“高”“中”“低”）之一， category 和 source 不能为空。
创建 /root/req/rtm.csv。首行为 req_id,screen_id,program_id,test_id。画面 ID 采用 SCR-001 格式，程序 ID 采用 PGM-001 格式，测试 ID 采用 TC-001 格式。 REQ-001 到 REQ-008 每个至少出现一次。
创建 /root/req/coverage.sh。接收两个参数（요구사항목록 추적표，占位符依次为需求清单与跟踪表），只输出一行 coverage=NN%（不带小数，向下取整）。请赋予它执行权限。
/opt/lab/fixtures/si-process/rtm-vendor.csv 是合作方发来的跟踪表。将其中没有出现的需求 ID 按升序、每行一个写入 /root/req/orphan.txt。
创建 /root/req/change-log.csv。首行为 chg_id,req_id,before,after,requested_by,approved,date。至少 2 行，且 approved 为 Y 的行和为 N 的行各至少有一行。 req_id 只能使用需求清单中已有的 ID。date 采用 2026-08-11 格式。
编写 /root/req/report.md。必须包含 ## 요구사항 현황、## 커버리지、 ## 미추적 항목、## 변경 이력 这四个 h2 标题（韩文，依次意为“需求现状”“覆盖率”“未跟踪项”“变更记录”），正文中要原样包含第 4 步计算出的覆盖率数值和第 5 步找出的需求 ID。
创建 /root/req/verify.sh。接收两个参数（요구사항목록 추적표，占位符依次为需求清单与跟踪表），执行一致性检查：没有异常时，首行输出 OK 并以退出码 0 结束；有异常时，输出以 NG 开头的行并以退出码 1 结束。检查项：(1) 跟踪表中的所有 req_id 都存在于需求清单中，(2) test_id 没有重复。

参考

CSV 处理几乎都可以用 head -1、tail -n +2、cut -d, -f1、sort -u、comm -23 组合完成。
常见错误 1：在 CSV 字段里放逗号。标题里请用 / 或空格代替逗号。
常见错误 2：coverage.sh 把表头行也算进去了。别忘了 tail -n +2。
常见错误 3：没有给脚本赋予执行权限（chmod +x）。

准备工作目录和原始文件

创建 /root/req 目录，并将 /opt/lab/fixtures/si-process/req-src.md 复制为 /root/req/req-src.md。

交付物工作的第一条规则是“不要动原件”。请把 /opt/lab/fixtures 下面当作只读，并另做一份工作副本。

编写需求清单 CSV

创建 /root/req/requirements.csv。首行必须恰好是 req_id,category,title,priority,source，数据为 8 行。 req_id 取 REQ-001 到 REQ-008，priority 为 상/중/하（韩文，依次意为“高”“中”“低”）之一， category 和 source 不能为空。

访谈整理稿的一个段落里混着好几条需求。出现“而且”“另外”的地方，大多就是该拆分的位置。ID 要像 REQ-001 这样用 0 补足三位，排序才不会乱。

在跟踪表中关联设计、程序和测试

创建 /root/req/rtm.csv。首行为 req_id,screen_id,program_id,test_id。画面 ID 采用 SCR-001 格式，程序 ID 采用 PGM-001 格式，测试 ID 采用 TC-001 格式。 REQ-001 到 REQ-008 每个至少出现一次。

一条需求可能拆分到多个画面。这时请写成多行。如果在一个单元格里用逗号塞入多个值，CSV 就会被破坏。

覆盖率计算脚本

创建 /root/req/coverage.sh。接收两个参数（요구사항목록 추적표，占位符依次为需求清单与跟踪表），只输出一行 coverage=NN%（不带小数，向下取整）。请赋予它执行权限。

覆盖率 = 在跟踪表中至少出现过一次的需求数 / 需求总数。用 cut 取出列，用 sort -u 去重，再用 wc -l 计数即可。注意整数除法。

找出合作方跟踪表中遗漏的需求

/opt/lab/fixtures/si-process/rtm-vendor.csv 是合作方发来的跟踪表。将其中没有出现的需求 ID 按升序、每行一个写入 /root/req/orphan.txt。

把两边的清单都排好序，再用 comm 或 grep -v -F -f 求差集。靠肉眼对照一定会出错。

编写需求变更台账

创建 /root/req/change-log.csv。首行为 chg_id,req_id,before,after,requested_by,approved,date。至少 2 行，且 approved 为 Y 的行和为 N 的行各至少有一行。 req_id 只能使用需求清单中已有的 ID。date 采用 2026-08-11 格式。

变更台账的核心是“变更前/后”和“是否批准”。未获批准的变更也一定要留下记录，日后才有依据。

需求现状报告

编写 /root/req/report.md。必须包含 ## 요구사항 현황、## 커버리지、 ## 미추적 항목、## 변경 이력 这四个 h2 标题（韩文，依次意为“需求现状”“覆盖率”“未跟踪项”“变更记录”），正文中要原样包含第 4 步计算出的覆盖率数值和第 5 步找出的需求 ID。

报告中请直接引用计算出的覆盖率数字和遗漏的需求 ID。让人重新计算一遍的报告，没有人会去读。

跟踪表一致性验证脚本

创建 /root/req/verify.sh。接收两个参数（요구사항목록 추적표，占位符依次为需求清单与跟踪表），执行一致性检查：没有异常时，首行输出 OK 并以退出码 0 结束；有异常时，输出以 NG 开头的行并以退出码 1 结束。检查项：(1) 跟踪表中的所有 req_id 都存在于需求清单中，(2) test_id 没有重复。

要验证的有两点。(1) 跟踪表中的需求 ID 是否全都在需求清单里——防止出现幽灵需求。(2) 同一个测试 ID 是否被用了两次。脚本要检查作为参数传入的路径，这样在其他项目中也能复用。