システム
システム境界を実現するのがシステムです。システムとの接点である「ユースケース」を実現するための「機能」を明らかにし、入出力情報で示された情報を満足するための「データ」を明らかにします。
ここで扱う「機能」とはプログラムに直結するものではなく、システムの特徴を伝えるための論理的な機能となります。実際のプログラムにマッピングするためにはアーキテクチャ設計をした後にプログラムへとブレークダウンすることになります。
「データ」についてもRDBのテーブルを表すものではなく、あくまでもシステム境界で示された情報を満足し、かつ機能との関係上必要なもののみを洗い出します。
最後に「機能」と「データ」をつなぎその関係性をCRUD（Create、Read、Update、Delete）として表現します。
| システム価値 | システム価値として以下の3つの情報を明らかにする ・システムに関わる人をアクター（役割）として洗い出す ・システムに関わる外部システムを洗い出す ・要望をあつめ要求へと構造化し重要なものを要件としてまとめる |
| システム外部環境 | システムを取り巻く環境を明らかにし、システム価値で示した目的、価値をどのように実現するかを以下の3種類の情報で明らかにする。 ・業務フロー：価値を実現するための業務を流れとして表現する ・利用シーン：業務フローが書けないような場合はシナリオとして利用シーンを書く ・概念モデル：ビジネス上重要な概念を構造的に表現する |
| システム境界 | システムとの接点を表すユーザーインターフェースとシステムインターフェースの2つに別れそれぞれに情報を定義する。 ユーザーインターフェース ・ユースケース：人との接点をユースケースで表す ・画面・帳票：人との接点における入出力情報として画面と帳票を明らかにする システムインターフェース ・イベント：外部システムとのやりとりの単位を表す ・プロトコルモデル：外部システムとのやりとりの一連の手順を状態を使って整理する システム境界ではシステムの接点でやりとりされる情報とそのタイミングを明らかにする。 |
| システム | システムは以下の機能とデータを明らかにする。 ・機能：システム境界を実現するために必要な論理的な機能 ・データ：機能を実現するために必要な情報（システム境界の入出力情報を満足する情報） 機能の整合性を確保するのがデータ。システム価値から始まる関連は最後にデータにつながり、最終的な整合性のよりどころとなる。 |
依存関係を利用する
4つの視点は単純な分類ではなく相互に依存関係を持っています。この依存関係こそがRDRAのもっともユニークな特徴です。
最初に説明したとおり、要件定義工程は要件を定義するための仕組みを持たないとすぐに混乱します。その混乱を避ける方法がこの依存関係にあります。
依存されているものから先に手をつけると物事はスムーズに進みます。例えば「業務フロー」はアクターに依存します。洗い出されたアクターが行う作業を流れにそって整理することでフローの設計がスムーズにいきます。
このことから依存関係を利用することで要件定義の手順が明らかになります。
次に依存関係を使うことで要件の決定を論理的に行うことができます。
打ち合わせなどで要件を決めるときに意見が分かれることが多々あります。そのような時に、発言力のある人の意見や声の大きい人の意見が採用されるようでは、論理的な決定とはいえません。
意見が分かれているときは、前提を合わせることが肝心です。その前提が依存関係にあります。システムの「機能」について意見が合わないときはシステム境界の「ユースケース」で合意が得られるかを確認します。「ユースケース」で合意が得られていれば、対立する「機能」の中からより「ユースケース」と自然な関係にある方を選べばいいことになります。
つまり、要件定義の4つの視点では（図4参照）は内側の視点は外側の視点に依存します。合意が得られない場合は、その外側の視点に立ち戻って合意を得てから、再度内側の視点で議論することが有効です。
このように仕様決定のための方法を持つことでスピーディでシステマティックな要件が定義できるようになります。
今までの説明では「基本的な考えは分かるけど実際にどうすればいいんだ」という声が聞こえてきそうです。今回は4つの視点を中心に要件定義の基本構造を説明しました。次回はこの4つの視点をUMLを使って表現する方法をご紹介します。
