kanachi-blog

要件定義の構成要素

1. システム価値（システムが生み出す価値）
2. システム外部環境（システムを取り巻く環境）
3. システム接点（システムとの接点）
4. システム（システムそのもの）

要件定義とはシステムの価値を示し、その価値を生み出すシステムの外部環境を明らかにします。そしてその外部環境とシステムとの接点を明確にし、その接点を実現するシステムを定義することです。

1. システムの価値を明確化する
   1. システムに関わる人と外部システムを把握する
   2. システムへの要望をまとめる
   3. システムにはどのような人が関わり、そこにはどのような問題や課題、そして要望があり、最終的に何が実現されなければならないのかを明らかにする
2. システムの外部環境を把握する
   1. 業務一連の流れを支援する場合
      1. ビジネス的な価値に結びついているかを確認して業務フローを作成する
   2. 個々の作業を支援する場合
      1. システムを利用するシーンを捉える
   3. 両者の場合でも、ドメインの概念の整理はここで行う。
3. システム境界を把握する
   1. システムとの接点としての入出力情報
   2. その情報の入出力タイミング
   3. 入出力情報とタイミングのルール化
4. システムを把握する
   1. 機能を洗い出す
      1. システム境界で洗い出されユースケースから利用されるもの
      2. 外部システムからのイベントに対応するもの
   2. データを洗い出す

1. システムに関わるすべての関係者とすべての外部システムを洗いだす
2. 関係者の要望、要求を捉え、同時にシステムの目的・役割を導き出す
3. 上記関係者が関係する業務フローもしくは利用シーンをすべて洗い出す
4. 上記業務フローあるいは利用シーンに関わるシステムの接点(ユースケース・イベント)を洗い出す
5. すべてのユースケース、イベントに結びつく機能を洗い出す

RDRAでは要件を表現する手段としてUMLを拡張した表記方法を利用する。

UMLとはオブジェクト指向分析や設計モデリングで使用される標準的な表記法。

UML2.0では13種類のダイアグラムが存在するがRDRAでは、4種類（クラス図、ステートマシン図、ユースケース図、アクティビティ図）を使用する。

基本ダイアグラムは、４つのステップごとに要件定義に必要な情報が集められたもの。

関係ダイアグラムは、基本ダイアグラムの各情報を繋げて関係づけたもの。

システムに関係する人と外部システム、システムの目的・役割を明らかにする。

ここで別のモデルでも利用される、アクターを洗い出す。

システムに対する要望、要求をヒアリングし、そこから本質的な要求を明らかにするモデル。

コンテキストモデルのアクターに対応する、実際の人や組織から要望・要求を集めてくる。

要望は、ヒアリングしたことをそのまま記録したものとして作成します。次に、実際の要件分析に活用できるように「要望」から「要求」へと構造化する。

一連の作業の流れを表したモデルで、業務に関わる人や組織が担う作業を整理したモデル。

コンテキストモデルに現れたアクターが、どのように連携しながら業務を進めていくのかを明らかにし、一連の作業の流れを設計する。

アクターごとにレーンを設けて、アクティビティを洗い出す。

コンテキストモデルでのアクターの責務に即しているかチェックする

モデル化の対象が特定の作業を支援するシステムの場合は、システムが利用されている場面を描くことが有効。これが利用シーンモデル。

このモデルにはシステムが利用されている状況を具体的にイメージできる文章や絵を使って表現する。

業務の中で認識されている概念を表す用語の意味と、それらの関係をクラス図を使ってモデル化したもの。

概念同士の制約などもここで示す。

人とシステムが関わる部分をユースケースモデルとして洗い出す。

ここで洗い出すユースケースを集めたものが、ユーザーから見たシステムの全体像になる。

ユースケースの詳細化はここではまだ行わない。

業務モデルや利用シーンモデルをベースに中間モデルを作成することで、ユースケースを素早く洗い出すことが可能。

画面や帳票として入出力される情報を、ユーザーと接するインターフェース部分として把握する。

具体的には入出力される単位とその項目を明らかにする。

ユースケースモデルと業務モデルor利用シーンモデルから中間テーブルを作成すると効率よく作成ができる

外部システムとのやりとりを把握するために、イベントモデルを作成する。

通信電文などの資料が参考情報として利用される。

入出力（画面・帳票モデル、イベントモデル）との連携をルール化するのが、このプロトコルモデル。システムに対する入出力の順番と条件を状態を使ってルール化する。

UMLのステートマシン図を使って表現する。

ユースケースやイベントを実現する「機能」を洗い出すのが機能モデル。純粋にシステムとして必要な機能を、適切な名前で表現する。

システムの中で扱う情報をデータモデルとして表現する。

対象業務の情報構造をそのままシステムの情報構造として表現したもの。DDDとして知られる。

機能モデルはシステム境界が満足する機能を洗いだす。具体歴にはユースケースとイベントを実現する機能として洗い出す。同時に機能がどのデータ、ドメインと関係づいているかを明らかにする。

重要なビジネスルールを表現した任意のドキュメント。システムの動作原理となるようなルールや制約など、システム化にあたって考慮しておくことを指す。

システム価値からの関係

システム外部環境とシステム境界との関係

システム境界とシステムとの関係