「要求仕様書って、どうすればうまく書けるのでしょう⁠」⁠。そんな声がソフトウェア開発の現場から聞こえてきます。というのも相次ぐ「仕様の変更」に悩まされるプロジェクトは数知れず。とにかく目に見える成果物を、ということでさっさとプログラムを作って、あとから調整をすればいいやと作業を進めていった結果、仕様漏れや仕様の衝突で行き詰まってしまう……。バグの発生の原因の多くは、仕様漏れや仕様衝突など、要求仕様に絡むプロセスに問題があることに気付いてきたにもかかわらず、状況はなかなか改善されません。それは「要求仕様というものをどのように表現すればよいのかがわからない」「⁠要求仕様をまとめる際につきまとう問題を認識していない」「⁠要求仕様書というものの存在意義を理解していない」のが原因であるといいます。

バグの大きな原因のひとつ「仕様漏れ」が起きる最大の原因として仕様書に「要求」が表現されないことがあげられます。

「要求仕様書」は「要求」とそれに関連した「仕様」が書かれた文書です。最終的にソースコードに変換されるのに必要なのは具体的に表現された「仕様」のほうですが、「⁠要求」が的確に把握され、適切に表現されないと相応しい仕様を導き出すことができません。

では「要求」とはなんなのでしょう？ そしてそれはどのように表現されればいいのでしょう？

一例をあげてみます。「⁠印刷できない状況が発生したときには担当者に知らせてほしい」という要求があります。この表現では「印刷できない状況」の範囲が広すぎてわかりにくいです。これを「印刷途中で用紙やトナーの不足がわかった時点で担当者にメールで知らせてほしい」とすることで「不足をチェックし、それを認識したら電文を組み立ててメールで知らせる」までの範囲が明らかになります。さらに「どうしてその要求が必要なのか？」という「理由」を探ることで要求の背景がわかり表現がより的確になります。その結果「印刷中に文字がかすれたくないから」という「理由」で「インクの残量を調べて、印刷できない可能性があれば印刷依頼者のパソコンに知らせてほしい」という本当の要求がつかめるのです。このように「理由」と「要求」をセットで考えてそれぞれを表現することで適切な仕様を導出できるようになります（実現性とのバランスから適切な方向に要求と理由の変更を図ることもありますが、いずれにせよセットで考えることで、依頼者の思いを的確に把握していきます⁠）⁠。

以上、端折り気味ですが「仕様化」の前に重要な（しかし、その重要性が認識されていない）「⁠要求」と「理由」の表現について述べてみました。

その他、仕様書はワープロではなくて表計算ソフトを使ってまとめることなど、ソフトウェア開発を成功に導く「要求仕様書」作成のノウハウはぜひ本書を御覧いただければと思います。数々の現場で指導にあたってきた著者による、仕様書作りの考え方や具体的プロセスと表現方法、改善法といった実践的なスキルが満載です。