KAOS法の概要 (v. 0.1)
KAOS法は，ゴール指向要求分析の一つと云われています．ゴール指向要求分析（Goal-oriented Requiements Engineering）は，良くGOREと略されることも多く 1，一定の評価を得た研究・実践領域ということだと思います．
略語のついでに考えると，KAOSは，Knowledge Acquisition in autOmated Specificationsの略とされています．少し苦しい．たぶん，KAOSが先に決めたと云うことだと思います．
教科書は，次の本になります．私の持っている本だと，最後のページ番号が682となっていますから，かなり大部の本です．
Requirements Engineering 2
さて，ゴール指向による要求分析というときに，そもそもゴールとは何でしょうか．
考案者の Axel van Lamsweerdeさんによる定義は次のようになっています(p.260)
ゴールというのは，システムが達成すべき意図の規範的言明（prescriptive statement）である．このとき，エージェントと協力する．
まず，規範的言明というのがわかりにくいのですが，一つのいい方としては，それは「命令」であると考えることができます．「〜すべき」と書かれる文ということです．対照的な言葉に，記述的（descriptive）というのがあります．こちらは，言語上の法（mode）としては，直接法で書かれることになります．例えば，「三次元空間上の特定の点を，異なる物質が同時に占めることはない」といった文です（本当は可能な気もします）．
どちらにしろ，ゴールは，システムがすべきことである，それは，そもそもが要求者の意図であるということになります．
エージェントというのは，ソフトウェアの文脈で使われているものと同じです．ある役割を与えれれた人やモノです．システムは，これらエージェントと協力します．
従って，ゴールというのは，システム化とエージェントを前提とした上で，要求者の意図を命令的に表現したものということなります．
しかし，この文節化では，余り分かった気にはなりません．
もう少し，アカデミックではない説明を試みます．Aさんが，ある地点に移動したいと考えている．このとき，その話を聞いたSさんが，飛行機の時刻表を差し出すのは，気の利いた行為か否かです．Aさんは移動しつつ風景を楽しみたいのかもしれない．或いは，誰かと一緒に旅行したくて，時間調整に悩んでいるかもしれない．意図というのは，陽には示されないということもありますが，やりたいことに対して，いきなり手段を提示するのは違う，ということは一般に正しいと思います．
ゴールは，基本的には要求者の意図をベースとしています．いま，意図の実現を図ろうとするとき，矛盾（ゆっくり行きたいが，自由時間が少ない）と障害（そもそも移動する費用がない）とともに，その整理が必要になります，この整理における基本単位を，ここでは，ゴールと呼ぶんだ，ということになります．
簡単にゴールモデル図式のサマリを書きました．参考にしていただければと思います．
KAOS_Notation_Summary(KAOS ゴールモデル図 早わかり）
KAOS教科書
いま，教科書を最初から辿っています（こちら）．参考までに，目次を示しておきます．
パート１は，タイトル通り，要求工学の基礎です．パート２が，KAOS法の説明です．パート３は少し進んだ話題になります．パート２から読み始めることも可能と思います（ページが多いですし）．
目次
パート１ 要求工学の基礎
１. 準備をしよう
1.1 要求工学とはなにか
1.1.1 問題空間と機械による解決
1.1.2 とりくむ事例の紹介
1.1.3 要求工学における次元：「どうして」，「なにが」，「だれが」
1.1.4 要求工学に含まれる記述のタイプ
1.1.5 要求のカテゴリ
1.1.6 要求ライフサイクル：プロセス，アクタ，製品
1.1.7 目標とする品質と避けるべき欠陥
1.1.8 ソフトウェアプロジェクトのタイプ
1.1.9 ソフトウェアライフサイクルと要求
1.1.10 要求工学と他分野との関係
1.2 どうして要求を工学するのか
1.2.1 要求に関する問題の事実・データ・引用
1.2.2 要求工学の役割と議論すべきこと
1.3 要求工学を実践しようとするときの障害
1.4 アジャイル開発プロセスと要求工学
まとめ
メモと更に読むべき文献
練習問題
2 ドメインを理解し，要求を引き出す
2.1 ステークホルダを見つけ，情報を引き出す
2.2 記述されたものから情報を引き出す技術
2.2.1 背景を知る
2.2.2 データを集める
2.2.3 質問票
2.2.4 概念を中心として情報を得るためのレパートリグリッドとカード種
2.2.5 問題世界の探索を行うためのストリーボードとシナリオ
2.2.6 早い時期にフィードバックを得るためのモックアップとプロトタイプ
2.2.7 知識の再利用
2.3 ステークホルダを中心とした，情報の引き出し方
2.3.1 インタビュー
2.3.2 観察とエスノグラフィックスタディ
2.3.3 グループセッション
2.4 結論
まとめ
メモと更に読むべき文献
練習問題
3 要求を評価する
3.1 不整合を管理する
3.1.1 不整合のタイプ
3.1.2 不整合に対処する
3.1.3 管理上の衝突：システム的プロセス
3.2 リスク分析を行う
3.2.1 リスクのタイプ
3.2.2 リスク管理
3.2.3 リスク文書
3.2.4 要求ライフサイクルにおいてリスク管理と組み合わせる
3.3 最終決定のために代替オプションを評価する
3.4 要求に優先度を与える
3.5 結論
まとめ
メモと更に読むべき文献
練習問題
4 要求を仕様化し文書にする
4.1 制限付き自然言語で，自由に文書化する
4.2 構造化した自然言語で，文書を書くよう訓練する
4.2.1 記述のためのローカルルール
4.2.2 要求文書を組織化するためのグローバルルール
4.3 図式表現を用いる
4.3.1 システムスコープ：問題図とフレーム図
4.3.2 概念構造：実体関連図
4.3.3 アクティビティとデータ：SADT図
4.3.4 情報の流れ：データフロー図
4.3.5 システムオペレーション：ユースケース図
4.3.6 相互作用シナリオ：イベントトレース図
4.3.7 システムのふるまい：状態機械図
4.3.8 刺激—反応：R-net図
4.3.9 複数のシステムビューと複数視点の仕様をUMLでまとめる
4.3.10 図式の記法：長所と限界
4.4 形式仕様
4.4.1 文を形式化するための基盤としての論理
4.4.2 履歴ベースの仕様
4.4.3 状態ベースの仕様
4.4.4 イベントベースの仕様
4.4.5 代数仕様
4.4.6 他の仕様パラダイム
4.4.7 形式仕様：長所と限界
4.5 結論
まとめ
メモと更に読むべき文献
練習問題
5 要求の品質保証
5.1 要求のインスペクションとレビュー
5.1.1 要求のインスペクションプロセス
5.1.2 インスペクションガイドライン
5.1.3 要求インスペクションチェックリスト
5.1.4 結論
5.2 要求データベースへの問い合わせ
5.3 仕様のアニメーションによる要求の妥当性確認
5.3.1 仕様から実行可能なモデルを引き出す
5.3.2 モデルをシミュレーションする
5.3.3 シミュレーションを可視化する
5.3.4 結論
5.4 形式検査による要求の検証
5.4.1 言語検査
5.4.2 専用の一貫性と完全性の検査
5.4.3 モデル検査
5.4.4 定理証明
5.5 結論
まとめ
メモと更に読むべき文献
練習問題
6 要求の進化
6.1 時空間上の進化：版と変異
6.2 変更を見込む
6.3 進化をサポートするために追跡可能性管理を行う
6.3.1 追跡可能性リンク
6.3.2 追跡可能性管理プロセスとその利点とコスト
6.3.3 追跡可能性管理技術
6.3.4 追跡可能性管理の十分な費用対効果のトレードオフを行う
6.4 変更制御
6.4.1 変更の開始
6.4.2 変更の評価と優先度付け
6.4.3 変更の一元管理
6.5 要求を監視し，動的な変更を前提とする
6.6 結論
まとめ
メモと更に読むべき文献
練習問題
7 要求工学におけるゴール指向
7.1 ゴールとは何か
7.2 ゴールの粒度，要求との関係，前提
7.3 ゴールのタイプとカテゴリ
7.3.1 ゴールのタイプ：ふるまいゴール vs ソフトゴール
7.3.2 ゴールカテゴリ：機能ゴールと非機能ゴール
7.4 要求工学プロセスにおけるゴールの中心的な役割
7.5 ゴールはどこから来るのか
7.6 ゴールと他の要求に関係する他の方法やプロセスとの関係
7.6.1 ゴールとシナリオ
7.6.2 意図に基づく仕様と操作に基づく仕様
7.6.3 ゴールとユースケース
7.6.4 ゴールとモデル検査されるプロパティ
7.6.5 ゴール指向とエージェント指向
7.6.6 ゴール指向とオブジェクト指向
7.6.7 ゴール指向とトップダウン分析
まとめ
メモと更に読むべき文献
練習問題
パート２ 要求工学に適合するシステムモデルを作る
8 ゴール図でシステムの目的をモデル化する
8.1 モデル注釈によるゴール特性の表現
8.2 ゴールの洗練
8.3 ゴール間の衝突を表現する
8.4 ゴールモデルを他のビューと結びつける
8.5 代替となるオプションをモデル化する
8.5.1 代替となるゴール洗練
8.5.2 代替となる責務割当
8.6 AND/ORグラフとしてのゴール図
8.7 ゴール洗練と割当に注釈を付加する
8.8 ゴールモデルを作る：経験的規則と再利用可能なパターン
8.8.1 初期ゴールを導き出す
8.8.2 洗練の分岐に従いゴールを識別する
8.8.3 ゴールモデルのスコープ境界を定める
8.8.4 よくある落とし穴を避ける
8.8.5 洗練パターンを再利用する
8.8.6 ゴールカテゴリと関係した洗練木を再利用する
まとめ
メモと更に読むべき文献
練習問題
9 何を間違えるかを理解する：ゴールモデルのリスク分析
9.1 障害によるゴール達成の妨げ
9.1.1 障害とは何か
9.1.2 障害抽出の完全性
9.1.3 障害カテゴリ
9.2 障害をモデル化する
9.2.1 障害図
9.2.2 障害洗練の条件
9.2.3 ゴールのAND洗練に対するボトムアップ的障害の拡散
9.2.4 障害図に注釈をつける
9.3 より頑健なゴールモデルに対する障害分析
9.3.1 障害を識別する
9.3.2 障害を評価する
9.3.3 修正したゴールモデルで障害を取り除く
まとめ
メモと更に読むべき文献
練習問題
10 クラス図で，概念オブジェクトをモデル化する
10.1 概念オブジェクトによって対象に現れる概念を表現する
10.1.1 概念オブジェクトとは何か
10.1.2 オブジェクトのインスタンス化：クラスと現在のインスタンス
10.1.3 概念オブジェクトのタイプ
10.1.4 UMLクラス図としてのオブジェクトモデル
10.1.5 モデル注釈によるオブジェクト特性の表現
10.2 エンティティ
10.3 関連
10.4 属性
10.5 オブジェクトモデルの構造化するときに利用するビルトイン関連
10.5.1 オブジェクトの特化
10.5.2 オブジェクトの凝集
10.6 クラス図に関して更に知っておくこと
10.6.1 導出した属性と関連
10.6.2 OR-関連
10.6.3 順序付き関連
10.6.4 関連の関連
10.7 オブジェクトモデルを作るときの経験的ルール
10.7.1 ゴール図から適切で完全なクラス図を導き出す
10.7.2 オブジェクトか属性か
10.7.3 エンティティ，関連，エージェント，イベント？
10.7.4 リンクされたオブジェクトの属性，それともリンクしている関連の属性か？
10.7.5 凝集と関連のどちらを選ぶか？
10.7.6 特化と汎化の概念
10.7.7 よくある落とし穴を避ける
まとめ
メモと更に読むべき文献
練習問題
11 システムエージェントとその責務をモデル化する
11.1 エージェントとは何か
11.2 システムエージェントに特徴を与える
11.2.1 基本的な特徴
11.2.2 エージェントの能力
11.2.3 エージェントの責務とゴールの実現
11.2.4 操作を実行するエージェント
11.2.5 エージェントの望みと信念
11.2.6 エージェントの依存
11.3 エージェントモデルを表現する
11.3.1 エージェント図とインスタンスの宣言
11.3.2 コンテキスト図
11.3.3 依存図
11.4 抽象エージェントの洗練
11.5 エージェントモデルを作る
11.5.1 ゴールモデルからエージェント図を作るための経験的知識
11.5.2 ゴールモデルからコンテキスト図を作る
まとめ
メモと更に読むべき文献
練習問題
12 システムの操作をモデル化する
12.1 操作とは何か
12.2 システム操作に特徴を与える
12.2.1 基本的な特徴
12.2.2 操作のシグネチャ
12.2.3 ドメインの事前条件と事後条件
12.2.4 操作の実行者
12.3 ゴールの操作化
12.3.1 ゴールを満足するための必要な事前・事後・トリガー条件
12.3.2 エージェントのコミットメント
12.3.3 ゴールの操作化と充足引数
12.4 ゴール・エージェント・オブジェクト・操作：意味論的イメージ
12.5 操作モデルを表現する
12.5.1 操作化図
12.5.2 UMLユースケース図
12.6 操作モデルを作る
12.6.1 操作化図を作る上で必要な経験敵知識
12.6.2 操作化図からユースケース図を構築する
まとめ
メモと更に読むべき文献
練習問題
13 システムのふるまいをモデル化する
13.1 インスタンスのふるまいをモデル化する
13.1.1 UMLシーケンス図としてのシナリオ
13.1.2 シナリオ洗練：エピソードとエージェント分割
13.2 クラスのふるまいをモデル化する
13.2.1 UML状態図による状態機械
13.2.2 状態機械の洗練：連続的副状態と並行副状態
13.3 ふるまいモデルを作る
13.3.1 広くカバーするために関連するシナリオを洗練する
13.3.2 状態変化条件によってシナリオを詳細化する
13.3.3 シナリオから状態機械へ
13.3.4 シナリオからゴールへ
13.3.5 操作化ゴールから状態機械へ
まとめ
メモと更に読むべき文献
練習問題
14 複数のシステムビューを統合する
14.1 ビューを統合するまえのメタモデル
14.1.1 メタモデルの全体構造
14.1.2 ゴールメタモデル
14.1.3 オブジェクトメタモデル
14.1.4 エージェントメタモデル
14.1.5 操作メタモデル
14.1.6 ふるまいメタモデル
14.2 ビュー内部の一貫性ルール
14.3 ビュー断片をグループ化しパッケージとする
まとめ
メモと更に読むべき文献
練習問題
15 実践的ゴール指向のモデル構築手法
15.1 現状システムをモデル化する
15.1.1 ステップ１：シナリオを利用して初期のゴールモデルを作る
15.1.2 ステップ２：初期のオブジェクトモデルを作る
15.2 将来システムをモデル化する
15.2.1 ステップ３：シナリオが示す新しいゴールを用いてゴールモデルを更新する
15.2.2 ステップ４：オブジェクトモデルを更新する
15.2.3 ステップ５：障害・脅威・衝突を分析する
15.2.4 ステップ６：責務を分析し，エージェントモデルを作る
15.2.5 ステップ７：代替オプションから選択する
15.2.6 ステップ８：操作モデル中でゴールを操作化する
15.2.7 ステップ９：ふるまいモデルを作り分析する
パート３ システムモデル上での推論
16 モデル分析と有効活用のための半形式推論
16.1 モデルデータベースの問い合わせに基づく分析
16.1.1 モデルの構造上の一貫性と完全性を調べる
16.1.2 専用の分析のために他のビューを作る
16.1.3 追跡可能性管理
16.1.4 類推的モデルの再利用
16.2 ゴール指向モデルの半形式的分析
16.2.1 衝突分析
16.2.2 障害を見つけるための経験敵知識
16.2.3 脅威分析：ゴールモデルからアンチゴールモデルへ
16.3 代替オプションについての推論
16.3.1 代替についての質的推論
16.3.2 代替についての量的推論
16.4 要求文書のモデル駆動生成
16.5 要求工学を超えて：ゴール指向要求からソフトウェアアーキテクチャへ
16.5.1 オブジェクトモデルからソフトウェアデータアーキテクチャを導出する
16.5.2 エージェントモデルおよび操作モデルから抽象データフローアーキテクチャを導出する
16.5.3 アーキテクチャ要求からアーキテクチャスタイルを選択する
16.5.4 品質要求によりアーキテクチャを洗練する
まとめ
メモと更に読むべき文献
練習問題
17 システムモデルの形式仕様
17.1 モデル注釈を記述するための実時間時制論理
17.1.1 状態表明
17.1.2 時制表明
17.1.3 実時間時制の構築
17.2 ゴールモデル中でゴールを規定する
17.3 オブジェクトモデル中で記述的プロパティを規定する
17.4 操作モデル中で操作化を規定する
17.5 システムの意味論的イメージに戻る
まとめ
メモと更に読むべき文献
練習問題
18 仕様構築と分析のための形式推論
18.1 ゴール洗練を検査する
18.1.1 定理証明を用いる
18.1.2 形式洗練パターン
18.1.3 有界SATソルバーを用いる
18.2 ゴール操作化の導出
18.2.1 有界SATソルバーを用いる
18.2.2 形式操作化パターン
18.3 リスク分析のための障害を生成する
18.3.1 ドメインプロパティを用いて障害を退行させる
18.3.2 形式障害パターンを用いる
18.4 セキュリティ分析のためにアンチゴールを生成する
18.4.1 セキュリティゴールを記述する
18.4.2 セキュリティゴールと初期アンチゴールを識別する
18.4.3 アンチゴールを洗練する
18.5 形式的衝突分析
18.5.1 衝突に対する境界条件を導き出す
18.5.2 発散を形式的に解決する
18.6 アニメーションとモデル検査のためにふるまいモデルを合成する
18.6.1 ゴール駆動モデル合成
18.6.2 シナリオ駆動モデル合成
まとめ
メモと更に読むべき文献
練習問題
(nil >at< nil.co.jp)
Notes:
- 本当に良く用いられるかどうかは，疑問がありますが．ちなみに，単に要求工学といういい方も余り好みではなく，もう少し良いいい方を考えたいと思っています．ある学問領域を指すというより，実践的な活動であるという意味が強いのではと思っています ↩
- Lamsweerde, A. v., Requirements engineering : from system goals to UML models to software specifications. John Wiley: Chichester, England ; Hoboken, NJ, 2009; p xxix, 682 p. ISBN:0470012706 (pbk.) 9780470012703 (pbk.) ↩