（スクラッチから作るとしても）システムを全くのゼロから創造することはマレである (p.72)
全くの新しいコトを思いつくのは，激しい思考を必要とする．かつ成功するとは限らない．芸術の世界は，おそらくこのゼロからの創造である．
芸術家ではない普通の人は，何かベースになるもの（それは，現状システムであるかもしれないし，どこかで見かけたシステムかもしれない）から，要求を作り上げることになる．
少し体系立てて，既存の知識を再利用しようというのがここでの狙いである．
今回は，問題領域には依存しない知識を利用することを考える．
KAOSの教科書では，性能要求を考える上で，かつて紹介したNFR(非機能要求, Non-Functional Requirements)本 から，題材をとっている．
しかし，せっかくなので，NFR本から，セキュリティの例を取りあげることにする．
NFR（非機能要求）本にあるカタログから．セキュリティの例
これが，NFRのカタログのうち，セキュリティに関するものである．NFRタイプというのが，最上位のタイプ（型）になっている．矢印は，サブタイプ（副型）の関係である．例えば，セキュリティは，可用性・十全性・守秘性・運用上のセキュリティというサブタイプを持つ．
特に右側のNFR特性のサブタイプは，異なった側面を示している．ライフサイクルは，開発／運用のそれぞれで，考慮すべきこと．内部-外部は，計算機の内部ｰ外部で考慮すべきことを示している．
この記述があれば，各タイプを利用して，質問を投げかけることができる．それによって，モレを防ぐことができる．
- システムが扱う完全性の対象とするデータは何か
- 開発時のセキュリティ確保（例えば，守秘性の対象となるデータのログ出力の禁止）にはどう対応するのか．
ここで示したサブタイプ関係は，ドメイン非依存である．従って，対象によらずに広く使用することができる．
(nil)
動作する部分的な製品を示すことで，他の人に，その製品の特徴が明らかになる．そうすることで，不十分或いは，失われた特徴を明らかにすることが出来るかもしれない (p.70)
前回の絵コンテおよびシナリオであった．それらは，プレゼンテーションソフトで作った（一連の）絵に相当する．その類比でいくと，プロトタイプは，編集可能なアニメーションとなる．
ソフトウェアには，2つの軸がある．
最初が，機能的プロトタイプか，ユーザインターフェイスプロトタイプかである．
前者では，主たる機能を作り込み，その機能を確認する．後者は，使い勝手の確認のために作成され，使用性を評価する．
次の軸は，使い捨てか，発展的に使い続けるかである．
前者は，あくまでプロトタイプのためにだけ作成する．実際の製品は，別途最初から作られる．後者は，スパイラルモデルに適している．確認をとりながら拡張し，最終的な製品とする．一般的には，前者となる．最終的な製品の規模が大きいときに，規模の影響を最初から見込んだり，それをプロトタイプに含むことは，動くもので確認するという目的から離れるからである．
一般には，プロトタイプを作りつつ，基本的な技術要素についても確認し，そこでの経験を元に最初から作るというのが自然である．
ところで，ハードウェアのプロトタイプは，製品価格の何倍もになる．ソフトウェアはどうだろうか．組み込みシステムの場合は，同様かもしれない．エンタープライズ系だと超えることはない．これは，大量生産するか否かの違いだけかもしれない．以前ほど，ソフトウェアのプロトタイプが話題になることはなくなっている．
ソフトウェア中心のシステムが増えたときに，プロトタイプに対する適切な評価が，コストを含め与えられべきだと思う．しかし，製品ソフトウェアが永遠のプロトタイプでありつづけるのかもしれない．
(nil)
「物語」の利用は，要求工学の初期段階において，有益な情報を引き出したり，その確認をするのに役立つ．それは，物事が現状システムにおいてどう動作し，新システムにおいてどう動作すべきかの具体的な例となるからである(p.67)
ここでは，2つの方法を示している．一つは，絵コンテ（storyboard）と呼ぶ方法であり，もう一つがシナリオ（scenario）と呼ぶ方法である．
絵コンテは，ある時点のシステム状態を記述する．登場人物は，システムに関係する人たちである．絵コンテは，静的なもの．システムと登場人物の関係を記したものとなる．
いわゆる5W1Hを加えることで，よりシナリオ的になものを作ることができる．下記は，例である ．
- 誰が，（物語の登場人物として）参加するのか
- 何が，そこでは起きるのか
- どうやって，特定のエピソード（挿話）を通して，それが起きるのか
- どうして起きるのか
- もし，あれやこれやのイベントが起きたらどうなるか
- 結果として，何かまずくなるか
これは，絵コンテを作成しながら，自分自身に問いかけるときに使うことができる．或いは，絵コンテを見ながらの質疑と考えることもできる．
3番目からは，物語的とは言いづらい．或いは，物語的かもしれないが，このままだと救いがない．ちなみに，ここでは，エピソードというのは，物語の筋と比べ，より詳細な登場人物ーシステム間のやりとりになる．
5番目は，先取りをするとユースケースにおける代替系列ないしは例外系列に相当する．これが主系列だとすると，物語としては，6のままでは終われず，続きを考える必要がある．
シナリオは，目的を達成するために，システムのコンポーネント（もちろん，そこにはユーザも含む）間で，どのような情報のやりとりがあるかを示す．時系列の流れとして示す．
シナリオには，2つの軸があるとしている．
ポジティブ vs. ネガティブ
ポジティブなシナリオとは，新システムが振る舞うべきイベントの流れを示す．会議管理システムの例だと，開催者が会議を希望する日程の範囲と場所を提示する．参加予定者が，可能な出席日を連絡する．全員参加できる日の中から，開催日を決めて，参加予定者に連絡する．そういう流れである．
一方でネガティブ流れとは，次のようなものである．ある出席者が，候補日の全てで都合が悪いとした．システムはそれを，参加者全員にフォワードし，再考を促したという流れである．特に先の例と違いはなさそうだが，プライバシーの観点から問題があるかもしれない．個人の予定を他者に通知してはいけないとすると，このシナリオは，そう動作してはいけないものとして提示されることになる．
ポジティブシナリオは，システムが振る舞うべき例として示され，ネガティブなシナリオは，システムが振る舞うべきではない例として示される．
正常 vs. 異常
正常シナリオは，普通に考えつくものである．全てが予定通りで，システムが正しく機能を実行する場合である．異常シナリオは，先の5に似ている．いわゆる，What-if （もし，〜だったら）で考える．例えば，先の会議管理システムでいえば，そもそも参加予定者が誰も返事しなかったら，と考えることである．
これを思いつくのは，とても難しい．そのため，What-ifを支援する多くの方法がある．しかし，良いプログラマにとって，異常シナリオを考えることは，慣れたことかもしれない．
（nil）