要件トレーサビリティ表を作りカバレッジを検証する

目標

インタビューのまとめから要件を抽出して番号を付け、要件追跡表(RTM)を作ったうえで、カバレッジと漏れている項目をスクリプトで検証できるようになります。

なぜ重要なのか

SIプロジェクトで要件IDは、要件定義書 → 画面定義書 → プログラム一覧 → テストシナリオ → 検収確認書をつらぬく唯一の糸です。この糸が切れた場所で、「開発されたのにテストされていない機能」と「要件にないのに作られた機能」が出てきます。そして、その発見は、いつも検収の2週間前に起こります。500件の追跡表を目で照合するのは不可能なので、現場では、結局誰かがこの検証をスクリプトにします。その誰かになるのが、このラボです。

ステップ

/root/reqディレクトリを作成して、/opt/lab/fixtures/si-process/req-src.mdを/root/req/req-src.mdにコピーします。
/root/req/requirements.csvを作成します。1行目はちょうどreq_id,category,title,priority,sourceで、データは8行です。req_idはREQ-001–REQ-008、priorityは상/중/하(韓国語の語は、順に「高」「中」「低」を意味します)のいずれか、categoryとsourceは空であってはいけません。
/root/req/rtm.csvを作成します。1行目はreq_id,screen_id,program_id,test_idです。画面IDはSCR-001形式、プログラムIDはPGM-001形式、テストIDはTC-001形式です。REQ-001–REQ-008がすべて最低1回登場する必要があります。
/root/req/coverage.shを作成します。引数を2つ(요구사항목록 추적표、韓国語の語は、順に「要件一覧」「追跡表」を意味します)受け取って、coverage=NN%の1行だけを出力します(小数点なしで切り捨て)。実行権限を付与してください。
/opt/lab/fixtures/si-process/rtm-vendor.csvは、協力会社が送ってきた追跡表です。ここに登場しない要件IDを、1行に1つずつ、昇順で/root/req/orphan.txtに書きます。
/root/req/change-log.csvを作成します。1行目はchg_id,req_id,before,after,requested_by,approved,dateです。2行以上で、approvedがYの行とNの行が、それぞれ最低1つずつある必要があります。req_idは、要件一覧にあるものだけを書きます。dateは2026-08-11の形式です。
/root/req/report.mdを作成します。## 요구사항 현황、## 커버리지、## 미추적 항목、## 변경 이력という4つのh2見出し(韓国語の見出しは、順に「要件の現況」「カバレッジ」「未追跡の項目」「変更履歴」を意味します)が必要で、ステップ4で計算したカバレッジの値と、ステップ5で見つけた要件IDが、本文にそのまま入っている必要があります。
/root/req/verify.shを作成します。引数を2つ(요구사항목록 추적표、韓国語の語は、順に「要件一覧」「追跡表」を意味します)受け取って整合性を検査し、問題がなければ1行目に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を作成します。1行目はちょうどreq_id,category,title,priority,sourceで、データは8行です。req_idはREQ-001–REQ-008、priorityは상/중/하(韓国語の語は、順に「高」「中」「低」を意味します)のいずれか、categoryとsourceは空であってはいけません。

インタビューのまとめの1つの段落に、複数の要件が混ざっています。「そして」「また」が出てきたら、たいてい分けるべき場所です。IDはREQ-001のように3桁で0を埋めないと、並べ替えが崩れます。

追跡表に設計・プログラム・テストを紐づける

/root/req/rtm.csvを作成します。1行目はreq_id,screen_id,program_id,test_idです。画面IDはSCR-001形式、プログラムIDはPGM-001形式、テストIDはTC-001形式です。REQ-001–REQ-008がすべて最低1回登場する必要があります。

1つの要件が、複数の画面に分かれることがあります。そのときは、行を複数書いてください。1つのセルにカンマで複数の値を入れると、CSVが壊れます。

カバレッジの計算スクリプト

/root/req/coverage.shを作成します。引数を2つ(요구사항목록 추적표、韓国語の語は、順に「要件一覧」「追跡表」を意味します)受け取って、coverage=NN%の1行だけを出力します(小数点なしで切り捨て)。実行権限を付与してください。

カバレッジ = 追跡表に1回でも登場した要件の数 / 全要件の数です。cutで列を取り出して、sort -uで重複を除いてから、wc -lで数えればよいです。整数の割り算に注意してください。

協力会社の追跡表の漏れ要件を探す

/opt/lab/fixtures/si-process/rtm-vendor.csvは、協力会社が送ってきた追跡表です。ここに登場しない要件IDを、1行に1つずつ、昇順で/root/req/orphan.txtに書きます。

両方の一覧を並べ替えておいて、commやgrep -v -F -fで差集合を求めます。目で照合すると、必ず間違えます。

要件変更台帳の作成

/root/req/change-log.csvを作成します。1行目はchg_id,req_id,before,after,requested_by,approved,dateです。2行以上で、approvedがYの行とNの行が、それぞれ最低1つずつある必要があります。req_idは、要件一覧にあるものだけを書きます。dateは2026-08-11の形式です。

変更台帳の核心は、「変更前/後」と「承認の有無」です。承認されなかった変更も、必ず記録として残しておけば、あとで根拠になります。

要件の現況レポート

/root/req/report.mdを作成します。## 요구사항 현황、## 커버리지、## 미추적 항목、## 변경 이력という4つのh2見出し(韓国語の見出しは、順に「要件の現況」「カバレッジ」「未追跡の項目」「変更履歴」を意味します)が必要で、ステップ4で計算したカバレッジの値と、ステップ5で見つけた要件IDが、本文にそのまま入っている必要があります。

レポートには、計算したカバレッジの数字と、漏れている要件IDを、そのまま引用してください。人が計算し直さなければならないレポートは、誰も読みません。

追跡表の整合性検証スクリプト

/root/req/verify.shを作成します。引数を2つ(요구사항목록 추적표、韓国語の語は、順に「要件一覧」「追跡表」を意味します)受け取って整合性を検査し、問題がなければ1行目にOKを出力して終了コード0、問題があればNGで始まる行を出力して終了コード1である必要があります。検査項目は、(1)追跡表のすべてのreq_idが要件一覧に存在すること、(2)test_idに重複がないこと、です。

検証することは2つです。(1)追跡表の要件IDがすべて要件一覧にあるか(幽霊要件の防止)。(2)同じテストIDが2回使われていないか。引数として受け取ったパスを検査するように作れば、ほかのプロジェクトでも使えます。