異なった種類のプロジェクトがある．[…] 1.1.6 で議論したREプロセスに手を加えることが必要になるかもしれない (p. 40)
ここでは，幾つかのプロジェクト種類を定義している．ソフトウェアプロセスの観点からは，大変に興味深い箇所である．
新規開発プロジェクトと再開発プロジェクト[ref]英語では，greenfield vs brownfieldプロジェクトとなっています．greenfieldとは緑の草が生えていて，これから新たに開発を待つというイメージです．一方で，brownfield は，かつては栄えたが今は寂れているくすんだ街という意味で使われることが多い．否定的な意味を持っています．従って，ここでは，緑色の場所 vs 茶色の場所といった視覚的で魅力的なタイトルは使わずに，単に新規開発と再開発としています[/ref]
新規開発プロジェクトでは，全く新しいソフトウェアが作られる．このとき，現状システムの問題を調べ，技術進化や市場の状況を見て，新しい仕様が作られる．
再開発プロジェクトの場合，現状システムは，既にサービスを行っている．将来システムは，それらを統合し・向上し・適応し・拡張しなければならない．
これは，既存システムをムシできるか，或いは，既存システムと折り合いをつけながら開発を進めるかという違いになる．更なる発展として，「通常設計」と「ラディカル設計」という概念が紹介されている[ref]What Engineers Know and How They Know It: Analytical Studies from Aeronautical History (Johns Hopkins Studies in the History of Technology)[/ref]．通常設計では，開発者は既存技術を向上し，或いは新しいやり方で既存技術を利用する．そうして，問題を解決する．一方，ラジカル設計では，まったく新しい技術を創造することになる．このとき，最初に要求仕様を作る人は，十分な記述ができるのだろうか（例えば，17回でみた実現可能性は書きにくいものの一つに違いない）．
特定顧客のためのプロジェクトと市場を対象にするプロジェクト
特定顧客のためのプロジェクトでは，具体的な必要性に応じて，開発を行う．市場を対象とするプロジェクトでは，対象の市場セグメントの潜在的な必要性に応じて，開発を行う．
組織内の開発とアウトソースによる開発
組織内の開発では，開発主体は，開発期間中，自組織である．一方でアウトソースによる開発の場合は，プロジェクトの要求が確定した後は，委託先によって開発を行う．
単一製品プロジェクトとプロダクトラインプロジェクト
単一製品プロジェクトでは，製品は特定の顧客のために作られる．プロダクトラインプロジェクトにおいては，複数の変種（variant）に対応できるよう開発を行う．このとき，製品は，特定のユーザクラス，特定のアイテムクラスに対応する．各変種間では，共通点と変異点（variation point）における差異がある．
ソフトウェアプロジェクトは，上記に示した次元のどこかの場所にいる．例えば，会議管理システムは，新規開発で・市場を対象として・組織内の開発であり・プロダクトラインプロジェクトである．
さて，「特定顧客のためのプロジェクトと市場を対象にするプロジェクト」を考えてみる．市場を対象にする場合，厳格な要求仕様書を書くことの意味は小さい．対象とするセグメントが期待していることは，所詮想像に過ぎない．そもそも，市場そのものが開発期間中に変化する．
「組織内の開発とアウトソースによる開発」も同様である．この両者で，要求仕様書という文書の重み付けは違う．組織内であれば，文書の変更も容易であり，文脈を共有することで，不必要な記述もある．一方で，アウトソースの場合は，明らかに異なる．不必要と思えることでも，異なる組織であれば，記載が必要なこともある．
従って，上記に示されるような次元を考慮した上で，適切な記述のレベルが，都度存在する．それを考えること（いわば設計すること）が重要であり，2者間取引に限定した方法を敷延するとか，特定顧客のための開発方法を，単純に強調するというのは，要求分析に限らず，意味がないことが分かる．
(nil)
誤りと不備
省略は，検出が難しい．しかし，いつでも生じる (p. 38)
ここでは，要求仕様書に存在するかもしれない欠陥についての記述である．誤りと不備から構成される．
欠陥の名前は，原文でも少しくだけた名称となっているので，合わせた（やり過ぎかもしれない）．ちなみに，ここで書かれている項目の多くは，Meyerさんの有名な論文「仕様における形式性について」[ref]B. Meyer. 1985. On Formalism in Specifications. IEEE Softw. 2, 1 (January 1985), 6-26.[/ref]にあるものと共通である．くだけた書き方は不謹慎かもしれない．
なお，問題世界・機械世界とあるのは，別の場所では，世界・ソフトウェアとしている．基本的に同じである．「世界」は更に「環境」としている場合もある．これが要求だとすると，下記にも当てはまるか．
要求文書の欠陥
| 省略 |
問題世界の特性を記述していない（目的がない・要求がない・前提がない） |
| 矛盾 |
問題世界の特性記述に，不整合がある |
| 不十分 |
問題世界の特性を，十分に記述していない |
| あいまい |
異なる解釈を許す書き方をしている |
| 数値がない |
代替策と正確に比較することができない．或いは，実装した機械を検証することができない |
| ノイズ |
問題世界の特性に対して，何の情報も得ることのできない記述がある |
| 書きすぎ |
問題世界を飛び越えて，機械世界の記述となっている |
| ムリ |
指定の予算・スケジュール・開発プラットフォームで実現することは，現実的にムリである |
| 意味が通じない |
要求仕様書の利用者が，書いてある意味を理解できない |
| 文書の構造がだめ |
意味的にも視覚的にも，正しい文書の構造となっていない |
| 先走り |
まだ定義していない問題世界の特性を使っている |
| 深い後悔 |
問題世界の特徴記述のタイミングが遅かったり，気まぐれで書かれている |
| 修正できない |
特定の箇所を修正しようとすると，要求文書全体に影響がでてしまう |
| 不明瞭 |
理由・担当・依存関係が不明である |
赤字の項目は，誤り（errors）で，その他は不備（flaws）としている[ref] すなわち，欠陥（defects）:= 誤り + 不備である[/ref]．当然，前者の方が問題になる．
(nil)
重要な品質である完全性・十分性・適切性は，相対的なものである．それらは，新システムの目的や必要性に依存している．(p. 36)
ここでは，要求策定プロセスにおける品質尺度（quality factor）を定義している．前回のスパイラルモデルの第三象限では，「品質を保証する」とある．これは文書化された要求に対する活動なので，その要求文書をどう評価するかという視点が必要になる．
簡単に，要求文書の品質尺度について，KAOSの定義を下表に示す．
KAOS 要求文書の品質尺度
| 完全性 |
将来システム全ての目的を満足することを十分に保証するように，要求・前提・ドメインプロパティが記載されている |
| 一貫性 |
要求・前提・ドメインプロパティが，相互に矛盾がないこと |
| 十分性 |
要求は，新システムに対する実際的な必要性を示していること．それは，ステークホルダによって明示的に示されているものと，暗黙的に示されるものがある |
| 明白性 |
要求・前提・ドメインプロパティは，異なる解釈が生じないように記述されなければならない（ちなみに，英語ではunambiguity．曖昧性のなさという訳語もあるが，否定表現で分かりづらいので明白性とした） |
| 測定可能性 |
要求は，あるレベルの精確さで表現されなければならない．あるレベルというのは，例えば分析者であれば代替策を考えることができる．開発者ならば，実装が要求を満足しているか否かを検証することができる |
| 適切性 |
要求と前提は，将来システムの根拠を与える一つ以上の目的を満足しなくてはならならい（機械世界で動くというのではなく，問題世界において，役立つ） |
| 実現可能性 |
要求は，予算・スケジュール・技術上の制約という点から，実現可能なものではなくてはならない |
| 理解容易性 |
要求・前提・ドメインプロパティは，要求仕様書を必要とする人にとって理解できるものでなくてはならない |
| 良い構造 |
良い要求仕様書は，その文書構造において，要素間のリンクを重視したものでなくてはならない．用語定義は，その利用に先立ち，洗練リンク・依存リンク・原因ー結果リンクなどが示されなければならない |
| 修正容易性 |
要求文書の改訂・適合・コンパクト化が可能でなければならない．また，このとき，局所的な変更が可能でなければならない |
| 追跡可能性 |
要求文書中のある項目が，作成され・修正され・利用された文脈を容易に見つけることができること |
以前に見たように，一般的な意味での要求は，KAOSの場合は，｛要求，前提，ドメインプロパティ}の組となる．
有名なIEEE-830:1988 のガイドライン（IEEE Recommended Practice for Software Requirements Specifications）には，よいSRS（ソフトウェア要求仕様書）の特性というのがある．このガイドラインにあって，上記の表にないのは，「重要性・安定性に従ってランク付けされているか」という項目である．逆に，KAOSの表のなかにある実現可能性・理解容易性・良い構造といったものは，830の良い特性中には存在しない．
(nil)