実現機能一覧の作り方
パッケージベースのシステムの要件定義では、通常、実現機能一覧表、すなわち、実現機能とカスタマイズ内容を説明する一覧表を作ります。 先日、他のメンバが作った表をレビューしていて、自分がどのようにこの表をチェックしているかの手順が明確になりました。 まず横軸。カスタマイズの内容が妥当かどうかを判断できる論理構成になっているかどうか？ そのための構成としては、横軸を実現したい機能（ToBe）、パッケージの標準機能（AsIs）、カスタマイズの内容（実現方法）にするのが一般的だと思います。すなわち、実現したい機能と事実としてのパッケージの標準機能を説明しつつ、その差分が、カスタマイズ内容の根拠となるように横軸を構成します。 次は縦軸。縦軸は実現したい機能をリストアップするわけですが、適当に思いつくままリストアップしたのではなく、漏れなくリストアップしたことということが示されているかどうか？ そのことをどうやって示すかというと、実現機能をＭＥＣＥで分類し、分類が論理的に漏れていないことを示すしかありません。 では、どのようにＭＥＣＥ分類すればよいのか？ これには、オブジェクト指向的な分類が簡単だと思います。すなわち、システムに存在する論理的なオブジェクト（データ）をリストアップし、それぞれに対して、そのオブジェクトに対する一般論としての操作をリストアップする。それを分類として、実現したい機能を当てはめていく。 オブジェクトは「ユーザ情報」「ドキュメント情報」というようにそのシステムで扱うオブジェクトを挙げていきます。これはシステムごとに違ってきます。これは一見すると至極簡単なことのように思えますが、パッケージベースの要件定義では往々にして陥る罠があります。それは、パッケージが提供しているデータモデルとしてのオブジェクトと、実現したい機能で扱う論理的なオブジェクトがよく似通っているために、両者を混同してしまうということです。このカテゴリを混同してしまうと本来１つの機能として表現されるべき内容が複数箇所に散在したり、同じような内容が何箇所にも繰り返しでてくるということになったりします。 オブジェクトに対する操作は、特定の情報が格納されている場所に対して一覧・検索、登録、削除、更新、参照 が考えられます。 windowsのファイルシステムで言えば、ファイル・フォ