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