問題の歴史：
要件トレーサビリティは、ビジネスの期待とシステムの実際の実装の間の乖離を防ぐためのツールとして生まれました。当初、アナリストは手動チェックリストに頼っていましたが、それは非常に非効率的でした。
問題点：
トレーサビリティが欠如すると、異なるレベルの要件間の関係が失われます：ビジネス目標 → 機能要件 → 技術要件 → テストシナリオ。これにより、エラー、"失われた"要件、質の低い実装が発生します。
解決策：
要件トレーサビリティは、マトリックス、専門ツール（Jama、DOORS、Jira/Zephyr）、およびテンプレートを使用して、関係のチェーンとして構築されます：
トレーサビリティマトリックスを作成します。最も基本的な構造は：
| ビジネス目標 | 機能要件 | テストシナリオ |
|---|---|---|
| BC-1 | FR-1 | TC-1 |
ツール内でアーティファクトにタグ付けを行います。
すべてのレベルでの変更に応じて、チェーンの見直しを行う必要があります — 関係が必要です。
定期的にレビューを行い、目標に関連付けられていない"ぶら下がり"要件またはテストを特定することが重要です。
重要な特徴：
小規模プロジェクトでは、トレーサビリティマトリックスなしで済ませることができますか？
いいえ、小規模プロジェクトでもトレーサビリティの欠如は要件の喪失につながることがよくあります。
プロジェクトの初めに一度だけトレーサビリティを構築すれば十分ですか？
いいえ、マトリックスは要件やテストが変更されるたびに定期的に更新する必要があります。
トレーサビリティはテストの完了にだけ影響しますか？
いいえ、設計から保守までのすべての段階で重要であり、変更の影響を評価し、作業を計画するのに役立ちます。
ネガティブケース：
プロジェクトでトレーサビリティマトリックスを構築しなかったため、テスターは仕様のみを参照しました。いくつかの要件が実装されましたが、チェックされなかったため、製品の機能が期待通りに動作しませんでした。
プラス：
マイナス：
ポジティブケース：
別のプロジェクトでは、生きたトレーサビリティマトリックスが維持されていました。すべての要件はテストやビジネス目標と関連付けられ、変更はすべて追跡されました。無視された機能や"未記述"のテストはありませんでした。
プラス：
マイナス：