要求に対して，次の項目を評価する．
リスクが低く・衝突の少ない要求か?
また，利害関係者が納得する前提か? (p. 87)
3章は，以前に見た要求工学スパイラルの第一象限に相当する．第二段階である．前章では，様々な技術を用いて，要求を整理した．冒頭のように，その要求を評価し・整理するのが，本章の目的である．おおむね次の4つの部分からなる．
不整合の評価と回避策
先ずは，要求に含まれる不整合を見つける．次にその不整合は如何に回避できるかを考える．
リスクの評価とリスク度の減少
要求に含まれている様々なリスク（安全性・セキュリティ・開発そのもの）を分析し，回避策を検討する．ここでのリスクとは，あくまで要求中のリスクである．プロジェクトリスクに限らないことに注意が必要である．
代替案の評価
代替案を用いて，不整合の回避し，リスク度を減らすことを考える．機能要求としては同一であっても，非機能要求に影響を与えるような代替案を考える．ここでは，非機能要求への寄与度や衝突・リスクを減らすという点から，評価を行う．
開発制約からの（優先度を用いた）評価
最終的に選択した代替案であっても，例えば，プロジェクト制約（日程・コストなど）を吸収できないかもしれない．その場合は，最終的に何を選ぶのかをきめるための，優先度による評価が必要になる．
以上が，3章の概要である．要求のリスクというのは，もちろん普段考えるにしても，それを合理的に（利害関係者が納得出来るように）考えるのは，なかなか難しい．どういう議論を展開するかを楽しみにして欲しい．
(nil)
結局の所，コンポーネントの再利用やプログラムの自動化技術が予想通り進んだ後で，何が残るだろう．ソフトウェア工学は，年老いていく．そのとき，ソフトウェア工学に残っているのは，要求工学だけではないだろうか
たまたま，ACMのSoftware Engineering notes を見ていたら，トップ10ダウンロード論文の紹介で，Lamsweerdeさんの論文が2位に入っていたので，ちょうど2章が終わったところでもあり，この論文を紹介したい．ちなみに，5位までは次のようになっている．
- Requirements Engineering: a Roadmap – 2000, Bashar Nuseibeh, Steve Easterbrook. Downloaded 187 (198) times
- Requirements Engineering in the year 00: a Research Perspective – 2000, Axel van Lamsweerde. Downloaded 144 (New) times
- Architecture-based Analysis of performance, reliability and security of software systems – 2005, Vibhu Saujanya Sharma, Kishor S. Trivedi. Downloaded 118 (New) times
- View of 20th and 21st Century Software Engineering – 2006, Barry Boehm. Downloaded 104 (117) times
- Theme: An Approach for Aspect-Oriented Analysis and Design – 2004, Elisa Baniassad, Siobhan Clarke. Downloaded 103 (New) times
一位も要求工学に関係している．全体に将来予測のものが多いので，そういう時期のデータだったのかもしれない．ちなみに，現在の順位は次から見ることができる．
http://dl.acm.org/sig.cfm?id=SP950
タイトルの通り2000年を起点として，過去25年の要求工学のふりかえりと，今後25年の予測を試みている．ICSEでの発表内容で，研究者向けである．
幾つかのアプリケーション領域では，複雑でカスタマイズ可能なパッケージが選ばれている．要求から（カスタマイズ）用のパラメータを設定することに関して，調査が必要かもしれない．
インターネット利用者が増えると共に，ソフトウェアも個別化するかもしれない．そのとき，唯一の利害関係者としてのエンドユーザに対する小さな要求工学の研究が，必要になるかもしれない．
要求工学と形式仕様記述の研究の狭間は，埋める必要がある．前者は，深い抽象モデルを作る．後者は，深い分析を提供する．ツールも進化している．両者を繋ぐ道を見つけるべきであろう．
問題領域と要求モデルには，より多くの知識が含まれるべきである．要求工学プロセス中に含まれる様々な側面・懸念・アクティビティについての知識である．
エージェントのモデル化は，もう一つの関心領域である．伝統的に要求工学は，世界をソフトウェアとそれを取り巻く環境に二分してきた．しかし，実際は複雑で，その中には複数のソフトウェア・人間・物理的なコンポーネントがある．間違った信念・非協力・間違った前提といったものが問題の大きな原因となっている．エージェントのモデル化支援というのが，特に，エージェントへの責務の割当に関して，重要になる．
現在分かっている代替策と将来の起こりうる変化に対する見通しに関して，余り注意が払われていない．しかし，要求工学における中心的な課題であり，将来取り組むべき領域である．
新しい言語や，記法に関して更に研究を進めるべきである．そういった言語を用いて，複雑な人工物を作る時期に来ている．しかし，非形式性から部分的な形式性，そして完全なる形式性にいつ移るべきかを明らかにする必要がある．シナリオから要求モデルへシフトするタイミングと方法に関しても同様．衝突がある見方から一貫した文書への時期と方法についも同様である．
要求のリエンジニアリングもまた研究すべき領域である．既存のドキュメントが適切に記述されていない場合がある．そのとき，開発と保守が問題になる．抽象と再構築はこの場面において，有益である．
言語自身に関して云えば，システムの複数の側面を把握するための複数言語を，意味的に統合すべきである．同一言語の複数フォーマットについても同様である（テキスト，表形式・図形式）．
ツールに関して云えば，要求工学に特化したツールには多くのチャンスがある．求められるツールの例を挙げる．要求分析の結果，最終的に作られるのは，多くの場合自然言語で書かれた文書である．ここには，指示的文と願望的文が含まれる．しかし，インタビューなど仕様を定めるために利用した要求と，その分析に関するものは含まれない．望まれるツールは，要求の構造を保持したまま，仕様を生成できるものである．或いは，必要に応じて，インタビューのビデオなどにアクセスできること．もう一つのツールは，アプリケーション完成後に，利用状況を監視することによって，要求を進化させるようなツールである．
早くも，次の25年の中間地点を過ぎた．彼の予測は当たっているだろうか．
（nil）
モデルベースの要求抽出は，これらの疑問（どの手法をどのように使えばよいのか?）に対する答えとなる．体系だった「豊かな」モデルを使用することで，ここで述べた様々な技術を，より構造化された形で，よりムダなく，要求を抽出することが可能となる（p.82）
今回の前半は，グループセッションに関して，後半は2章のまとめである．
ここでいうグループセッションは，日本で云えば合宿であろうか．小規模であれば，会議室に籠もるということになるか．
利用可能な方法は，いつもの通り，構造化された方法とされていない自由な方法の2種類があるとしている．
構造化されたグループセッション
参加者の役割は，事前に決めておく．リーダ・報告者・ユーザ・開発者などである．重要な新システムの機能について，それぞれの立場から議論を行う．手法としては，JAD(Joint Application Development) やQFD(Quality Function Deployment) といった体系だった方法を使用する．
自由なグループセッション
こちらは小規模なものである．いわゆるブレインストーミングである．最初の段階では，自由なアイデア出しをする．第二段階では，合意のとれた基準（e.g. 効率性・実現可能性など）に従って，整理を行い，優先度を付加する．
さて，2章のまとめである．2章では，さまざまな技術が紹介された．体系立てることへの熱意を感じる．
まとめは，冒頭の文に集約される．当然である．
モデルベースの手法であるKAOSの紹介が待ち遠しいが，まだ少し準備が続く．エバ・ハッサン先生が出演していた「テレビでアラビア語」の物語のようでもある．
(nil)