要求のカテゴリ
この項では，様々な要求のカテゴリを取りあげている．順番に見ることとしたい．
機能要求
機能要求は，将来ソフトウェアが環境中で持つべき機能的効果を定義している (P.23)
以前に「なに」次元で見たように，規範的記述である．以下に，原書にある例を示す．
- 文献検索エンジンは，キーワードに関係する図書館所有の本のリストを示すこと
- 列車制御ソフトウェアは，全てのシステムが管理する列車の加速を制御すること
- 会議スケジューラは，出席予定者のスケジュール制約を満足するようにスケジュールを決めること
原文では，全て”shall”を用いる記述になっている．ISO の規格日本語訳などでもおなじみの表現で，まさに要求事項を示している．さて，この次にまた不思議な文がある．
さて，そのような要求によって得られる効果は，”ソフトウェアが実行した「操作」によって生じる”と，している．
ここは，読むときに引っかかりがあった方が良い箇所と思う．おそらくわざと考えさせるような文にしている．要求でそういうソフトウェアを作れと書いてあるので，できたソフトウェアがその通りに動作するのは，当たり前ではないかと思う．まさに，その当たり前のことを書いている．ただ，ここでは，ソフトウェアの動作に名前をつけたいと考えている．その名前が，ソフトウェアの「操作」である．
この箇所に限らないが，パートIは，おそらくパートIIないしはパートIIIのあとに書かれている．少なくとも Lamseweerde さんの思考としては，パートIIと拡張・実験としてのパートIIIを繰り返している．その結果を，パートIへと抽象化したと考えている．
この本が出版されるまでの10年間ほどの間に，実に多くの論文がLamsweerdeさんによって書かれている．この本の物理的並びのように，抽象から具象へ進んでいるというより，具象から抽象が生まれている．従って，そのベースとなる具象が，抽象の議論に顔をだす．この「操作」概念も，同じであり，のちにKAOS法における重要な要素として紹介される．
さて，ここでは，幾つかのまとまった機能の集合をフィーチャー(feature)と呼ぶとして，ごく簡単にふれている．ここでのフィーチャは，プロダクトファミリーの議論にあるフィーチャとは違っている．もっとも，プロダクトファミリーについても，本書では軽い記述しかない．このパートは，要求の包括的な議論であり，記載が少ないことが，逆にとても興味深い．
(nil)