情報をつなげることの必要性
説明が容易になる
人に何かを説明する時には、話をつなげて一貫性のある話として展開できることが大事です。RDRAの要件定義では各情報につながりがあるので、そのつながりを使って説明することで自然に分かりやすい内容になります。
システム価値を説明することは、システム化のゴールを説明することになります。「何のためにこのシステムを作るのか」。「それは誰のためか」、そしてそのために「関わる外部のシステムにはどのようなものがあるのか」を説明します。
次にその価値を実現するための業務フローや利用シーンを説明します。その説明が「確かに効果的である」と感じられればシステムを取り巻く環境を定義できたことになります。この時の説明のポイントは業務の一連の流れに無理がないこととシステムとの接点が明確になっていることです。
ここまででシステムを取り巻く環境とその環境が実現したいことを表したことになります。
今度はシステムとの接点を人と外部システムの2つの面から説明します。
システムの使われ方をユースケースを使って説明し、そこで実際に使われるインターフェースとして個々の画面と帳票の役割を説明します。
外部システムとのインターフェースは、イベントとして情報のやりとりと受け渡される情報とを共に説明します。
最後は機能とデータをシステム境界とつなげて説明します。ユースケースを実現するために必要なものとして機能を説明し、画面・帳票やイベントで受け渡される情報を満足するものとしてデータを説明します。システム境界を満足するためのつじつまを合わせているのが、「機能」と「データ」です。
これでアクターからデータまでをつなげて説明することができます。
要件の決め方が決まる
要件定義は関係者が集まり、方向性を検討することが大事です。しかし、要件を定義する方法が明確でない場合は、その進め方をめぐって混乱しがちです。情報をつなげて要件を定義することは要件を組み立てる方法を示していることになります。これにより要件を明らかにする手順と方法が決まることになります。手順が決まれば作業をスムーズに進めることができます。
要件を決めるにあたっては必ず意見が分かれる場面があります。そのときにも4つの視点が役に立ちます。4つの視点は各々外側に向かってWhyを表す構造になっています。
例えばシステムはシステム境界に依存しているので、システムの内容がシステム境界を決めることになります。「システム境界を実現するためにはこのシステムが必要になる」という考え方です。
従って、システムの「機能」で意見がまとまらないときは「ユースケース」まで戻って意見の調整を図ります。システム境界で了解が取れればシステムの機能とデータは自ずと決まってきます。このように意見の対立が起きた場合には1つ外側の視点で合意を取り付け、意見の対立を調整します。これにより無理強いせずにシステマティックに要件を定義することができます。
情報源
RDRAの詳しい情報は著書『要件定義マニュアル』をご参照ください。
今回ご紹介したUML用のテンプレートは「リレーションシップ駆動要件分析サイト」から無料でダウンロードできます。
第1話で要件定義の構造を示し、今回は要件定義をどのように表現するかを示しました。次回は紹介したUMLの各モデルを要件定義工程でどのように使うかをご紹介します。
