ソフトウェアの要求は，将来ソフトウェアが規定する規範的記述である．この要求は，ソフトウェアと環境の交わりでのみ生じる現象として記述する (p.19)
ここでは，要求分析のプロセス中で考慮すべき4つの記述について記載がある．
(1) 要求
冒頭の内容になる．例として次が挙がっている．
- 全ての列車のドアは，列車が移動している間は，閉じたままでなくてはならない．
- 図書館の利用客は，一度に三冊以上の本を借りることはない．
- 会議に呼ばれている参加者が持つ制約は，可能な限り入手すべきである．
(2) ドメインプロパティ
「問題」世界（冒頭の引用文では環境）に関する記述
将来システムがあってもなくても，対象の世界では成立している特性である（単に，ドメインプロパティを訳しただけのようで恐縮する）．ソフトウェアの世界には，このドメインプロパティは最初は存在しない．しかし，将来システムが，環境に組み込まれる．このとき，環境で成立している特性は維持しないといけない．要求者が「そんなのは云わなくても当たり前でしょう」という内容．
列車が動いていると云うことは，列車の実際の速度がゼロの場合のみ
この例は，ずいぶんのようにも思う．しかし，このプロパティを要求者と開発者で共有できなかったために生じた事故についての説明が，あとで示される．また，ドメインプロパティの多くは，物理的な（或いは現実世界の）法則に従う．
(3) 前提
前提は，環境によって定まり，環境における言葉を用いて表現する．
この説明は少しわかりにくい．以前の図は，この項では新たに書き換えられている（右側が新しい図）．
先のドメインプロパティとの比較できる例を挙げる．
計測した列車の速度はゼロでないということは，物理的な速度がゼロではないということである．
「計測した列車の速度」というのは，ソフトウェア側の表現である．「物理的な速度がゼロではない」というのは，環境側の表現である．ここでは，環境側の言葉とソフトウェアの言葉を結びつけている．一方で，先のドメインプロパティは，純粋に環境側の言葉になる．
(4) 定義
これは，素直に要求者と開発者が合意した言葉の定義である．同様の例を挙げておく．
「動いている列車（TrainMoving）」とは，列車がブロック（線路のある区間）を物理的に動いていると（考えることのできる）事実を説明する「環境」における現象の名前である
さいごの，この紛らわしい「定義」の例は，列車のうごきそのものを，システムが直接に知ることができないことから来ている．人間であれば簡単に思える「動いている」という判断も，システムにとっては，車軸の回転をセンサで知るだけのことかもしれない．車輪がスリップしていれば？センサーが故障していたら？と考えたときに，システムは「動いている列車」を判定し損なうのである．
(nil)