Boehm と Papaccio の報告によると，要求の誤りが設計段階で発見された場合，修正に必要な労力は，要求段階で発見・修正した場合の5倍となる．実装段階では10倍であり，単体テスト段階では20倍，リリース後は200倍となる (p.48)．
最初の項（1.2.1）では，「要求をエンジニアリングする」理由を，要求に起因する問題の事実・データ・引用から示す．それが，要求工学の重要性を示しているということである．文頭の引用は，よく知られている上に覚えやすい．現在はどうか，というのが気になる（ちなみに，1987年に発表されたデータである）．
原書では，もう少し新しいデータ（2001年くらいまで）もあるのだが，ぜひ原書を見ていただくとして，ここでは，安全性に関わる興味深い点を見ておく．最初は，本文ではたった5行で記載されているアメリカン航空AA965便の事故である．以前に調べたことがあるので，違う視点から考えてみる．
AA965便は，1995年12月20日，夕方マイアミを飛び立ちコロンビアのCaliに向かった．夜間の飛行である．Cali空港は山岳地帯にある．Cali空港が近づき，自動操縦によって飛行機は降下を始めた．
Caliの管制官から，直接北から着陸してはどうかという提案があった（オリジナルの飛行計画では180度旋回し，南から滑走路に入る必要があった）．夜間であり，クリスマス休暇の混雑から出発が遅れていたので，操縦士は，早く到着したいと思っていた（出発が約2時間遅れた）．当然，了解し，新しい経路を入力することにした．この間，飛行機は降下を続けている．新しい経路を入力するに当たり，管制官に確認したところ，TULUAの経路標識を過ぎたかと聞かれた（レーダは以前に爆破されていて，管制官は航空機の位置を確認できない！）．その，TULUAビーコンを確認している間も飛行機は降下を続け，結果的にすでに通り過ぎたことが分かった．
次の経路標識はROZOで，操縦士はRと入力した．一文字のインデックスで，航空機の近傍の経路標識が自動的に探索される．かつ，同一の先頭文字を持つものがないハズだった．ところが実際には，ROMEOが東方近傍にあり，インデックスRは，より大きな都市であるボゴタに近いROMEOが選択された．ROZOのインデックスは，同じRを使えないためROZOと4文字であった（事故後，PALMAに経路標識名は変更されている）．しかし，そのことに操縦士は気づかなかった．精神的に余裕がない状態だし，普通はインデックスは一文字という思い込みがある．自動操縦により，南へ向かうコースから，東のROMEOに向かうため，旋回をした．しかし，しばらくの間は，気がつかなかった．
途中で，間違いに気づき進路を戻そうとした．しかし，谷沿いの経路で進路を変えれば，当然山と向き合うことになる．GPWS（対地接近警報装置）の警告により回避しようと上昇したが，間に合わずに山に衝突した．これは，管制官が滑走路変更を提案してから，わずか5分後の出来事であった．
事故調査報告書では，この事故は操縦士のミスと結論づけている（原因として4点挙がっているが，すべて操縦士に責任があるとしている ）
ちなみに，機長は13回Caliに飛んでいる．副操縦士は，Caliは初めてであった．
さて，システムの問題に戻る．グラスコックピットと呼ばれる近代的な操縦支援システムは，それがブラックボックスとなったときに（身体性を失ったときという方が適切か），人間が，短時間で正しい判断をすることを困難にする．
「より賢くすればよいではないか」というのは，機械に身を任すという決心を，我々に要求する．
(nil)
要求工学分野は，第一に，もちろんソフトウェア工学と関係している．しばしば云われることではあるが，要求工学は，正しいシステムが何かについての工学であり，ソフトウェア工学は，システムを正しく作ることに関係している (p. 45)
ここでは，要求工学が，様々な分野と関係していることを示している．選んでいる分野を見ると，Lamsweerdeさんが教養の人というのが，よく分かる．
以前に，ライフサイクルのところでみた要求工学の四つの象限ごとに説明している（正確には第三象限はなくて，代わりに要求の進化が入っている）．ここでは，羅列に留めておく．
問題領域を理解し，情報を引き出す
- システム工学
- 制御理論
- 経営科学
- 組織理論
- 行動心理学
- 社会学理論
- 人類学
- 人工知能
- 信頼性理論
- 性能評価
- 認知心理学
- HCI（Human Computer Interaction）
評価し，交渉する
- （意思）決定理論
- リスク管理
- 対立管理（コンフリクトマネジメント ）
- 人工知能（マルチエージェント ）
仕様を決め，文書にする
要求の進化
個人的には，文書化のところで，統語論・意味論・関連性理論を含んだ言語論を入れてほしかった．
KAOS手法は，モデリングを重視する手法だが，他のモデリングとの関連についても記述している．
- 概念モデル
- タスクモデル
- ドメイン知識と人工知能における問題空間
概念モデルというのは，(E)ERに代表されるデータベースのモデル化であるし，タスクモデルは，GOMS(Goal , Operators, Method and Slection rules)に代表される人間の行動をモデル化するときに使われる考え方．ドメイン知識や問題空間といえば，意味ネットワークや（情報の世界で云う）オントロジーをすぐに思いつく．有名ではあるが，特定の分野を除けば，それほど普及しているわけではない．
(nil)
問題解決が持つ再帰的な性質は，問題空間と解決空間を，絡み合わせる (p.44)
昨年ICSEに出かけたときに，一日だけツインピークスという，そのときが二回目となるワークショップに出席した．場所がサンフランシスコだから，こういう名前がついたわけではない（そもそも第一回は別の場所であった）．
ツインピークスという二つの山頂のうち，一つは要求を示している．もう一つは，アーキテクチャを示している．
議論になったのは，そもそもこの両者の間にギャップがあるのかないのかという話だった ．ないとみんなが思っていれば，こんなタイトルをつけることはないので，主催者がギャップがあると心の中で思っているか，少なくとも，それは共通認識としてあると考えているに違いない（この場合，同時にギャップを埋めることは可能と考えている可能性が高い）．
午後2時間ほど，小グループに分かれて議論した．「ツインピークスと空間（これまでも何度か出ている問題空間・解決空間，あるいは，世界と機械といった空間）」というテーマのグループに入った（全部で10名ほどだっただろうか）．
私の主張は次の通り．
両者のギャップは本来的なものではなく，他の要因（例えば政治的に）決まる．共に適切にモデル化すれば，シームレスに繋ぐことは可能である
自分では気に入っていたが，なぜか，とても評判が悪かった．
さて，KAOSに戻る．要求分析は，プロジェクトの初期段階で実施する．従って，様々な他のアクティビティと関係する．
- ソフトウェアプロトタイピング
- アーキテクチャ設計
- ソフトウェア品質保証
- 実装と統合
- 文書化
- 保守
- プロジェクト管理
もちろん，これらアクティビティの入力となる．しかし，単なる入力では済まず，相互に絡み合うのである．
実現が見えない要求は，そもそも成立しない．アーキテクチャを考えたときに，要求が示している性能は，そもそもがムリだと分かったとする．そうなると次に要求に戻って，システムの目的が達成可能な妥当な線を見つけないといけない．前回でいえば，新規開発でラディカルな設計を必要とするタイプはそうなる．或いは，アーキテクチャを考えたときに，実は見落としていた要求があることに気がつく．そうすると，新しい要求項目を追加する必要が生じる．
この「絡み合い」は，何も要求とアーキテクチャに限ったことではない．山頂は，あちこちにある．しかし，プロジェクトのタイプによっては，一度深い谷におりないと，隣の山頂には行けない（ISO 26262 におけるDIAによるやりとりはその一つだろう）場合もある．
ただ，このことは，一般論（世間の常識？）としての要求と設計の間にあるギャップではなくて，文脈上そのことを考慮すべきというだけに過ぎない．両者は本質的にはつながっている．谷を作るのは，政治的人間であり，それには理由のある場合とそうでない場合がある．
(nil)