シリーズ: モデルベース要件定義手法RDRA
- 要件定義手法RDRAの概要と全体像
- RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
- RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる（本記事）
- RDRAによる要件定義の進め方〜第3フェーズ：整合性・網羅性を確認し精度を上げる（近日公開予定）
- RDRAの成果物と設計フェーズとの連携（近日公開予定）
- RDRA Agentの紹介（近日公開予定）
- RDRAと見積（近日公開予定）
TRACERYプロダクトマネージャーの haru です。
RDRAによる要件定義は、業務からシステムへと段階的に構造を組み立て、最後に全体を統合的に検証するプロセスとして設計されています。
要件定義は主に次の3つのフェーズに分けて進めます。
- 第1フェーズ：枠組みを作る（議論の土台づくり）
- 第2フェーズ：要件を組み立てる
- 第3フェーズ：整合性・網羅性を確認し、精度を高める（要件定義の仕上げと仕様化の準備）
前回のRDRAによる要件定義の進め方〜第1フェーズ：枠組みを作るでは、第1フェーズの進め方について説明しました。
第2フェーズは、開発対象システムの中心部分を定義する重要なフェーズであり、3つのフェーズの中でも最も時間をかけて取り組むべき段階です（参考書籍の『RDRA3.0 ハンドブック: 根拠を持った要件定義を素早く正確に』では、要件定義全体の約60％を充てることが推奨されています）。
この記事では、第2フェーズの進め方について解説します。
第2フェーズの進め方の概要と目的
第2フェーズでは、「システム要件定義」に該当するシステム境界レイヤーおよびシステムレイヤーを中心に具体化します。
画面やイベントなどユースケースを構成する要素に加え、情報・状態・条件といった要素を関係性に基づいて整理することで、システムの振る舞いと構造を明確に定義します。
第2フェーズで定義する主な要素およびモデルは、以下のとおりです（下図）。
- システム境界レイヤー
- 画面
- イベント
- 情報（システムレイヤーの参照）
- 条件（システムレイヤーの参照）
- タイマー
- システムレイヤー
- 情報（情報モデルの洗練）
- 状態（状態モデルの洗練）
- 条件
また、第2フェーズでは、主に以下の2つのアプローチで進めます（上図）。
- トップダウンで要件を組み立てる
- システム境界レイヤーからシステムレイヤーへと展開し、ユースケースを段階的に詳細化します。
- ボトムアップで詳細を見直す
- システムレイヤーの定義を具体化したうえで、システム境界レイヤーへと遡って整合性を確認し、開発対象システムの挙動を明確にします。
トップダウンで要件を組み立てる
ユースケースを起点とし、その実行に直接関与する要素を関連付けて明示します。
具体的には、画面、イベント、タイマーに加え、関与するアクターや外部システムをユースケースに関連付けます。
これにより、ユースケースがどの契機で開始され、誰が関与し、どのインターフェースを通じて実行されるのかが一貫した構造として表現されます。
ユースケースに関連付ける各要素の説明を下表に示します。
| 要素 | 説明 |
|---|---|
| 画面 | UI（画面や帳票等） |
| イベント | 外部のシステムやアクターとのインターフェース。 |
| タイマー | ビジネス上の締切（例：月末締、定時実施）。 |
| アクター | システムを利用する人や組織の役割。 |
| 外部システム | 連携が必要な既存システムや外部サービス。 |
画面、イベント、タイマーを定義し、ユースケースに関連付ける
ユースケースのインターフェースとなる画面やイベント、ならびに実行タイミングを規定するタイマーを、「BUC」シートの「関連モデル1」および「関連オブジェクト」列に記載します*1。
これにより、ユースケースがどの要素を契機として開始されるのかが構造として表現されます（下図参照）。
RDRA Graphで参照すると、ユースケースに画面およびイベントが関連付けられていることを確認できます（下図）。
アクター、外部システムを関連付ける
画面にはアクターを、イベントには外部システムまたはアクターを関連付けます。これらの関係は、「BUC」シートの「関連モデル2」および「関連オブジェクト2」列に記載します。
これにより、インターフェースを介して誰がどのように関与するのかが構造的に明示されます。
RDRA Graphで参照すると、ユースケースとアクターおよび外部システムとの関係が関連付けられていることを確認できます（下図）。
「BUC」シートでユースケースを定義していないアクティビティ（システムを使用しないアクティビティ）に対して「関連モデル2」および「関連オブジェクト2」を定義した場合、それらは当該アクティビティに関連付けられます（下図）。
ボトムアップで詳細を見直す
システムレイヤーを詳細化し、境界レイヤーとの整合性を検証します。（システムレイヤー→システム境界レイヤーのボトムアップ）。
システムレイヤーにおける情報・条件・状態を具体的に定義し、それらをユースケースに明示的に関連付けることで、ユースケースの処理内容が構造として明確になります。
さらに、システム境界レイヤーとシステムレイヤーが関係性に基づいて整理されることで、要件間の整合性が担保され、要件定義全体の精度とトレーサビリティが向上します。
情報の定義
情報を構造化し、設計する
「情報」シートを用いて情報要素を整理し、情報間の構造を明確にします。「関連」列では情報同士の関係を定義し、あわせて想定される属性も具体化します。
RDRA Graphで参照することで、情報間の関係構造を可視化できます。
この構造を基に、概念データモデルを整理し、基本設計プロセスにおけるデータベース設計へと自然に展開できます。
情報をユースケースに関連付ける
「BUC」シートの「関連モデル1」および「関連オブジェクト」列に、「情報」シートで定義した情報名を記載することで、ユースケースと情報を明示的に関連付けます。
これにより、各ユースケースがどの情報と関連しているのかを、構造として表現できます。
RDRA Graphで参照すると、ユースケースと情報が関連付けられていることを確認できます（下図）。
条件の定義
条件とは、業務上またはシステム上で適用されるビジネスルールや制約を指します。
これは、ユースケースの実行可否や処理分岐を規定する要素です。
第2フェーズでは、条件を体系的に抽出し、該当するユースケースに明示的に関連付けます。
これにより、ユースケースの分岐・制約が構造として整理されます。
条件の抽出
条件を抽出し、「条件」シートに整理して記載します（下図）。
ここでは条件の詳細化よりも、必要となるビジネスルールの網羅的な抽出に重点を置きます。
条件の具体的な定義や精緻化は、第3フェーズで実施します。
条件をユースケースに関連付ける
抽出した条件を「BUC」シートの「関連モデル1」および「関連オブジェクト」列に記載します（下図）。
「BUC」シートに記載した条件とユースケースの関係をRDRA Graphで参照すると、下図のように両者の関連構造が可視化されます。
これにより、各ユースケースに適用される条件の抜け漏れや整合性を俯瞰的に確認できます。
状態の定義
第2フェーズでは「状態」シートを第1フェーズの内容からさらに詳細化し、定義の精度を高めます。
状態をさらに洗い出すとともに、状態遷移の契機となるユースケースを「遷移UC」列に記載し、その遷移結果となる状態を「遷移先状態」列に記載します（下図）。
「状態」シートに記載した内容をRDRA Graphで参照すると、状態とユースケースとの関係および状態遷移の構造が、下図のように可視化されます。
これにより、状態遷移の整合性や、遷移に関係するユースケースとの関連を俯瞰的に確認できます。
最後に：第2フェーズの成果物の全体像
第2フェーズの成果物の全体像を下図に示しました。
第1フェーズでは、企画プロセスで検討された内容を前提に、「要求の確認」と「業務要件定義」を主に進め、システム全体の枠組みができあがります。
第2フェーズでは、第1フェーズで構築した枠組みに基づき、「システム要件定義」を具体化します。これは、RDRAにおけるシステム境界レイヤーおよびシステムレイヤーを詳細化するプロセスに相当します。
ユースケースを起点に、画面、イベント、タイマー、情報、状態、条件といった要素を整理し、それぞれを相互に関連付けていきます。これにより、業務の流れとシステム内部の振る舞いが一本の構造として結び付けられ、開発対象となるシステムの全体像が把握しやすくなります。
第3フェーズでは、システムレイヤーをさらに詳細化するとともに、全体の整合性・網羅性を検証し、要素間の矛盾や抜け漏れを確認し、仕様化に耐えうる精度へと引き上げます。
次回は、第3フェーズの具体的な進め方について解説します。
参考書籍
*1:シート記載上の注意：「BUC」シート内で同一のユースケースを複数行にわたって記載する場合、2回目以降の行では、「関連モデル1」および「関連オブジェクト」列は空白とします（例：上図のUC列「蔵書の貸出を登録する」）。
