既に述べたように、全てのドキュメントは、生成することだけが目的ではありません。常に「利用」することが考えられていなければなりません。その意味で、上に述べたような構成で記述するというだけでは、必ずしも、「利用」を促進しません。
ここでは、その後の利用価値を高めるちょっとした配慮について説明します。
（インデックスに戻るときはウィンドウをクローズしてください）
「仕様」は「要求」から導き出されます。
たとえば、
＜５．プレビュー＞
「５．１ 印刷前に、画面上でプレビューさせたい」
「５．２ プレビュー画面から、任意のページを印刷したい」
という要求から、
「５．１ プレビュー時の画面は・・・・とする」
「５．２ 縮小・拡大は２０％〜３５０％までとし、複数ページは同時には表示しない」
「５．３ プレビュー画面から、用紙の設定（サイズ、紙質、方向の選択）ができる」
「５．４ 画面の上部に“このページ印刷”と“印刷”の２種類のボタンを用意し、
“このページ印刷”が選ばれたときは、印刷要求を出した後、再びプ
レビュー画面に戻る。用紙の設定等は可能なこと。また“印刷”が選ば
れたときは、そのまま通常の印刷画面を呼びだし、通常の印刷の操作に入る。
終わった後は、プレビュー場面には戻らない。
「５．５ ・・・」
という「仕様」が導き出されます。
これに対して、「要求」が不適切だと、適切な「仕様」が引き出せません。
たとえば、
＜７．様式の指定＞
「７．１ 様式として登録されている件数を知ることが出来る」
と言う「要求」から導き出されるのは何でしょうか？ せいぜい、どのように表示するかとか、使用率を併せて表示すると言った程度です。あるいは、このまま「仕様」にも姿を現す可能性もあります。
その原因は、これは「要求」ではなく「仕様」だからです。「仕様」が「要求の殻」を被って要求書の中に紛れ込んだのです。この場合の失敗の原因は、「件数」という具体的な要件を要求の中で使ったことにあります。たとえば、
「７．１ 登録されている様式の状況を知ることが出来る」
という要求であれば、様式ファイルの件数を表示するとか、様式の一覧表や内容をサムネールで見せるという仕様が出てきます。
このように、適切な「仕様」は、適切な「要求」から導き出されるのです。
一般に、要求仕様書は顧客にも読みやすいように、自然言語で書かれます。とはいえ、自然言語では、「判断」などの論理の表現が曖昧になりやすく、双方で認識の「差」を生み出す元となってしまいます。そこで出来るだけ「仕様」をある程度小さな単位でまとめ、簡潔に書くことが望まれます。
また、「条件」が及ぶ範囲を明確にするために、「if then ,else 」の構文を使ったり、仕様書の中で「ＰＡＤ」などの構造化フローを使うことも効果的でしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
仕様では、曖昧な表現を避けることが大切です。
例えば、「データの輻輳に注意して・・・」とか、「応答をいつまで待っても来なかったときは・・・」「出来るだけ早く応答を返す」といった表現では設計者の裁量が入ってしまい、あとでもめる元になります。
本来、要求仕様書の項目（仕様）は「テスト可能性」が求められます。つまり、その項目が「仕様どおりに」実現しているかどうかを確認できるように表現されていなければなりません。システム・テストや機能テストは、まさにそのためのテストでもあるのです。
「出来るだけ早く・・・」のような時間的な曖昧な表現が「２秒以内に・・・」と修正された途端に、幾つかの要求間で実現しない事（矛盾）が判明することもあります。
言うまでもなくこの種の問題は、現実には、設計段階あるいはテストの段階に入って判明するのですが、それでは遅いのです。
「以上」「以下」という表現も、注意が必要です。
（インデックスに戻るときはウィンドウをクローズしてください）
要求仕様書の個々の項目ごとに「要求番号（＝仕様番号）」を割り当てます。そのとき、「機能グループ」ごとに１〜３文字の記号を割り当て、その中で連続番号を付ける方法もあります。
mem.001:
mem.018:
：
com.001:
必ずしもきっちりとした「機能」単位に分ける必要はありません。何らかの機能のカテゴリに分けられていればいいと思いますが、その場合、カテゴリが明確に表現されている必要があります。通常は、要求書の段階でカテゴリ分けが行われ、カテゴリに適当な名称が与えられてきますので、要求仕様書では、そのまま継承することになります。
このユニークな番号によって、その後の設計作業において、処理と要求（仕様）を結ぶことが出来ます。その結果、設計途中で要求（仕様）の変更があったときも、設計書からその要求番号を探せば、影響範囲を間単に知ることが出来ます。（＝＞要求管理）
また、これによって要求（仕様）とテスト項目を結ぶことも出来ます。テストの網羅性などに効果を発揮する「要求ーテストマトリクス」を作るには、最初に「要求番号」を割り振っておかなければ実現しません。
さらにはソースコードに埋め込んで、要求とソースモジュールを結ぶことも出来ます。具体的な関数レベルで要求仕様書と繋がります。特に、未決事項を含んだまま設計や実装に着手している場合は、あとで変更されることが明らかですので、固有番号を活用して対応しておくべきです。
少なくとも、「機能的要求」については、この番号付けは問題なく出来るはずです。また「性能的要求」についても、ちょっと工夫すれば可能なはずです。
なお、番号付けのルールについては、その後の項目の追加や削除などの“変更”に耐えられるように、十分な工夫が必要になります。
なお、注意すべきことは、
１）登録データを一覧表示する
２）データが空の場合も枠だけは表示する
のようなトピックの区切りを示す「１）」という番号付けでは、要求（仕様）を「特定」することは出来ませんので、番号付けの効果は得られません。
（インデックスに戻るときはウィンドウをクローズしてください）
仕様の項目に割り付けた番号の前にチェック・ボックス（□）を付けることをお勧めします。
□□□ mem.001:
□□□ mem.018:
：
□□□ com.001:
要求仕様書はその後の作業に利用されてこそ価値あるものとなるのです。その度に、改めて仕様の内容を確認したり、テスト仕様書と照合したりします。このチェック・ボックスは、そのときに威力を発揮します。
チェックボックスがいくつ必要かは、最初の段階では見通せないかも知れませんが、取りあえず１つあれば、あとでワープロの「置換」機能を使って増やすことも出来ます。まずは「一つ」。