要求仕様書の作成段階は、９０年の初め頃から「Requirement Engineering」として世界的な取り組みが始まっています。「エンジニアリング」というのは、“そこで示された手順に従って進めていけば、誰がやっても、ある程度の結果を得られるような仕組み”をいいます。現在、ソフトウェアの中に存在する「エンジニアリング」としては３つあります。
Software Engineering：ソフトウェア開発全般を捉えたもの
Requirement Engineering：要求仕様作成段階を捉えたもの
Re-Engineering：保守の段階を捉えたもの
です。
最近は、要求仕様書の自動化ツールの研究も大分進んできているようですから、要求仕様書を巡る作業の姿は、これから変わっていくことになるかも知れません。ツール化による検索機能も強化されるでしょう。それでも、要求仕様書が何故必要なのか、どこに利用されるのか、どのような配慮が必要なのかという点は、大きく変わるとは思えません。変わるとすれば、前後の作業との繋がりを考えた時に表現が変わるぐらいです。
要求仕様の表現は、開発手法と全く無関係というわけではありませんが、逆に、全く変わってしまうということもありません。要求の発信者も、それを理解するのも人間です。たとえばオブジェクト指向であっても、要求自身は“機能”で表現されますし、顧客からの変更も“機能”で発せられます。決して、顧客から“クラス”の変更が求められるわけではありません。「Use Case」の存在が、そのことを如実に物語っています。
いずれにしろ、要求仕様書は、ここ（このページ）に書かれていることを理解したつもりでも、それだけでは実際にはなかなか書けないものです。また、開発する製品の特性によっても要求や仕様の表現が異なる可能性があります。それぞれの組織にあって、いくらかの時間をかけて実際に取り組みながら洗練していただく必要があります。
このホームページが皆さんのお役に立てるかどうか分かりませんが、私自身、現役でいる間は研究を続けつつもりです。皆さんもどうか怠り無く研究してください。
このページをご覧の読者は、おそらくソフトウェアの開発に携わっている方がほとんどだと思いますが、この「要求」と「要求仕様」の構図は、ソフトウェアの仕様策定の場面だけでなく、仕事上でいろいろな場面で出てきます。
たとえば、「戦略会議」の場で、
「市場の実態をすぐに調査して欲しい」
という指示が、あなたに出されたとします。これも、立派な「要求」です。この要求を満たすことが出来るかどうかは、「市場」「実態」「すぐに」「調査」というキーワードに対して“特定”しながら、この「要求」を満たすための「仕様」を展開しなければなりません。
「市場」とは、どこを指すのか？
「実態」とは、何を含んでいるのか？
「すぐに」とは、いつまでなのか？
「調査」とは、どのような形で報告することを指しているのか？
時には、確認のために質問をすることも必要でしょう。鵜呑みにしたり早合点して要求を外すよりは、早い段階での質問の方が歓迎されます。また、上記のキーワードを特定する際に、要求の出された「理由」が分かっていれば判断しやすくなります。こうして、「要求」を的確に「仕様」に分解することによって、効率的な行動が起こせるはずです。
また、テレビの刑事物のドラマなどで、
「ガイ者の身辺を当たってみて欲しい」
という指示（要求）が、課長から出される場面がありますが、これも「身辺」や「当たる」というキーワードに対して、適切に特定できなければ身動きが取れません。初動捜査のミスは致命的です。
経験の浅い人などによく見られる光景として、“何をすればいいのかよく分からない”というのがあります。これは、そこで求められている「要求」を具体的な行動に変換できない状況ですが、よく観察すると、「要求」に含まれる「非特定用語」を抽出できていないことがほとんどです。
このように、「要求」―「要求仕様」の構図は、とても応用範囲が広いのです。一旦、正しく（適切に）手に入れたら、少々大げさに言えば、あなたの人生が変わる可能性だってあるのです。