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

短期間に分析する

　今回ご紹介する方法は画面数が100程度の中小規模なシステムを対象としています。システム関係者へのヒアリングが行える環境があり、材料（入出力情報とデータ）が揃っている場合は、手法とツールを使うことで、短時間でシステムの地図を作成できます。

　今回は要件定義ツール「要件のツボ」を使った方式を説明します。今回もプログラムそのものを調査するのではなく、システムの入出力を調べ、その使われ方を調べる方法です。「要件のツボ」も同じ考え方で作られており、情報の表現方法をそのまま活用できます。

対象とする情報

　既存システムの分析は、以下の6種類のデータと2つのモデルで表現します。

• 誰に： 「アクター」「外部システム」
• 何を行い： 「画面・帳票」「外部システムとの入出力」「機能」「データ」
• 何のために： 「ステートマシンモデル」「概念モデル」

　「要件のツボ」を使った場合は、システムの関係者を「アクター」「外部システム」で表現し、入出力情報として「画面・帳票」「イベント」「イベントデータ」を使い、システムは「機能」と「データ」で表現します。

　ステートマシンモデルはプロトコル（後述の「手続きにともなうルール化」を参照）という機能で代用し、概念モデルは用語集で代用します。

　扱える情報は前回紹介したUMLを使った方法とほぼ同じ（違いは画面にイベントを結びつけないこと）です。

　思考方法はUMLと「要件のツボ」では多少異なります。UMLはダイアグラム単位で図としてつながりを記述しますが「要件のツボ」では個々の要素を直接つなげるので、ダイアグラムのように1枚の図として表現する単位がありません。UMLではダイアグラム単位が表現の単位になるので、読み手と作り手は同じダイアグラムを見ることになり、作り手の表現力がそのまま読みやすさにつながります。「要件のツボ」は図としての要素がない分、要素のつながりにだけ集中でき、作成が容易になります。

　UMLのような汎用的なツールは柔軟性があり表現力も高いのですが、使いこなすには経験が必要です。一方専用ツールは柔軟性には劣りますが、初心者にも扱え、素早くまとめることができます。

材料を順次入力する

　既存システムの分析は、最初に入出力情報（画面・帳票、イベント、イベントデータ）とデータを洗い出すことから始めます。「要件のツボ」ではそれらのデータをアイコンではなくテキストとして入力します。

図1　洗い出した情報を順次入力する

　図1にあるように洗い出した情報の名前を順次登録します。この時情報は個々に分析せず、そのまま登録します。そして、ある程度材料がそろったところで分析を始めます。あくまでもシステム全体の視点から分析することが重要で、個々の情報を個別に分析することはしません。それを行うと時間がいくらあっても足りなくなるからです。

　材料（入出力情報とデータ）を集めることと、分析を分けることが大事です。