・・・日本は教えていないみたいだけど・・・
要求仕様書は(UML等を使ったり、文書だったりの違いはあるモノの)、一般に、
・データフロー(業務フロー)がどうなっているか
・データ構造がどうなっているか
を示している。たとえばUMLだと前者はユースケース図→アクティビティ図、
後者はクラス図となる。そして、これらの図の間にコンフリクトや矛盾がないことが
よいものとされている。
しかし、実際のユーザーの要望は、ユーザー間で矛盾していたり、
コンフリクトがあって、それを調整する必要がある。
そして、その結果が上記UMLに書かれる。
このようなユーザーの要望、意図を記述し、その間の矛盾、トレードオフを
可視化する手法がKAOSで、Lamsweerdeさんは、そのKAOSを使って、
UMLのユースケース図、クラス図等に落とし込み、要求を出す手法を、
Requirements Engineering: From System Goals to UML Models to Software Specifications
で説明している。全体図は、こんなかんじ。
8章、9章がKAOS、
10章がクラス図(を本文中では説明している)
11章がエージェントモデルで、その中でi*を説明している
12章がユースケース図
13章がシーケンス図とステートチャート図
に展開している(これ以降の章で、形式手法に展開している)
世界的にみると、要求工学を教える場合、この本が使われているみたい・・・
なので、ユーザーの要求(をゴールという形で表現するゴール指向分析;KAOSはその一派)
から、UMLに落とし込んで、要求仕様を作るという手法は、世界的にみると
当たり前なことなのかもしれない。
最近、ある要求工学の授業内容をみる機会があった。
で、その資料をみたら、上図(全体図)を説明すべきところに
別な図が入っていて・・・UMLとの連携は書かれていなかった。
たぶん、説明もしていないのだろう・・・
ってことは、日本では、ユーザー要求を、どう処理すると、UML
に落ちて、システム化できるかは、説明されていないということだ・・・
(その授業で説明されないなら、たぶん、日本のどこの要求工学の
授業でも説明されないであろうと思われる授業なので・・)
・・・世界的には、説明されているのに・・・
だから
顧客分析力がこんなに求められちゃうんだよね。
ソフトウェア工学の割には・・・
う~ん、日本は遅れているかもしれない・・・