リレーションシップ駆動要件分析(RDRA)とは？
要件定義において、重要な要素が3つあります。
- 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている
- 「整合性」：各要件の整合性が取れている
- 「表現力」：それぞれの要件が分かりやすく表現されている
複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。
リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。
RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います。
よくあるように要件をリストでただ並べるのではなく、UMLの視覚効果を利用することで表現力を実現します。
要件定義についてはこちら↓
「ハッピーな開発🎉をするための、プロジェクトにおける要件定義の役割」
要件定義の構造
RDRAでは、要件定義の構成要素として「システム価値」「システム外部環境」「システム境界」「システム」の4つを定義します。
要件定義は要件を決めていく工程ですが、要件を決めていく際には必ず前提条件が必要になります。
まず、システムを作ることで実現したいビジネス的な価値が存在し、それを利用する関係者や関連サービスがあります。
そして、ユーザーがシステムを利用する際の接点となるインターフェースがあり、それを通して実際に動くシステムがあります。
このようにシステムを開発する際にはトップダウン式の依存関係があり、それらは4つのステップに分類することが可能です。
- 「システム価値」：価値を生み出す対象
- 「システム外部環境」：システムを取り巻く環境
- 「システム境界」：システムとユーザーの接点
- 「システム」：システムそのもの
4つのステップは、このように内側の要素が外側に依存するような関係になっています。
システム価値を定めたら、それを満たすように内側の要素を考えていくことで網羅性のある要件定義を行うことができます。
システム価値
システム価値では、システムと関係する人や外部システムを捉え、要求を明らかにします。
ここではコンテキストモデルと要求モデルを考えます。
コンテキストモデル
コンテキストモデルでは、システムと関係する人や外部システム、目的を明らかにします。
ここで洗い出されたアクターが、以後のモデルで利用されることになります。
要求モデル
要求モデルではシステムに対する要望をヒアリングし、要求としてまとめます。
ビジネスサイドのレビューでは要求のダイアグラム、開発サイドでは要件のダイアグラムを利用すると効果的になります。
システム外部環境
システム外部環境では、システムを取り巻く環境(業務や作業)を明らかにします。
ここでは、業務モデルまたは利用シーン、概念モデルを考えます。
業務モデル
業務モデルは、業務に関わる人や組織が行う一連の作業を整理したモデルです。
コンテキストモデルで登場したアクターが、どのように作業を行なっているかを明らかにします。
利用シーン
もしシステムがツールやユーティリティといった、特定の作業を支援するようなシステムの場合、システムが利用されているその場面を理解することが重要になり、これが利用シーンとなります。
システム利用の状況を具体的にイメージできるよう表現し、チーム内で利用シーンについて合意が取れるようにします。
概念モデル
概念モデルは、業務で使われる用語の意味や関係性を示したモデルです。
これにより、その領域固有の表現や概念を共通認識として議論できるようになります。
システム境界
システム境界では、システムとの接点を明らかにします。
アクターと関わるものがユーザーインターフェース、外部システムと関わるものがシステムインターフェースとなります。
ここでは、ユースケースモデル、画面・帳票モデル、イベントモデル、プロトコルモデルを考えます。
ユースケースモデル
アクターがシステムと関わる部分をユースケースとして洗い出します。
ここで洗い出したユースケースを集めたものが、ユーザーから見たシステムの全体像ということになります。
画面・帳票モデル
画面や帳票として入出力される情報をまとめたモデルが画面・帳票モデルとなります。
ここでは情報の単位や項目を洗い出し、具体的な画面や操作感などは別に資料を作成する必要があります。
イベントモデル
イベントモデルは、外部システムとのやり取りを把握するためのモデルです。
連携するデータや受け渡しのタイミングなどを記述します。
プロトコルモデル
画面・帳票モデルやイベントモデルの入出力の順番や条件をルール化するものがプロトコルモデルです。
システムが持つデータは、ある時点でのシステムの状態を表し、その状態を変化させる起点が入出力となります。
システム
ここまででシステムに必要な前提条件が揃ったので、システムの機能とデータを明らかにします。
ここでは、機能モデル、データモデルを考えます。
機能モデル
ユースケースやイベントを実現するための機能を把握するモデルが機能モデルです。
ユースケースモデルとは別にこれを作成することで、純粋にシステムとして必要な機能を適切な名前で表現することができます。
データモデル
システムで扱う情報を把握するモデルがデータモデルです。
データの項目や関係性を洗い出しますが、ここではDBについてまでは考える必要はありません。
各ダイアグラムの関係
各ダイアグラムは関係性を持っています。
例として、コンテキストモデルで登場したアクターや外部システムは、ユースケースモデルのアクターやイベントモデルの外部システム、業務モデルや利用シーンのアクターと結びつけられます。
このように複数のダイアグラムを関連づけていくことで、要件定義の整合性を保ちます。
リレーションシップ駆動要件分析はあくまで数ある要件定義フレームワークの1つなので、会社ごとの状況や領域に合わせて自分達に合った要件定義の方法を探すのも良いかと思います！🎉