重要な品質である完全性・十分性・適切性は，相対的なものである．それらは，新システムの目的や必要性に依存している．(p. 36)
ここでは，要求策定プロセスにおける品質尺度（quality factor）を定義している．前回のスパイラルモデルの第三象限では，「品質を保証する」とある．これは文書化された要求に対する活動なので，その要求文書をどう評価するかという視点が必要になる．
簡単に，要求文書の品質尺度について，KAOSの定義を下表に示す．
| 完全性 | 将来システム全ての目的を満足することを十分に保証するように，要求・前提・ドメインプロパティが記載されている |
| 一貫性 | 要求・前提・ドメインプロパティが，相互に矛盾がないこと |
| 十分性 | 要求は，新システムに対する実際的な必要性を示していること．それは，ステークホルダによって明示的に示されているものと，暗黙的に示されるものがある |
| 明白性 | 要求・前提・ドメインプロパティは，異なる解釈が生じないように記述されなければならない（ちなみに，英語ではunambiguity．曖昧性のなさという訳語もあるが，否定表現で分かりづらいので明白性とした） |
| 測定可能性 | 要求は，あるレベルの精確さで表現されなければならない．あるレベルというのは，例えば分析者であれば代替策を考えることができる．開発者ならば，実装が要求を満足しているか否かを検証することができる |
| 適切性 | 要求と前提は，将来システムの根拠を与える一つ以上の目的を満足しなくてはならならい（機械世界で動くというのではなく，問題世界において，役立つ） |
| 実現可能性 | 要求は，予算・スケジュール・技術上の制約という点から，実現可能なものではなくてはならない |
| 理解容易性 | 要求・前提・ドメインプロパティは，要求仕様書を必要とする人にとって理解できるものでなくてはならない |
| 良い構造 | 良い要求仕様書は，その文書構造において，要素間のリンクを重視したものでなくてはならない．用語定義は，その利用に先立ち，洗練リンク・依存リンク・原因ー結果リンクなどが示されなければならない |
| 修正容易性 | 要求文書の改訂・適合・コンパクト化が可能でなければならない．また，このとき，局所的な変更が可能でなければならない |
| 追跡可能性 | 要求文書中のある項目が，作成され・修正され・利用された文脈を容易に見つけることができること |
以前に見たように，一般的な意味での要求は，KAOSの場合は，｛要求，前提，ドメインプロパティ}の組となる．
有名なIEEE-830:1988 のガイドライン（IEEE Recommended Practice for Software Requirements Specifications）には，よいSRS（ソフトウェア要求仕様書）の特性というのがある．このガイドラインにあって，上記の表にないのは，「重要性・安定性に従ってランク付けされているか」という項目である．逆に，KAOSの表のなかにある実現可能性・理解容易性・良い構造といったものは，830の良い特性中には存在しない．
(nil)