as-isとto-be→記述と規範

昨日、

ユーザーストーリーとDtoD、シナリオとカスタマージャーニーなんかのまとめ（＆偏見）
http://blog.goo.ne.jp/xmldtp/e/44240f36fc047485f09e55ad84792741

で、KAOSをto-be,それ以外をas-isと分けているけど、その根拠は？
と聞かれると思うので、書いておきます。

Lamsweerde先生の

Requirements Engineering: From System Goals to UML Models to Software Specifications

に、そのようなことが書いてある・・・
っといっても、as-is,to-beとは、出てきません。

descriptions と prescriptions　という言葉ででてきます。


この言葉の意味ですが、

記述と規範[prescriptive_grammar]
http://user.keio.ac.jp/~rhotta/hellog/2011-05-14-1.html

の意味だと思います。
descriptions→あるがままの姿→as-is
prescriptions→あるべき姿→to-be
ということになりますよね。

Lamsweerde先生は、上記の本の４章において、４．３章で、準形式(semi-formal)な形として、ダイアグラム（UML,ER図、DFDなど）を取り上げ、４．４章形式仕様として、VDMその他もろもろを挙げています。そして、４．５章の結論で、これら、準形式（＝UMLなども含まれる）、形式手法とも

Confusion between descriptions and prescriptions

と指摘しています。

つまり、as-isとto-beが混同している、ドメインプロパティと、要求、仮定と定義の区別がないとしています。そして、intentを区別する（to-beを明確にする）というのが、ゴール指向のモチベーションと記述しています。

そして、そのゴールを説明する７章の

7.1 What are goals

で、

A goal is a prescriptive statement of intent

「ゴールとは、意思（意図）についての規範的な文」としています。

つまり、ゴールは「こうあるべき」というto-be（規範）についてかかれたものです。このゴールによって、構築されたゴール指向分析であるKAOSは、規範的→to-beを記述したものといえます。

　それ以外のダイアグラムなどは、Lamsweerde先生の視点に立てば（それらがto-beを記述できないので、KAOSやっているんだから）to-beではなく、as-isになるということです。
この視点で、昨日のエントリは書いています。