要求仕様書は、顧客の要求を分析し、そこに含まれる詳細な要求を捉え、実現性を裏付けて整理したものですが、その結果、要求仕様書の役割として、以下の４つが考えられます。
・顧客の要求を確認する
・仕様の実現性を確認する
・設計作業に引き継ぐ
・テスト仕様書の元になる
（インデックスに戻るときはウィンドウをクローズしてください）
まず最初の役割として、顧客の要求を聞き出し（要求書）、それを分析して「要求仕様書」にまとめ顧客に提示します。この作業は、本来は顧客から出された「要求書」に基づいて行なわれるのですが、現実問題として、必ずしも書面で出されるとは限りません。
顧客は、この「要求仕様書」の内容をチェックし、要求と食い違う個所があれば、訂正を求めます。
したがって、要求仕様書には、
・要求に含まれる具体的かつ詳細な要求（仕様）が展開されている
・要求される詳細な機能が、機能ごとに具体的に記述されている
・機能以外に、各種の品質特性についても、その達成について言及されている
・機能の実現の前提条件が明らかにされている
・納期やコストなどの実現の手順についても言及されている
ことが必要になります。
これによって、顧客の要求を正確に確認することが出来ます。もちろん、顧客の要求はこれで完全に把握できるとは限りません。完成までの間に、競争相手の出現や、環境の変化によって要求自体が追加されたり変化することがあります。
（インデックスに戻るときはウィンドウをクローズしてください）
顧客が、「要求仕様書」を見てシステムの機能や性能を確認し、“了承”というステップを踏むためには、単に個々の機能や性能がが明示されているだけではなく、それぞれの機能、性能が実現できるものとして表現されていなければなりません。また、仕様が、相互に相反していないことも必要です。
一般に書かれているような機能仕様書などでは、顧客の“・・・して欲しい”という要望（＝要求に近いもの）をそのまま記述しているために、具体的表現に欠け、実現性の追及が為されていないものも見られます。このような単に要求（要望？）を個条書きする程度のものでは、「要求仕様書」の役目を果たしません。
そのため、設計作業を進めていく中で、改めて「要求」が具体的に展開されることになり、最初に掲げた仕様が実現しないことや、仕様間の相互矛盾などが判明し、慌てて顧客と交渉することになったりしますが、このような行動は、確実に顧客の信頼を失うこととなります。
このような事態を避けるためにも、最初の「要求仕様書」の段階で、その実現性を追及しておくべきです。仕様間の相互矛盾などは、具体的表現の上で実現性を追及するなかで判明するものです。
（インデックスに戻るときはウィンドウをクローズしてください）
当然のことに、「要求仕様書」には、顧客の「要求」を満たすために“何をすべきか（という仕様）”が明らかにされており、これに基づいて設計作業が行なわれることになります。多くの開発現場でも、この“認識”は持っているようですが、実際に、「要求仕様書」が設計作業にうまく“引き継がれ”ているかというと、残念ながら、“参考”にされていることは確かでしょうが、必ずしも明確に“引継がれている”とは言えません。それは、設計書の“この部分”は、要求仕様書のどの部分の“要求項目”を受けているのかという繋がりが明示されていないからです。
うまく引き継がれていないもう一つの理由は、ここでまとめられている要求仕様書は、システム全体に対する仕様です。一方、「設計書」には、一般に、システム全体の設計書と、個々のタスクの設計書があり、実装に引き継がれるのはどちらかというと後者のタスク毎の設計書ですが、ここで個々のタスクに求められる「仕様」（大部分が機能的仕様）と、先のシステム全体の「要求仕様」とは、直接的にはつながらない可能性があります。要求仕様を幾つかのタスクで手分けして実現するわけですから、タスクに与えられる仕様も、そのタスクの持ち分に合うように内容が変わることになります。
そのため、設計途中で、要求や仕様が変更されたときなど、既に書かれている設計書に影響を与える個所を見つけることが難しくなり、設計書において、関連する個所を見付けることが出来ずに修正モレとなる可能性もあります。もちろん、ソースの方に注意が偏って、設計書や要求仕様書を修正されない可能性もあります。
（インデックスに戻るときはウィンドウをクローズしてください）
「要求仕様書」の４つ目の役目は、これに基づいて機能レベルや品質レベルの「テスト仕様書」が作られることです。「要求仕様書」で要求されている項目は、それが正しく実現されているかどうか、テストで確認できるように書かれています。いいかえれば、「要求仕様書」は、それ自体、システムとしてどのようなテストをすればいいかを示しているのです。
残念ながら、多くの開発現場では「テスト仕様書」がうまく書かれていません。テスト項目のリスト（チェック・リスト）ですらまともに書かれていません。たとえ書かれていても、多くの場合、その内容は、顧客の要求のレベルに近い視点で、“出来ることの確認”事項を並べたようなものが多く、テストのガイドとして使用するには全く不十分なものです。
そうなるのも、「要求仕様書」が作られていないからなのです。