要求のライフサイクル
つまり，要求工学のプロセスは，スパイラルモデルに従って，繰り返しながら，連続的に増えていくと考えることができる（p. 34）
下図が原書に描かれているプロセスの絵になる．Boehmのスパイラルモデルに似ている．しかし，図がスパイラルというだけで，考え方は，Lamsweerdeさんのオリジナルで，意味的には異なっている．
要求工学のプロセス
ちなみに，この種のアイデアを，以前はライフサイクルモデルと呼んでいた．他には，ウォータフォールモデル（悪の代表と良く誤解される）がある．しかし，それだけである．ライフサイクルは文字通りに捉えると人生であるから，インスタンス（個々の人，プロジェクト）で考えると，本来モデル化のしようがない．生まれて年をとって死ぬだけである．
ライフサイクルというコトバは，最近では，開発や保守というプロセスを考えたときの，構成要素を指している．例えば，先の Lamsweerde さんの例だと，「問題領域を理解する」というのは一つの構成要素である．これを何回実施しようが，「問題領域を理解する」ことに変わりはない．こういう構成要素だけを定義しておいて，実際のプロジェクトに応じて，配置するというのが一般的である．
ただ，スパイラルは，数学的にも美しい．スパイラルモデルといういい方は，実際に実行する難しさを別にすれば，心地よく響く．
（nil）
要求のカテゴリ
法規適合（Compliance）要求
法規適合要求は，国内法・国際法・社会的規範・文化的ないしは社会的制約・規格等に関して，環境に対してソフトウェアが与える影響を規範的に記述したものである (p. 27)
例としては，次が挙げられている．
- 後続列車との最悪停止距離値は，国際的な鉄道規則に適合していること．
- 会議管理は，ターゲット市場における公式の休日を，初期値としては除外すること．
アーキテクチャ要求
アーキテクチャ要求は，将来ソフトウェアが環境に適合するための構造的制約を示している．
ここでも幾つかの例が示されている．
- 列車に搭載される制御器は，駅に設置されるコンピュータから送信される加速指令の受け取り，適切に実行しなくてはならない．
- 会議管理ソフトウェアは，様々な国に分散している参加者の利用している電子メールシステム，電子アジェンダ管理システムと連携することが望ましい
- 会議管理ソフトウェアは，次のOSで動作することが望ましい．（指定OS）
開発要求
開発要求は，ソフトウェアが，どのように機能要求を実現するかに関わらない．しかし，どのように開発されるべきかを規定している．ここには，開発コスト，スケジュール，フィーチャのバリエーション，保守性，再利用性，移植性などが含まれる．
例としては，次が示されている．
- 新しい不思議の国大学図書館ソフトウェアのコストは，Xを超えないことが望ましい
- 列車制御ソフトウェアは，2年以内の運用開始が望ましい
- ソフトウェアは，次の点で，カスタマイズ可能であることが望ましい．会議種別（組織か個人化，規則的か単発か），会議場所（毎回固定か，変化するか），参加者（常に同じか，重要性によって変化するか）．
ここまでで，要求の分類が一通り出揃っている．大きくは，機能要求と非機能要求に分かれる．非機能要求は更に，品質と今回扱った法規適合・アーキテクチャ・開発要求に分かれるとしている．
最初に少し戻る．「なぜ」次元では，目的を深く分析する．結果として得られた要求は，「なに」次元に属する．「なぜ」次元では，様々な検討や理由が生じる．しかし，「なに」次元では，どのような検討がなされ，どうしてそうなのかといった情報が欠落する．機能要求がそうであったように，規範的な記述（〜すること）を中心に書くことになるからである．上記でみたように，非機能要求は必ずしも規範的文ではなく，そこにはゴール検討時に現れた代替策や期待が現れることになる．
（nil）
要求のカテゴリ
品質要求
品質要求は，ソフトウェアの機能によって生じる，付加的でかつ品質に関連する特性のことである．(p.24)
前回の図において，非機能ゴールからブレークダウンした左側に，その要素が示されている．安全性・セキュリティ・信頼性・性能・インターフェイスである．再掲する．
この分類は，納得しやすい．
ところで， SQuaRE (Systems and software Quality Requirements and Evaluation ) で挙がっているのは，Lamsweerdeさんとは，異なる選択と並びになる．ちなみに，SQuaREは，ここではISO/IEC 25010:2011を指している．また，以前も触れている．
この中で，「システム／ソフトウェアの製品品質」として挙がっているのは，以下になる（日本語は，JIS X25010:2013 のもの）
- 性能効率性
- 互換性
- 使用性
- 信頼性
- セキュリティ
- 保守性
- 移植性
Lamsweerdeさんが最初に挙げていた安全性は，副特性を含めてここにはない．
もう一つのユーザ視点での「利用時の品質」は次の通り．
- 有効性
- 効率性
- 満足性
- リスク回避性
- 利用状況網羅性
安全性は，リスク回避性のなかの副特性の一つ「健康・安全リスク緩和性」の中に埋もれている．ふむ．セキュリティが，立派に特性として挙がっているのに，安全性は，副特性の一部でしかない．とても興味深い．構造上，類似している安全性とセキュリティの間で，ここまで違いがある理由のはなぜだろう．
訓詁学的に比較・検査するのはおもしろいが，今は余り有益でもなく，先に進む．
図に挙がっている品質要求のそれぞれについて，例が挙がっている．
安全要求
列車の加速制御において，後続列車との最悪ケースでの停止時の距離は，常に維持されること．
隠匿性要求（Confidentiality requirements）
スタッフではないユーザは，自己以外のユーザが何の本を借りているかを，知ることができないこと．
以下，全ての例が挙げられているが，残りは原書を参照いただければと思う．
品質特性というのは，網羅的なものではなく，その時点で重点を置くアスペクトを示しているに過ぎない．大事なのは，どの品質特性を重視するかと云うことをあらかじめ示しておくことかと思う．
（nil）