これは何か
要件追跡表は、要件ごとに、元の要望・設計・連携・プログラム・テスト・変更の履歴とのつながりを記録する成果物です。
要件一覧が「どんな要件があるか」を示すのに対し、要件追跡表は「その要件がどこで作られ、どこで確かめられたか」を示します（04-05 要件はどこからどこまで追跡するのか）。
なぜ作るか
- 要件が作られ、確かめられたかを確認できる
- 要件が変わったとき、影響する設計やテストを探せる
- 障害が起きたとき、元の要件までさかのぼれる
誰が使うか・いつ作るか
- 使う人：要件の担当、設計・開発・テストの担当、変更を判断する人
- 一般的には、要件を確定するときに作り始め、設計・テスト・変更のたびに更新します
- アステリア案件の要件追跡表の実際の列・粒度は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
追跡の規模に関係する記載
- 約1,500件の要件
- 約36本のシステム連携（個別に定義されているのは IF-01〜IF-12）
- 関連する成果物：REQ-002 要件一覧、REQ-005 変更要求書、REQ-006 要件確定記録
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 追跡表の行
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
| 要件ID | 出どころ | 設計 | 連携 | テスト | 結果 | 変更履歴 |
|---|---|---|---|---|---|---|
| REQ-FUNC-0123 | 経理業務の要望（例） | 仕訳作成の設計（例） | 会計への仕訳の連携（例） | 仕訳の連携テスト（例） | 合格（例） | 変更要求あり（例） |
| REQ-FUNC-0124 | 営業業務の要望（例） | 契約取込の設計（例） | 契約情報の連携（例） | （空欄） | — | — |
要件ID・内容はすべて教材上の例です。2行目のテスト欄の空欄は、「まだつながっていない」ことを示す例として置いています。
何を書いてはいけないか
- 確かめていないのに、つながっているように書く
- 古い版の設計やテストの番号を、更新せずに残す
- 空欄を、理由を確かめずに「対象外」で埋める
どこを見るか
- すべての要件に、テストの欄が埋まっているか
- 空欄の理由が分かるか（未実施・対象外・記入漏れ）
- 変更のあった要件で、設計・テストの欄も更新されているか
- 要件一覧と、要件の数・番号が一致しているか
- 追跡の粒度が、テストを選び出せる細かさになっているか
赤信号
- テストの欄の空欄が、テスト工程の終わり近くになっても多い
- 変更履歴があるのに、テストの結果の日付が変更より前のまま
- 要件一覧と追跡表で、要件の数が合わない
- 表の最終更新が、何週間も前
関係するUnit・危機演習
- Unit：04-04 要件に番号を付ける理由、04-05 要件はどこからどこまで追跡するのか、04-06 途中で要件が変わったらどうするのか、10-01 テストは何のためにするのか
- 危機演習：CR01 要件定義が終わらない（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
「この要件追跡表と要件一覧・テスト一覧を比べ、①追跡表にない要件、②テスト欄が空欄の要件、③変更履歴のあとにテストをやり直していない可能性がある要件、を挙げてください。つながりを推測で埋めないでください。」
REVIEW
- 比べた3つの表が、同じ時点の版か
- AIが「つながりあり」と判断した根拠が、表に書かれているか
- 空欄の理由を、AIが決めつけていないか
人間が判断すること
- 追跡の粒度
- 空欄の要件をテスト対象にするか、対象外とするか
- 追跡に抜けがある状態で、次の工程へ進むか
いつ使うか
この教材では STAGE 04｜1,500件の要件を管理する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この表から、ある要件を変えたときにやり直すテストを選び出せますか？