要求仕様書は顧客からの「要求」を受けて、その要求を満たすべく具体的かつ詳細な「仕様」としてまとめられたものです。具体的であることから、要求の実現性や検証可能性が伴うことになります。また、詳細に仕様化されていることで、仕様間、あるいは要求間での相互の矛盾も発見しやすくなっている筈です。
（ユーザー） （設計者）
「要求書」 → （実現性の検討）
← 「要求仕様書」を返す
（確認・契約） → （設計作業に着手）
（インデックスに戻るときはウィンドウをクローズしてください）
「要求」「要求書」「要求仕様」「要求仕様書」という言葉は、開発現場において必ずしも正確に使われていません。また「機能仕様書」や「製品仕様書」と混同している場面も見られますので、組織において正確に定義することをお勧めします。『言葉は、正しく使われないと、本来の効力を発揮しない』、あるいは『定義されないものは実行されない』ということに注意してください。
「要求」と言うのは、依頼者から発せられるもので、一般に「○○のことを実現して欲しい」とか「○○のことが出来るように」という形で出てきます。
たとえば
「ＴＣＰ／ＩＰ」のプロトコルを入れて欲しい」とか
「USB で繋ぎたい」とか
「もっと動画をスムースに実現して欲しい」
というものです。
分野は違いますが、
「心臓が弱いので、部屋の内と外の温度差をなくして欲しい」とか、
「ひざを痛めているので、家の中で躓かないようにして欲しい」
というのも要求です。
もちろん、中にはもう少し“具体的”なレベルで要求が出される事もあります。
たとえば
「製品のコストを○○円に」とか
「消費電力を○○ｗに減らして欲しい」とか
「○○の画面上に経過時間を表示して欲しい」
というように。
これらは全て「要求」であって「仕様」のレベルではないことに注意して欲しいのです。「○○円」とか「○○ｗ」というのは目標値であって、「仕様」の意味を持っているわけではありません。
「要求」は言うまでもなく「What」です。「要求仕様」も「What」ですが、「要求」と比べて、具体的であり、かつ詳細に「要求の What」に含まれる「What」、あるいは「要求の What」を構成する詳細な「What」です。
「仕様」というのは、「Specification」に対応した日本語です。それ自体が「詳細な」という意味を持っています。唯の「文書」ではありません。
したがって、「消費電力を○○ｗに減らして欲しい」という要求（What）には、いったいどのような「具体的かつ詳細な
What」が含まれているかということ探しだす必要があります。その結果、
「○○の部品を使うのを止めて□□に切り替える」とか
「アイドル状態が○○秒続いた時にパワーセーブ機構を働かせる」
というようなことが考えられます。
一方、ここまで具体的になってくると、ある詳細な仕様を決めたことで、派生的に周囲に影響を与えることが見えてきます。「□□の部品を使う」ことで他に影響が出ないのかということが考えられることになります。「画面に経過時間を表示」するには、経過時間を獲得する仕組みを組み入れなければなりません。どうやって、実現するかは設計の問題ですが、「少なくとも１秒間隔で時間の経過をカウントする機構を組み入れる」ということ（What）を実現しないと、おおもとの要求は満たせないことは表明しておく必要があります。
また、顧客は特定の画面を見て要求を発しているのですが、システム上、他の画面と共用している部分が多く、この要求を満たすために、他に細かな実現すべき「What」があることに気づかなければなりません。それらをまとめたものが「要求仕様」または「要求仕様書」なのです。
つまり、多くの開発現場にあって、設計途中でいろいろと「ここはどうするのか」といった「問題」が持ち上がりますが、それらの殆どは「要求仕様」の範疇です。それが最初にまとめられていないために、設計段階、あるいは実装段階に入ってからの「仕様の変更」となって吹き出すのです。
この「要求仕様書」は、顧客との間で契約を結ぶ際に重要な文書でもあります。ここには、要求に対してそれを実現するための具体的な仕様のレベルで表現されているため、設計者が顧客の要求をどのように捉えているのかが一目で分かります。
また、要求されている機能に対して出来ることや出来ないことだけでなく、パフォーマンスなどの品質や、納期をどのように達成するかということも“約束事”として記述されています。本来の姿から言えば、この要求仕様書は、設計者（開発者）が行う行為の全てが見えるものです。
もちろん、場合によっては相当な量になるでしょう。何処まで（詳細に）表現すればいいのか、必ずしも定まっている分けではありません。その時の案件と、顧客の要求状態、開発側の体制やスキルなどを考慮して決める事になります。
後になって、沸き上がった仕様の変更や追加が、契約上の追加仕様に当たるのかどうかが問題になることが多いのですが、それは、最初にこのような「要求仕様書」を交換しなかったからです。
何れにしても、この文書に基づいて契約を交わすのが、正しい契約です。
（インデックスに戻るときはウィンドウをクローズしてください）
要求仕様書が契約の前提となるということになれば、いい加減な内容で誤魔化すわけには行かなくなります。当然、「要求」に曖昧な点があれば、顧客と何度でも話しあわなければなりません。でも「要求」のレベルのものをいくら眺めていても、そうそう問題が見えてくるわけではありません。「仕様」のレベルに展開してはじめて、その要求に潜む障害や問題、あるいは矛盾などが見えてくるのです。
この行為は、最初の段階に集中して行なわれる必要があるのですが、残念ながら多くの開発組織では、要求仕様書を作成する行為に重きを置いていません。そのため、設計段階になって曖昧さが表に出るのですが、開発側の担当者としては、今ごろになってそのような問合せを顧客に持ち込むことに躊躇して、結局曖昧なまま作業を続け、バグとなってから改めて顧客に確認して修正するということになるのです。
そのような事がないように、「要求仕様」の策定段階で、（勇気を出して）何度も折り返して内容をチェックすることです。 もちろん、この作業にはそれなりの時間を投入する必要がありますが、ここで省けば、以降の工程で、その何倍もの時間がとられることになります。その時には、すでに担当者に配分されていることを考えると、時間のロスだけの問題ではなくなります。