システムの視点

４つの視点の最後はシステムの視点です。
ここでは機能とデータを明らかにします。
オブジェクト指向を採用する場合はドメインモデルも作成します。

前回の繰り返しになりますが、システムは何らかの入力と出力があり、その入力と出力のつじつまを合わせるのが機能とデータだと考えることができます。

　入力　→　　　システム　　→　出力
　　　　　　　（機能、データ）

システムへの入力と出力は沢山あり、様々なタイミングでやりとりされます。

それらの入力と出力の背後で働くのが機能になります。
そして、そのつじつまを合わせるのがデータもしくはドメインになります。

入力されたものをそのまま、もしくは加工してデータとし、出力はそのデータをやはりそのまま、もしくは加工して出力します。
入力と出力はタイムラグがあるので、データを永続化する必要があります。

つじつまを合わせるというのは各々の入出力のタイミングでデータの整合性をとることを意味します。

それを機能モデルとデータモデル、ドメインモデルを使って整理します。

　機能モデル：http://k-method.jp/sample/sample_info_site/index.htm
　データモデル：http://k-method.jp/sample/sample_info_site/index.htm

要件定義として扱う機能は「このシステムの機能は〜〜〜です」のようにシステムの働きを理解出来るような粗い粒度の機能の名前になります。
あくまでもシステムが行うことを表しているもので、プログラムに対応するものではありません。
従ってここで洗い出した機能を分割してプログラムを明らかにするわけではありません。
プログラムへ落とし込むのはアーキテクチャが決まった後になります。

ここで疑問を持たれる方がいるかもしれません。

　　「要件定義でデータまで明らかにする必要があるのか？」　　

　　　　　　ということです。

粗い要件定義であればデータを定義する必要はないかもしれません。

RDRAでデータもしくはドメインを定義するのは、要件定義の整合性を高めるためです。

システム価値、システム外部環境、システム境界とつながりをもって洗い出した情報は最終的にデータもしくはドメインにつながります。

ここでつじつまが合わなければ、今度はシステムからシステム境界、システム外部環境、システム価値へと遡って情報の整合性を確認しながら定義情報としての整合性や網羅性を確認します。

以上　４回に渡ってRDRAの４つの視点について説明してきました。

RDRAの肝は正にこの４つの視点にあります。
個々の視点での各モデルの定義方法が重要ではなく、この４つの視点の意味を理解し、その上で適切なモデルを作成することが重要です。

次回以降はこの４つの視点を使っていかに要件定義工程をまとめていくかを説明します。