ソフトウェアの要求は，将来ソフトウェアが規定する規範的記述である．この要求は，ソフトウェアと環境の交わりでのみ生じる現象として記述する (p.19)
ここでは，要求分析のプロセス中で考慮すべき4つの記述について記載がある．
(1) 要求
冒頭の内容になる．例として次が挙がっている．
- 全ての列車のドアは，列車が移動している間は，閉じたままでなくてはならない．
- 図書館の利用客は，一度に三冊以上の本を借りることはない．
- 会議に呼ばれている参加者が持つ制約は，可能な限り入手すべきである．
(2) ドメインプロパティ
「問題」世界（冒頭の引用文では環境）に関する記述
将来システムがあってもなくても，対象の世界では成立している特性である（単に，ドメインプロパティを訳しただけのようで恐縮する）．ソフトウェアの世界には，このドメインプロパティは最初は存在しない．しかし，将来システムが，環境に組み込まれる．このとき，環境で成立している特性は維持しないといけない．要求者が「そんなのは云わなくても当たり前でしょう」という内容．
列車が動いていると云うことは，列車の実際の速度がゼロの場合のみ
この例は，ずいぶんのようにも思う．しかし，このプロパティを要求者と開発者で共有できなかったために生じた事故についての説明が，あとで示される．また，ドメインプロパティの多くは，物理的な（或いは現実世界の）法則に従う．
(3) 前提
前提は，環境によって定まり，環境における言葉を用いて表現する．
この説明は少しわかりにくい．以前の図は，この項では新たに書き換えられている（右側が新しい図）．
先のドメインプロパティとの比較できる例を挙げる．
計測した列車の速度はゼロでないということは，物理的な速度がゼロではないということである．
「計測した列車の速度」というのは，ソフトウェア側の表現である．「物理的な速度がゼロではない」というのは，環境側の表現である．ここでは，環境側の言葉とソフトウェアの言葉を結びつけている．一方で，先のドメインプロパティは，純粋に環境側の言葉になる．
(4) 定義
これは，素直に要求者と開発者が合意した言葉の定義である．同様の例を挙げておく．
「動いている列車（TrainMoving）」とは，列車がブロック（線路のある区間）を物理的に動いていると（考えることのできる）事実を説明する「環境」における現象の名前である
さいごの，この紛らわしい「定義」の例は，列車のうごきそのものを，システムが直接に知ることができないことから来ている．人間であれば簡単に思える「動いている」という判断も，システムにとっては，車軸の回転をセンサで知るだけのことかもしれない．車輪がスリップしていれば？センサーが故障していたら？と考えたときに，システムは「動いている列車」を判定し損なうのである．
(nil)
「だれ」次元では，将来システムのコンポーネント毎に，誰（人間・デバイス・ソフトウェア）が，目的・制約・サービスを行うかを割り当てる (p.16)
この前段階の「なに」次元では，サービス（とそれに付随している制約・前提）を記述している．そのサービスを「だれ」が実行をするのかを，ここでは定義する．
あるコンポーネントは，純粋にソフトウェアだけで実行するかもしれない．別のコンポーネントは，人とソフトウェアが協力して実行するかもしれない．
単なる指示ではない場合もある．代替案として要求書に記述されるかもしれない．コスト制約のもとで，案として２つあると．全てを，人が行う場合とソフトウェアで実現する場合．
この要求に基づくシステムの提案者は，コストや期間制約とともに，どちらかを選択する．このことを可能にするために，要求として表現する．
ここまでで，3つの次元を見てきた．「なぜ」・「なに」・「だれ」次元である．
これから作られる3次元空間を考えると，どこから考えるかに順番はないようにも思う．「なぜ」から始まって，「なに」・「だれ」を考えても，「だれ」から始まって，「なぜ」「なに」を考えても，行き着く最後の空間上の位置が同じであれば，構わない．
しかし，KAOS法の場合は，おおむね「なぜ」・「なに」・「だれ」の順になる．
一般に，この順になっているとは限らない．例えば，KAOS法同様に広く知られているi*（i star, アイスター）では，「だれ」から始まる（教科書 にある簡単な図を示す）
ここでは，人・組織・人工物という「だれ」に相当するアクター（円で示されている部分）が起点になっている．
(nil)
要求工学における「なに」次元は，機能的にサービスに関係している．これは，「なぜ」次元によって見つけた目的を満足するために将来システムが提供すべきサービスである．(p.15)
この「なに」次元は，前々回の全体像でいえば，ちょうど「なぜ」次元と「だれ」次元の間に位置する．
前回の「なぜ」次元では，なぜの繰り返しが次元に沿って行われるが，「なに」次元には，そういう特徴はない．「なに」を正確に書くことが必要になる．
今回も，議論を先取りすると，「なに」の部分は，要求仕様が該当している．「なぜ」では，ゴールモデルを用いて，ユーザ要求を掘り下げていく．結果として選択されるのが，要求仕様である．KAOSの記法では，「なぜ」次元は，要求ノードの非循環有向グラフとして擬似的な階層構造として表現する．要求ノードは，最終的に選択した「仕様」ノードとして表現する．ここには，一般に階層性はない．
要求仕様が「なに」だとすることに，ずいぶんと違和感を感じる．例えば，不思議の国大学の図書館において，「24/7の検索サービスを提供すること」という仕様は，「なに」という疑問詞が似つかわしくない気がする．文頭の言葉のように機能的サービスを決めるのがここでの目的である．このとき，サービスが「なに」といういい方は，あるかもしれない．
文字通り機械の世界であれば，よく分かる．仕様に相当するのは，図面であり，それは作るべきモノを完全な形で示している（完全な形でなければ，正しい図面とはいえない）．まさに，作るべき「なに」である．
ここでの「なに」次元の「なに」は，ハードウェアからの借用語に見えてしまう．もう少し良い表現を探してみたい．
さて，この段階で，記述が必要な要素として，機能的サービス以外に筆者が提示しているのは，次である．
- 正常に動作するためのシステムの前提
- ソフトウェアの特性（性能・セキュリティ・ユーザビリティ等）に関係した制約
後者は，一般にNFR（Non Functional Requirement 非機能要件）と呼ばれるものである．機能・非機能・制約がきちんと書ければ，要求仕様としては，必要十分であるというのは，そのとおりと思う．
（nil）