2007年05月26日

実現機能一覧の作り方

 パッケージベースのシステムの要件定義では、通常、実現機能一覧表、すなわち、実現機能とカスタマイズ内容を説明する一覧表を作ります。
 先日、他のメンバが作った表をレビューしていて、自分がどのようにこの表をチェックしているかの手順が明確になりました。

 まず横軸。カスタマイズの内容が妥当かどうかを判断できる論理構成になっているかどうか?
 そのための構成としては、横軸を実現したい機能(ToBe)、パッケージの標準機能(AsIs)、カスタマイズの内容(実現方法)にするのが一般的だと思います。すなわち、実現したい機能と事実としてのパッケージの標準機能を説明しつつ、その差分が、カスタマイズ内容の根拠となるように横軸を構成します。

 次は縦軸。縦軸は実現したい機能をリストアップするわけですが、適当に思いつくままリストアップしたのではなく、漏れなくリストアップしたことということが示されているかどうか?
 そのことをどうやって示すかというと、実現機能をMECEで分類し、分類が論理的に漏れていないことを示すしかありません。
 では、どのようにMECE分類すればよいのか?
 これには、オブジェクト指向的な分類が簡単だと思います。すなわち、システムに存在する論理的なオブジェクト(データ)をリストアップし、それぞれに対して、そのオブジェクトに対する一般論としての操作をリストアップする。それを分類として、実現したい機能を当てはめていく。
 オブジェクトは「ユーザ情報」「ドキュメント情報」というようにそのシステムで扱うオブジェクトを挙げていきます。これはシステムごとに違ってきます。これは一見すると至極簡単なことのように思えますが、パッケージベースの要件定義では往々にして陥る罠があります。それは、パッケージが提供しているデータモデルとしてのオブジェクトと、実現したい機能で扱う論理的なオブジェクトがよく似通っているために、両者を混同してしまうということです。このカテゴリを混同してしまうと本来1つの機能として表現されるべき内容が複数箇所に散在したり、同じような内容が何箇所にも繰り返しでてくるということになったりします。
 オブジェクトに対する操作は、特定の情報が格納されている場所に対して一覧・検索、登録、削除、更新、参照 が考えられます。
 windowsのファイルシステムで言えば、ファイル・フォルダ情報が格納されている場所がDドライブだとします。Dドライブに対しては、Dドライブ直下のファイル・フォルダの一覧、ファイル・フォルダの登録、特定のファイル・フォルダの名前などのプロパティ等の更新、特定のファイル・フォルダの名前などのプロパティ等の更新、特定のファイル・フォルダの削除ができますね。切り取りや貼り付けなどの操作も、この5つのどれかの分類に入れられるはずです。ここでポイントになるのは、フォルダのような入れ物のオブジェクトはそれに対してまた一覧・検索、登録、削除、更新、参照の操作ができるということです。
 オブジェクトとそれに対する操作の分類ができて、それに実現機能がきちんとマッピングされていれば、分類をみただけで漏れなくリストアップされていることが分かります。

 表の縦軸、横軸の検証が終わってから、最後に表の中身をチェックします。
 この表は、実現機能の1行1行について、実現したい機能は何々、パッケージ標準機能は何々、(つまりその差は何々)、だから(その差を埋めるための)カスタマイズ内容は何々という論理がきちんと成り立っている必要があります。そのためには、ただ実現したい機能とパッケージ標準機能を書けばよいというわけではなく、その差がひとめで分かるように書いてある必要があります。具体的には、それぞれで違うところだけを違うように書いて、それ以外の同じところはまったく同じに書いてあるかという観点で、2つの文章を比較してチェックすればよいわけです。

 つまり実現機能一覧表のチェックポイントは、「これで全部だという根拠」と「差分の根拠」がちゃんと示されているかということだと思います。
posted by koppe at 12:31| Comment(0) | TrackBack(0) | 要件定義の現場から | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/42944366

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。