要求のカテゴリ
法規適合（Compliance）要求
法規適合要求は，国内法・国際法・社会的規範・文化的ないしは社会的制約・規格等に関して，環境に対してソフトウェアが与える影響を規範的に記述したものである (p. 27)
例としては，次が挙げられている．
- 後続列車との最悪停止距離値は，国際的な鉄道規則に適合していること．
- 会議管理は，ターゲット市場における公式の休日を，初期値としては除外すること．
アーキテクチャ要求
アーキテクチャ要求は，将来ソフトウェアが環境に適合するための構造的制約を示している．
ここでも幾つかの例が示されている．
- 列車に搭載される制御器は，駅に設置されるコンピュータから送信される加速指令の受け取り，適切に実行しなくてはならない．
- 会議管理ソフトウェアは，様々な国に分散している参加者の利用している電子メールシステム，電子アジェンダ管理システムと連携することが望ましい
- 会議管理ソフトウェアは，次のOSで動作することが望ましい．（指定OS）
開発要求
開発要求は，ソフトウェアが，どのように機能要求を実現するかに関わらない．しかし，どのように開発されるべきかを規定している．ここには，開発コスト，スケジュール，フィーチャのバリエーション，保守性，再利用性，移植性などが含まれる．
例としては，次が示されている．
- 新しい不思議の国大学図書館ソフトウェアのコストは，Xを超えないことが望ましい
- 列車制御ソフトウェアは，2年以内の運用開始が望ましい
- ソフトウェアは，次の点で，カスタマイズ可能であることが望ましい．会議種別（組織か個人化，規則的か単発か），会議場所（毎回固定か，変化するか），参加者（常に同じか，重要性によって変化するか）．
ここまでで，要求の分類が一通り出揃っている．大きくは，機能要求と非機能要求に分かれる．非機能要求は更に，品質と今回扱った法規適合・アーキテクチャ・開発要求に分かれるとしている．
最初に少し戻る．「なぜ」次元では，目的を深く分析する．結果として得られた要求は，「なに」次元に属する．「なぜ」次元では，様々な検討や理由が生じる．しかし，「なに」次元では，どのような検討がなされ，どうしてそうなのかといった情報が欠落する．機能要求がそうであったように，規範的な記述（〜すること）を中心に書くことになるからである．上記でみたように，非機能要求は必ずしも規範的文ではなく，そこにはゴール検討時に現れた代替策や期待が現れることになる．
（nil）