RTM (要件トレーサビリティ マトリックス) は、BA が次の 4 つの質問に答えるのに役立つ表です。
- この要件はどのようなビジネス目標から来ていますか?
- この要件はどのストーリー/仕様に変換されましたか?
- この要件はテスト ケースによって検証されましたか?
- この要件はもうリリースされましたか?
プロジェクトが小さい場合、RTM は単純なシートにすることができます。プロジェクトが大規模な場合、RTM は Jira、Azure DevOps、TestRail、または要件管理ツールに常駐することがあります。重要なのはツールではなくトレース能力です。
1. RTM が必要になるのはどのような場合ですか?
次の場合には RTM が必要です。
- ステークホルダーが多いですね。
- 要件は大きく変わります。
- プロジェクトにはコンプライアンスがあります。
- ベンダーまたは複数のチームが共同で構築します。
- BA は QA/UAT の適用範囲を証明する必要があります。
- リリースバージョンが多数あります。
小さな機能ごとに RTM を重くする必要はありません。しかし、重要な機能を備えた RTM は、要件の欠落を回避したり、価値のなくなったものの構築を回避したりするのに役立ちます。
2. ミニマリスト RTM には何が含まれますか?
単純なテンプレート:
| フィールド | 意味 |
|---|---|
| ビジネス目標 ID | ビジネス目標 |
| 要件 ID | 要件コード |
| 要件の説明 | 要件の説明 |
| 出典 | ステークホルダー、ポリシー、会議、文書 |
| 優先事項 | しなければならない/すべき/できるか、MoSCoW |
| ユーザーストーリー / 仕様 | リンクチケットまたはSRSセクション |
| テストケース | テスト ケースをリンクする |
| ステータス | ドラフト/承認/開発中/テスト済み/リリース |
| 変更リクエスト | 変更があった場合は CR リンク |
| オーナー | 責任者 |
3. RTM の例
機能: オンライン相談をスケジュールします。
| 目的 | 要求ID | 要件 | 出典 | ストーリー | テスト | ステータス |
|---|---|---|---|---|---|---|
| OBJ-01 ホットライン割引 30% | BR-001 | 顧客はオンラインで自分の予定を予約します | カスタマーケアワークショップ | US-101 | TC-101 | リリース |
| OBJ-01 | SR-001 | 利用可能なスロットをサービス/日ごとに表示 | SRS v1.0 | US-102 | TC-102 | テスト済み |
| OBJ-02 ノーショー削減 | SR-002 | カレンダーのリマインダーを 24 時間前に送信 | 運営方針 | US-110 | TC-110 | 開発中 |
| OBJ-03 コンプライアンス | NFR-003 | 管理者がスケジュールを変更したときの監査ログ | コンプライアンスレビュー | US-120 | TC-120 | 承認済み |
この表を見るだけで、どの要件がテスト済みか、どの要件がまだ開発中か、どの要件が準拠まで追跡されているかがわかります。
4. 前方へのトレースと後方へのトレース
フォワードトレース
ビジネス目標から下へ:
Objective -> Business Requirement -> System Requirement -> User Story -> Test Case -> Release
「この目標にはどのような要件が含まれますか?」という質問に使用されます。
逆方向トレース
チケットまたはテストケースから次のように進みます。
Bug/Test/Story -> Requirement -> Objective
「なぜこれを作るのですか？」とよく尋ねられました。
ストーリーの目的を追跡できない場合は、そのストーリーがスコープ クリープである可能性があります。
5. RTM はアジャイルに必要ですか?
はい、でも軽いはずです。
アジャイルでは、必ずしも長い正式な RTM ファイルを作成する必要はありません。以下を使用して追跡できます。
- エピックリンク。
- Jira 課題のリンク。
- ラベル。
- 説明内の要件 ID。
- テスト ケースのリンク。
- Confluence の仕様ページ。
Jira ストーリーの例:
Business Objective: OBJ-01
Requirement: SR-001
SRS: Booking SRS v1.2, section 3.1
Test Cases: TC-101, TC-102
UAT Scenario: UAT-05
6. RTM による変更制御
要件が変更された場合:
- 変更リクエストIDを作成します。
- 変更の理由を記録します。
- 影響の評価: ストーリー、テスト ケース、API、データ、トレーニング、リリース。
- RTM を更新します。
- 要件がベースラインである場合は、承認を申請します。
たとえば:
CR-014: Cho phép khách hủy lịch trước 2h thay vì 4h.
Impact:
- BRULE-003 thay đổi.
- US-115 cần update.
- TC-115 cần update expected result.
- Email template hủy lịch cần update.
- Training CSKH cần cập nhật.
7. チェックリスト RTM
- 各要件には一意の ID があります。
- 各要件には出典があります。
- 各要件には優先順位があります。
- 重要な要件にはテスト ケースが含まれます。
- 要件には変更履歴のあるベースラインがあります。
- 要件までストーリー/チケットを追跡します。
- テスト ケースは合格基準まで遡ります。
- リリース ノートには出荷時の要件が記載されています。
- 対象外の項目は別途記載します。
8. よくあるエラー
エラー 1: RTM は詳細すぎるため、誰も更新しません
良好な RTM とは、使用されている RTM のことです。チームが 30 列を更新できない場合は、最も重要な 8 ～ 10 列まで削減します。
エラー 2: ソースがありません
ソースのない要求は非常に危険です。口論が起こったとき、BA は誰に相談すればよいのかわかりません。
エラー 3: 要件をストーリーまでトレースし、テストまではトレースしない
テストまで追跡しない場合、要件が検証されたことを証明したことにはなりません。
予約のためのより完全な RTM の例
| 要求ID | 要件 | ルール | デザイン/API | テストケース | UAT シナリオ | ステータス |
|---|---|---|---|---|---|---|
| REQ-001 | ゲストには、今後 14 日間の利用可能なスロットが表示されます。 | BR-001 | GET /consultants/{id}/slots | TC-001 | UAT-001 | 承認済み |
| REQ-002 | 顧客は利用可能なスロットを予約します。 | BR-002 | POST /appointments | TC-002、TC-003 | UAT-002 | 承認済み |
| REQ-003 | 確認されたスロットは他の顧客には表示されません。 | BR-003 | スロットロック設計 | TC-004 | UAT-003 | 承認済み |
| REQ-004 | 顧客は予約時間の少なくとも 4 時間前に予約を変更します。 | BR-004 | PATCH /appointments/{id}/reschedule | TC-005、TC-006 | UAT-004 | 印刷レビュー |
| REQ-005 | 顧客は予約の少なくとも 4 時間前に予約をキャンセルします。 | BR-005 | PATCH /appointments/{id}/cancel | TC-007 | UAT-005 | 印刷レビュー |
| REQ-006 | 予約後にシステムから確認メールが送信されます。 | BR-006 | 通知サービス | TC-008 | UAT-006 | 承認済み |
| REQ-007 | コンサルタントは、日ごとの予約スケジュールを表示します。 | BR-007 | コンサルティングカレンダーページ | TC-009 | UAT-007 | 草案 |
変更リクエストの例:
CR-014: 企業は、スケジュール変更ルールを 4 時間から 2 時間に変更したいと考えています。
RTM による影響:
REQ-004アップデートが必要です。BR-004閾値を変更します。- 検証APIが変更されました
PATCH /appointments/{id}/reschedule。 TC-005、TC-006、UAT-004期待される結果を更新する必要があります。- エラーメッセージのUIコピーを「4時間」から「2時間」に変更する必要があります。
- 顧客は手動サポートを受ける前に 2 時間以内に電話するため、顧客サービス SOP を更新する必要があります。
このため、RTM は、作成しただけで忘れてしまったファイルではなく、バックログとともに存続する必要があります。
練習問題を練習する
5 つのユーザー ストーリーがある機能を選択します。列を含む RTM を作成します。
- 目的
- 要件ID
- 要件
- ソース
- ストーリー
- 合格基準
- テストケース
- ステータス
次に、自分自身を確認してください。目的に当てはまらないストーリーはありませんか?まだテストケースがない要件はありますか?
参照元
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
- 実務者向けの PMI ビジネス分析: https://www.pmi.org/shop/p-/book/business-analysis-for-practitioners-a-practice-guide/00101570601
- IEEE/ISO/IEC 29148-2018: https://standards.ieee.org/ieee/29148/6937/
結論
RTM は管理文書ではありません。ご要望に応じた位置決めシステムです。範囲が変更されたり、リリースが近づいたり、欠陥が現れたり、関係者が「なぜこれを構築するのか」と尋ねたりした場合、RTM は BA が記憶ではなく証拠で答えるのに役立ちます。