最終成果物を除いて、全ての成果物は、それが生成されることだけが目的ではなく、同時に、その後の何らかの作業に有用であることが必要となります。後の作業での利用の頻度や回数が多いほど、一般にその成果物は有用であると言うことが出来ます。
そのためには、その成果物がどの作業に使用されるか、あるいはどのように使用すべきかを、成果物の生成に取り掛かる前に考えておく必要があります。そうすることによって、成果物の構成や内容に無駄がなくなり、その結果として、その成果物を生み出す作業にも無駄がないことになります。
また、そのように構成や内容が明らかになっていることで、その成果物を生み出すために必要なデータや資料も、自ずと明白になってきます。ここまで出来ると、作業のリワークは、極端に減少します。
さて、要求仕様書は、少なくとも既に述べたような「使用目的」に耐えられるように構成される必要があります。以下に、その中の重要な項目について簡単に説明します。
（インデックスに戻るときはウィンドウをクローズしてください）
使用するハードウェア構成：周辺機器も含む
使用するＯＳ環境：
システムの想定条件：トラフィック密度
データ量
（インデックスに戻るときはウィンドウをクローズしてください）
一般に、要求仕様書の大部分が機能的要求で構成される。
機能：ユーザーやオペレータが使用する機能
その製品の有する機能
例外処理：エラー時に求められる対応
このとき、適切な機能のカテゴリに分類してまとめることが必要です。
たとえば、
１．起動方法
：
２．データの登録
：
３．データの削除
：
７．様式の変更
というように分類します。
このカテゴリの分類は、「要求書」の段階で分けてくることが必要になります。つまり、このカテゴリ分類は、要求書と一致していなければならないものです。
（インデックスに戻るときはウィンドウをクローズしてください）
「品質的要求」とも言います。
性能の指定：
パフォーマンスの指定：
プログラム・サイズの制限：
ファイル・サイズの制限：
操作性に関する規定：
保守性に関する規定：
移植性に関する規定：
信頼性に関する規定：（できるなら）
など、製品の必要に応じて規定します。実現の確認方法に注意して記述することが大事です。
なお、製品によっては、性能やパフォーマンスは「品質」ではなく「機能」として捉えられる可能性があります。
（インデックスに戻るときはウィンドウをクローズしてください）
設計上の制約：設計手法の規定
ライフサイクル・モデルの指定
ウォーターフォール（Ｖ字）
インクリメンタル
ラショナル・ユニファイド・プロセス
標準の規定：順守すべき作業標準（手順）
ドキュメントの標準
言語の指定：プログラミング言語
設計言語
など
（インデックスに戻るときはウィンドウをクローズしてください）
納入物：最終納入物
途中納入物（時期を並記）
受け入れ条件：テストの完了条件
納入後の受け入れテストの内容
満たさなかったときの対応
注意することは、納入物の構成や目的が明確であることです。成果物の「名称」だけでは、双方の思いが食い違います。
（インデックスに戻るときはウィンドウをクローズしてください）
契約の裏付けとなる開発作業が現実的なものであることを明示します。
概スケジュール：あるいは「大日程」と呼ぶこともあります。
マイルストーン：納入物と期日を明確にする
納入物をこの形で表現してもよい
納期の遅れに対する対処
このとき、 最終納期以前に「デモ」の要求があるのかどうかを確認しておく事も必要です。デモの有無は設計作業に大きく影響します。またデモの狙いや手順なども、早期に確認しておくことも重要です。場合によっては、「要求」として取り上げて、「非機能的要求」の中で展開してもよいでしょう。
（インデックスに戻るときはウィンドウをクローズしてください）
一旦、要求仕様書が承認された後の修正は、構成管理の対象となり、変更に際しては正確に履歴を取ることが義務づけられます。このとき、ある要求の変更が、どこに影響したかを検討したことを追跡できるように工夫する必要があります。