要求メタモデル
要求モデルのメタモデルについて、つらつらと考えている。
要求モデルでは、ユースケースが軸となると思うのだけれど、単純なユースケース駆動は、なかなかうまくいかないような気がしている。
一つの理由は、ユースケースの誤用があまりにも多いことである。
具体的には、ユースケースを機能一覧代わりに使っていたり、UIの画面遷移モデルに使っていたり、ひどいのになるとフローチャートを描いていたりする。
とはいえ、こういった誤用に情状酌量の余地がないのかというとそうでもない。
要求仕様として、機能一覧や画面遷移モデルが求められるケースが多々あり、特にOOADに初心な顧客や開発部隊だと、その圧力が大きい。このような状況において、「OOADを導入」の掛け声のもと無理矢理ユースケースを使うと、ユースケースであってユースケースでない珍妙なモデルが作成されることになる。
しかも、ユースケースは本来機能一覧や画面遷移に向いているとはいえないモデルなので、作るのに手間がかかる、今までできていたことができない、ユースケースの入門書を読むと混乱する、といった問題が発生してしまう。
つまりところ、こういう場合にはユースケースと称するものなどは作らず、今までどおり機能一覧や画面遷移モデルを作成すればよいのである。
また、ユースケースを作成するコストが大きいということも問題である。
このため、機能一覧的なものをユースケースで作成しようとすると、不必要なコストが発生する。
CRUDユースケース*1といった提案もあるけれど、本来のユースケースの思想からは少しずれていると思われるのであり、要求仕様をユースケースのみで記述しようとするので出てくる妥協案といえなくもない。
以上のような問題に対応するため、要求仕様では「ユースケース」と「ファンクション」を併用し、適材適所で使い分けることが良いのではないかと思っているのである。
また、プロダクト・ラインへの対応と非機能要求の扱いを考えると、「ユースケース」や「ファンクション」とは別系統のモデルとして「フィーチャ」の導入が必要となってきそうである。
さらに、「ユースケース」と「ファンクション」の間にFeature-Driven Development*2で言うところのFeatureに対応するモデルがあると便利な場合もありそうである。このFeatureは前出の「フィーチャ」との混同を避けるために、「ユーセージ(Usage)」と呼んでみようか、というのがアイデアである。
というようなわけで、要求仕様の階層として:
- フィーチャ(feature)
- 機能特性
- 品質特性
- その他の非機能特性
- ユースケース(use case)
- ユーセージ(usage)
- ファンクション(function)
- ユーセージ(usage)
というのが面白いのではないかと考えている。
