第7章さまざまな要件の識別(P87)

ようやく推敲フェーズに向かっての準備だ！なんか実際にやってるような気分になってきた（笑　っていうか、ユースケースを書き終わっての、この微妙な隙間を埋めてくれているのはとってもかゆいとこに手が届いてる感じで嬉しいかも！

補助仕様書(P91)

ユースケースや用語集で捕らえられにくい要件,情報,制約を記述する（ユースケースの中で、特別な要件として捉える人もいる）

設計上の早期の意志決定および制約はほとんどの場合、適切ではない。
こういう場合は（特に方向付けフェーズで少ししか分析が済んでいない場合）
疑いを持って取り組みなおすべきである。

ビジョン文書(P96)

同じ問題に取り組んでいるか。それは適切な問題か。
（グループアイデア促進手法が効果的）

問題の説明を行う：早期の要件作業において、問題点を簡潔に説明することにより、利害関係者がほんの少ししか違わない問題を個別に解決しようとする可能性を減少させる。
重要な日機能的目標および品質目標を明らかにする
根源的な問題と目標の連鎖を調査する

機能的要求をユースケース以外の方法で表現する：システム機能(P98)

- 利害関係者が、注目すべき機能がすぐ分かるような短い要約を求めた場合。
- ユースケース名の羅列→リストが多すぎる。名前だけでは重要な機能性が伝わらない。
- 注目すべき機能性の中に、ユースケースや、EBPにうまくマッピングしない場合
- 複数のユースケースにまたがったり、かかわらない場合
- システム機能として、機能性の説明が必要なもの（例次のバージョンはEJB2.0エンティティBeanをサポートする必要がある！みたいな時）

システム機能はシステムが「行える」こと。システム機能は下記の判定文をパスする。
　【システムは＜システム機能×＞を行う。】　（例）システムは支払い承認を行う。
　※システム機能のほとんどは、ユースケースの詳細な表現の中に記述されるはず
　※ビジョン文書に記述するシステム機能の個数は、50未満であることが望ましい。
　　それ以上になる場合は、システム機能のグループ分けや抜粋を検討すること。
　※機能的要件以外の要件を、ビジョン文書、補助文書の両方に書くこと。
　　ユースケースにおいて繰り返したりすることは、くれぐれも避ける

推奨する順番（固定するのはあまり有益ぢゃないけど）

ビジョン文書のドラフトを書く
ユーザー目標と,関連するユースケースを識別する
いくつかのユースケースを書き,補助文書に着手する
上述の文書からの情報を要約し,ビジョン文書を改良する

用語集（データ辞書）(P102)

用語集の作成は、かなり早い段階で始めるべし！
用語集の目標：明確にする必要のある語を記録すること（データの集合体や、合成語なども含めていく）

項目の候補

- 別名
- 説明
- 書式(種類,長さ,単位）
- 他の要素との関係
- 値の範囲　→システムの振る舞いについてかかわるので注意
- 検証ルール　→システムの振る舞いについてかかわるので注意