要求のカテゴリ
非機能要求
非機能要求は，ソフトウェアが機能要求を満足するとき，或いは開発中に満足すべき制約を定義している (p.24)
例としては，以下が挙がっている．
- 文献検索を行う時および結果を表示する時のフォーマットは，コンピュータの経験がない学生にも利用可能であること
- 加速指令は，全ての列車に対して３秒ごとに送信すること
- 参加者のスケジュール制約は，他の出席予定者に開示されないこと
非機能要求というのは，機能要求に比べると注目されることが少ない．原書で挙げられている書籍のうち，古典的となっている教科書に，NON-FUNCTIONAL REQUIREMENTS IN SOFTWARE ENGINEERING がある．
本のタイトルは，ソフトウェア工学における非機能要求と，いわばカテゴリ名そのままである．よく整理された本であり，（非機能要求に対する関心が低いことも相まって）今後この本を超えるのはなかなか難しいと思う．以下，書名が長いので，NRF本ということにする．
NRF本の前半では，非機能要求のタイプについて議論している（5章）．サーベイの結果として，161の非機能項目が挙がっている（数え間違いしていなければ）．もちろん，この項目一つ一つについて議論する訳ではなく，フレームワークを用いて，正確性・セキュリティ・性能について詳細な議論を進めている．
Lamsweerdeさんは，上記のNRF本を引用した上で，分類を示している．もちろん，網羅的ではないという但し書きつきでだ．下図は，機能・非機能の機能分類で，赤曲線枠内が，非機能に関連している．
さて，NRF本のおもしろさは，フレームワークにある．ちょうどKAOSゴールモデルとGSNを融合したような形式を持つ，汎用的な枠組みである ．ただ，ここで横道には入らないでおく．
(nil)
要求のカテゴリ
この項では，様々な要求のカテゴリを取りあげている．順番に見ることとしたい．
機能要求
機能要求は，将来ソフトウェアが環境中で持つべき機能的効果を定義している (P.23)
以前に「なに」次元で見たように，規範的記述である．以下に，原書にある例を示す．
- 文献検索エンジンは，キーワードに関係する図書館所有の本のリストを示すこと
- 列車制御ソフトウェアは，全てのシステムが管理する列車の加速を制御すること
- 会議スケジューラは，出席予定者のスケジュール制約を満足するようにスケジュールを決めること
原文では，全て”shall”を用いる記述になっている．ISO の規格日本語訳などでもおなじみの表現で，まさに要求事項を示している．さて，この次にまた不思議な文がある．
さて，そのような要求によって得られる効果は，”ソフトウェアが実行した「操作」によって生じる”と，している．
ここは，読むときに引っかかりがあった方が良い箇所と思う．おそらくわざと考えさせるような文にしている．要求でそういうソフトウェアを作れと書いてあるので，できたソフトウェアがその通りに動作するのは，当たり前ではないかと思う．まさに，その当たり前のことを書いている．ただ，ここでは，ソフトウェアの動作に名前をつけたいと考えている．その名前が，ソフトウェアの「操作」である．
この箇所に限らないが，パートIは，おそらくパートIIないしはパートIIIのあとに書かれている．少なくとも Lamseweerde さんの思考としては，パートIIと拡張・実験としてのパートIIIを繰り返している．その結果を，パートIへと抽象化したと考えている．
この本が出版されるまでの10年間ほどの間に，実に多くの論文がLamsweerdeさんによって書かれている．この本の物理的並びのように，抽象から具象へ進んでいるというより，具象から抽象が生まれている．従って，そのベースとなる具象が，抽象の議論に顔をだす．この「操作」概念も，同じであり，のちにKAOS法における重要な要素として紹介される．
さて，ここでは，幾つかのまとまった機能の集合をフィーチャー(feature)と呼ぶとして，ごく簡単にふれている．ここでのフィーチャは，プロダクトファミリーの議論にあるフィーチャとは違っている．もっとも，プロダクトファミリーについても，本書では軽い記述しかない．このパートは，要求の包括的な議論であり，記載が少ないことが，逆にとても興味深い．
(nil)
定義からいって，ソフトウェア要求は，システム要求である．しかし，逆は成立しない．あいまいさがないところでは，要求といえば，システム要求を指す (p.19)
システム要求 SysReq は，次のように記述できる．いま，Mが監視している変数の集合で，制御対象変数の集合をCとする（一般的なコントローループラントモデル）．このとき，次が成立する
SysReq ⊆ M × C
ソフトウェア要求 SofReq は，次のように記述できる．同様に，入力変数の集合をIとし，出力変数の集合をOとする．
SofReq ⊆ I × O
この2つの式は，当たり前のようにも見えるし，本当かと思ったりもする．
どのような記述が適切かは，システムやソフトウェアをどうモデル化するかに依存している．ここでは，システムにしろソフトウェアにしろ，入力を変換して出力する機械とみなす．もちろん，対象は異なる．システムの場合，監視している変数（例えば，自動車の場合，現在速度や車軸回転数）から制御対象の変数（アクセル開度が決まる）．M × Cというのは，直積を示す（要求と関する部分が，かなり疎なマトリクスになる）．ソフトウェアの場合も同様である．ただ，監視や制御ではなく，入出力といういい方に変わる．
さて，次は，SysReqとSoftReqの関係である．
前回は，ドメインプロパティと前提について見た．ここで復習を兼ねて，ドメインプロパティ（Dom）と前提（Asm）の関連する記述を示す（p. 22）
| システム要求 |
SysReq |
TrainMoving → DoorsClosed |
| ソフトウェア要求 |
SoftReq |
MeasuredSpeed ≠ 0 → doorsState = ‘closed’ |
| ドメインプロパティ |
Dom |
TrainMoving ↔ trainSpeed ≠ 0 |
| 前提 |
Asm |
measuredSpeed ≠ 0 ↔ trainSpeed ≠ 0 |
| DoorsState = ‘closed’ ↔ DoorsClosed |
ドメインプロパティは，環境側（システムが埋め込まれる世界）であり ，前提は環境とソフトウェアの共通領域なので，DOMとASMを利用して，システム要求 SysReq とソフトウェア要求 SofReq を結びつけることができる．
{SOFREQ, ASM, DOM} ⊨ SysReq
これは，左側が成立すれば，右側を満足するという一般的な読み方でもよいし，左側が右をモデル化していると読むこともできる．
(nil)