「なぜ」次元の分析は，単純さからほど遠い（p.14）
もう少し，「なぜ」次元の話を続ける．KAOS手法の中心モデルは，ゴールモデルであるが，その背景となっているのは，この「なぜ」次元だからである．
ちなみに，具体的なKAOS手法については，PART II のテーマで，287ページから始まる．すこし遠い．
「なぜ」次元の主要な作業として，次を挙げている．
- ドメイン知識を得ること
- 問題世界において「代替」を評価すること
- 新しい技術の利用可能性を評価すること
- 「衝突」に対処する
最初のドメイン知識を得ることの必要性は，明白である．不思議の国大学図書館の例だと，そもそも図書館での書籍・雑誌にまつわる知っていて当然の知識がある．雑誌の年間購読にどういうオプションがあり，物理的な冊子の形とオンラインジャーナルでどう手続きが違うか．オンラインジャーナルの場合，ユーザにはどういう告知が必要か，というのは必要知識の一部である．いま，将来システムを作ることに対する目的がある．この目的に対して，「なぜ」を繰り返し適用するのだから，そもそもドメイン知識がなければ，黙ってしまうしかない．
いま，「図書館システムを便利にする」という目的を考えたときに，さらに「なぜ」を問う．「いまは，利用時間が制約されているから，夜間に必須の論文が読めない」．では，夜間も開館しようとすると，別のなぜに出会うかもしれない．「コスト上の問題から，読めない雑誌がある」．夜間の開館は，コストアップにつながり，更なる不平を生むかもしれない．
前回用いた図で「なぜ」次元は，雲形で表現されていたが，外形が不定であるばかりか，雲の中の要素も絡み合っているのである．
この絡み合いのうち相反するものは，KAOSでは「衝突」と表現する．この「衝突」が最終的に解決できれば，つつがなく目的を達成できたと言うことになる．もちろん，文字で書くのは簡単であるが，実際には難しい．
さて，このときに，「代替」をさらに考えつくかもしれない．「なぜ」を繰り返すと，「なぜ，利用時間が制約されていると，夜間に必須の論文が読めないのか」となる．図書館の開館時間とは別に，サービスが提供できれば良いとすれば，「夜間には，オンラインサービスを提供する」を新たな目的とすることが可能かもしれない．これが，「代替」である．
新しい技術の利用可能性は，よくよく心しないといけない．技術のことを書くわけではない．このレベルでは，目的を「なぜ」を通じて明らかにすることにある．もし，30年前であったら，「夜間にオンラインサービスを提供する」は，新たな目的とはならないことを考える必要がある．
（nil）
新しいシステムの版が何故必要かは，新システムで達成すべき目的として明確にする必要がある（p.13）
今回取りあげる文は，少しひっかかる．システムが必要な理由とシステムの目的は，一致しない．会議管理システムは，調整が大変だから必要である．システムの目的は，会議の調整が容易なシステムを作るである．少なくとも，否定の関係にある．正確に言えば，「新システムの達成すべき目的には，そのシステムが必要な理由が関連づけられていなければならない」ということか．ただ，これでもまだすっきりはしない．
下図は，図1.2である（すこし改変している）．一番右（将来システム）には，すでにKAOSの原型とでもいえる構造が現れている．
将来システムの目的は，「どうして（WHY）」次元としている．
ここでは，注意深い分析が必要としている．
- 新システムの目的を正確に言えば何になるのか
- 悪影響はないか
- それら目的はどのように関連しているのか
- ビジネスの目標とどのように対応しているのか
ちなみに，ここには，WHYで始まる文は一つもない．それでも「なぜ」次元なのである．
思うにLamsweerde さんが主張したいのは，目的に関して「なぜ」を徹底しろということではないか．それが，単になぜではなく，「なぜ」次元としている理由でもあるだろう．このことを踏まえて，最初の文の新たな日本語を考えてみる．
「新システムで達成すべき目的は，「なぜ」を繰り返すことで，明確にする必要がある」
KAOSは，トップダウンの構造をとるため，スタートがぶれるてはいけないということでもあると思う．
(nil)
ミーティングしたいという要求は，時間的・空間的な重なりから，競合するかもしれない (p.10)
説明のために，３つのケーススタディが示されている．以下は概要のみだが，それぞれ2ページほどの長さがある．
ケーススタディ１：図書管理
不思議の国大学（UWON）では，図書の管理システムを刷新したいと考えている．現状は，一つのシステムではない．各学部等で，独自に構築したもののしかない．これでは効率がわるい．従って，より効率がよく，書籍の購入費用も少なくて済み，ユーザにとっても便利な単一のシステムに移行したい．
ケーススタディ２：列車制御
不思議の国空港（WAX）では，空港へのアクセスが問題になっている．これまでは，バスが主であった．しかし，運行管理を工夫することによって，鉄道をより効果的に使うことにした．高速大量輸送が可能であり，より正確な時間で運行できる可能性があるから．ソフトウェアによって，この高速の輸送に加えて，安全性と快適性を実現したい．
ケーススタディ３：会議管理
不思議の国ソフトウェアサービス会社（WSS）では，グローバル化が進展する現状を見て，会議管理システムに需要があると考えた．様々な場所や国でミーティングが行われる可能性があるからだ．そこで，この会議管理システムでは，どのような機能が必要かを考えた．しかし，単に参加者の出席可能日をまとめるだけではだめで，例えば職位が上の人の意向を反映するなどさまざまなパターンに対応する必要があることが分かってきた．
ケーススタディというのは，無機質な例が多いが，ここでは読み物としてもおもしろくなっている．例えば，ケーススタディ３の上位の職位の意向を尊重するという内容も，最終的に要求としてどう書くのかを考えると興味深い．
さて，文頭の言葉は，ケーススタディ３から抜き出している．何れもソフトウェアの話であるが，このあと物理的な制約を考慮しなさいということにもつながってくる．もちろん，ケーススタディ１でも，「本」は分けられないし，ケーススタディ２では，同一時刻に同一路線にいる異なった列車は，ぶつかっているに違いない．全て物理制約を含んでいる．
この物理制約以外にも，便利とはどういうことか（ケーススタディ１），快適とはいかなることか（ケーススタディ２）を考えると，楽しい．
(nil)