要件定義ツールを使った既存システムの分析

モデルベースの手法でコストをかけずに既存システムを分析する（4）

情報を付加する

　登録した情報に新たな情報を付加することで、より深く対象を把握することができます。入出力に関係する登場人物を洗い出し、何のために使われるのかを考える材料とします。同じくビジネスとの接点を整理することでシステムの振る舞い（ビジネス上の手順）を明らかにします。

入出力に関わる登場人物を洗い出す

　洗い出した入出力情報を分析する方法の一つとして、「アクター」「外部システム」との関係を整理することがあげられます。「画面・帳票」がどのようなアクターに使われ、そのアクターの責務から「画面・帳票」の役割や働きを理解します。同じく「イベント」と関わる外部システムを明示することで「イベント」の役割が理解しやすくなります。

　まずはシステムに関わるアクターと外部システムを資料やヒアリングから洗い出し、「画面・帳票」に「アクター」を結びつけ、「イベント」に「外部システム」を結びつけます。これらの作業を行うことで入出力情報の役割が明確になります。

手続きにともなうルール化

　入出力とデータがつながったことでシステム全体のつながりは分かりました。しかし、入出力がどのような順番で利用され、実際の作業とどう関わっているかは整理されていません。

　手続きにともなうルール化とはビジネスで認識されている状態を元に、入出力の役割を明らかにするものです。第3話の図5で説明したものと同じです。

　図5は注文から出荷までの状態の変化とその遷移を示しています。これによりビジネス上認識している状態をどの画面を使って遷移しているかが分かります。

　「要件のツボ」では状態を定義し、状態間の遷移として画面とイベントをドラッグ＆ドロップで対応づけます。例えば図5を例に説明すると「注文前」「注文済」「在庫引当済」「出荷待ち」「出荷済」の5つの状態を表現しています。次に「注文前」状態に「注文登録」画面を割り当て次の状態として「注文済」を設定します。これで「注文前」から「注文済」への遷移を設定したことになります。このように一連の状態を遷移させる「画面・帳票」と「イベント」を設定できれば、ビジネス上の状態を変化させるシステムの入出力が明確になります。

　重要なことはシステムの仕組み上現れている状態（プログラムのロジック上必要となった状態）は省き、現場の担当者が把握している状態を洗い出すことです。ビジネス上認識されている状態と入出力をつなげていくことで、個々の入出力情報の使われ方が明らかになり、ビジネスとシステムの接点が明確になります。この作業（状態の洗い出しと遷移の割り当て）を繰り返すことでシステムに埋め込まれたビジネスルールを掘り起こすことができます。

図5　注文から出荷まちまでの状態