「要求」は、「仕様」と違って細々と記述しません。そこで実現して欲しいことは何なのか、を明快に言い当てます。「要求」の役割は、そこから必要な「仕様」を導き出すことにあります。「仕様」を書く人も、それをチェックする人も、そこに示された「要求」から「仕様」を導き出すのです。したがって「要求」の表現が適切でないと、いい「仕様」は出てきません。
（インデックスに戻るときはウィンドウをクローズしてください）
要求のモレを防ぐために、システムを幾つかの機能のカテゴリに分けます。たとえば、
１．起動
２．印刷データの表示
３．スプールへの操作
というように、適当なカテゴリに分割し、その中で実現したい要求を表現します。カテゴリの前に付けられた数字は、分類番号となり、「起動」の中で記述される「要求」は、
「１．１ 簡単な操作で起動できること」
「１．２ 起動したあとは、起動中であることを表示して欲しい」
「５．１ プレビュー画面から、任意のページを印刷したい」
というように枝番号がつきます。
このカテゴリの分類が無ければ、要求は無秩序に表現されることになり、要求そのもののモレを発見しにくくなります。また、要求の表現が適切かどうかの判断もはっきりしなくなります。「要求書」のレビューは、主に、
・機能カテゴリが、そこで求められている機能を網羅しているかどうか、さらに
・カテゴリ内の要求が適切でモレていないか、
をチェックすることになります。
さらに、このカテゴリは、そのまま「要求仕様書」に持ち込みます。これによって、「要求」と「要求仕様」の対応を確認できます。
（インデックスに戻るときはウィンドウをクローズしてください）
「要求」は、仕様と違って、その表現は１行から２行程度で簡潔に行われます。それ以上の長い文章に成るときは、一般に、「理由」が延べられていたり、複数の要求が混じっていたり、その要求の説明が行われたり、「要求」と「仕様」が混じっていたりします。
一つの機能カテゴリで２つ以上の要求がある場合、それらが矛盾していない限り、「仕様」では、その全ての要求を満たすことを考えます。その際、「要求」は一体何だったのかが簡潔に捉えられることが重要になります。
したがって、「要求」は簡潔にまとめ、それ以外に、必要に応じて「理由」「説明」「補足」などというキーワードを使って要求を補うことをお勧めします。
（インデックスに戻るときはウィンドウをクローズしてください）
一般に要求には、それが存在する「理由」があります。そのような要求を実現しなければならない理由とか、製品の特性から表示や操作にそのような配慮が必要な理由があります。その「理由」を、個々の要求の下に明確に付けておくことをお勧めします。
要求：高速通信に堪えられるようにパフォーマンスを上げて欲しい
理由：そうでないと数年後に商品の価値がなくなってしまう
要求：動作している状況が見えるようにして欲しい
理由：不用意に電源を落とされてしまうのを防ぐため
このように、要求には「理由」が存在します。もちろん、「仕様」にも「理由」が成立することがありますが、「仕様」の場合は、表現の細かさに幅があったりして、必ずしも「理由」が見えるとは限りません。でも、「要求」には「理由」は存在するはずです。
逆に、適切な「理由」が浮かばない時、あるいは強引な理由になっている時は、要求の捉え方が適切ではなかったり、「要求」ではなく「仕様」の可能性があります。つまり「仕様」が「要求の殻」をかぶっている可能性があるのです。
要求の「優先度」なども、通常は、このような理由などの背景から決まることもあります。したがって「理由」が示されていないことが、優先度に対する考えがまとまらないことにも繋がっています。
ただし、全ての要求には、その背後に要求として存在する理由があるとしても、現実問題として、何百何千とある要求の全てに理由を添付することは困難かも知れません。その開発体制の状態やそのために掛かるコストなどを総合的に考えて、どこまで「理由」を書くか決めることになります。たとえ“良いこと”であっても、コストを無視しては成立しないことがあります。
要求に「優先順位」或いは「優先度」を付けるのも有効ですし、実際に必要な場面も少なくありません。
＜mem：メモリー＞
□□□M mem.001:
□□□Ｗ mem.002:
：
あまり細かく分類する必要は無いと思いますので、上の例のように、
Ｍ：must ・・・必須
Ｗ：want ・・・希望
あるいは、
Ｆ：first ・・・・第１段階
Ｓ：secound ・・・第２段階
Ｔ：third ・・・・第３段階
といったように、２〜５段階で、優先度を表す記号を用意し、それを個々の要求の前に付けます。
優先度は、個々の要求に対してだけでなく、一段上の機能カテゴリ単位に付けることも考えられますし、上の例のように、一つのカテゴリ内に複数の要求があって、そのそれぞれに対して異なる優先度が付けられることもあり得ます。
優先度は、単に「必要性」の観点からだけではなく、ハードや開発環境などが整う時期などによって設定されることもありますし、リスクを分散させるために優先度を分けることもあります。これらの情報は、開発のライフサイクルの選定にも重要な情報となります。つまり、開発方法として、スパイラル方式や、インクリメンタル方式などを採用する場合、どの機能から実現するか判断する際の手掛かりとなります。
また、優先度が割り付けられていることによって、途中でスケジュールが逼迫したときや、メモリサイズの見通しが誤ったときなど、機能のトレードオフの判断に使えます。