要求仕様書は、ユーザー、顧客、営業マン、要求仕様書の作成者、設計者、検査担当者、管理者、といった広い範囲の人たちにとって、読みやすく理解しやすいものでなければならない。文書は、こうした人たちのすべてが、要求に基づいて開発されつつあるシステムを完全に理解できるように書かれていなければならない。そのように書かれていれば、稼働してからびっくりするようなことは起こらない。
（開発関係者の各々に渡すためのサブセットとしての）複数の要求仕様書を作成する場合、これがうまくいくのは版をまたがって一貫性が保証されているときだけである。もっと効果的なやり方は、自然言語での記述（原理５４）を使い続けることと併せて、より形式的な性質を必要とする部分に複数の記述方法を用いる（原理４８および５３）ことである。
（２０１の鉄則：原理５６＜要求分析の原理＝要求仕様書を常に読みやすくしておけ＞
要求仕様をどのようにまとめるかは、ソフトウェアの世界に限らず、重要なそして難しい問題です。誰もがこの重要性を認識しているのに、相変わらずプログラムを書くことにリソースが割かれていることは驚きです。実際に、開発の遅延が常態化しているような組織では、ほとんど例外なく、この要求仕様書に問題があります。多くは、「要求」の一部だけがメモのような形で書かれただけのケースで、そこからは「仕様」を窺い知ることはできません。
要求仕様書そのものが全く書かれていないケースもあります。最後まで書かれないケースもありますが、中には、すでに実装やテストまで進んでいる状態で書かれてくることもあります。これなどは、書く力はあるわけですから、まったくもったいない話です。せっかく書いても、時期を逸してしまったために、その労力が報われないのですから。初期に、もう一人投入してでも、適当な時期にリリースされる体制をとれば、そこで発生している多くの問題は解決するはずです。
このように、要求仕様書を書くということは、少なくともソフトウェアの開発において、もっとも重要なテーマであると云っても過言ではありません。回路やメカと違って、設計者の自由度が非常に高い世界だけに、適切な要求仕様が書かれなければ、稼働してからびっくりすることになってしまいます。ＣＭＭに取り組み場合も、要求仕様の構成や書き方をどうするかは、その後の成功を左右することになります。
確かに、レベル２のアセスメントでは、要求仕様書が適切な時期に書かれていることや、その後の変更に追随することなどはチェックされますが、その内容や構成までは求められていません。しかしながら、現実問題として、それを書くことによって、関連するバグが減少し、時間というリソースが獲得出来なければ、その後のＣＭＭの取り組みは頓挫してしまいます。それだけに、開発組織の中で、要求仕様としての要件を満たすべく内容・構成を追及することが必要なのです。
そこで問題になるのは、“読み易い”という意味です。関係する多くの人にとって読み易い要求仕様であるということは、構成の面では、適切な分類の下で書かれていることです。今、目にしている個所は、システム全体のどこに位置するのかが分かることが重要です。そのために、「カテゴリ図」をつけても良いでしょう。カテゴリ図は、その製品においては、かなり永続的に使えます。
一方、内容の面では、具体的に書かれていることです。特に「仕様」は、具体的でなければその役目を果たしません。具体的であることによって、それぞれの立場で、対象となるシステムを理解できるのです。現実に書かれているものの多くは、この具体性に欠けるために、書いた人や直接関係する人にしか理解できないということが生じています。
では実際に、要求仕様書が読み易く書けたかどうかを、どうやって判断すればいいのでしょうか。書いた人は、読み易いものを書いたと思っても、読む人がどう評価するかです。もっとも、読んだ人も、読み易かったかどうかは、簡単に評価できません。ではどうするかといえば、どれだけ多くの“具体的なコメント”が出されたかで判断します。読み手が「具体的なコメント」を発することが出来るのは、そこに「書かれていることが具体的」であったからです。抽象的な表現で書かれていた場合は、“なんのことか分からない”といったコメントが出ますが、“このような場合の規定が抜けている”といったコメントは出てきません。もちろん、完ぺきな要求仕様に対してはコメントは出ないでしょうが、出来栄えかどちらなのか判断に迷うことはないでしょう。
要求仕様書を構成する重要な要素は、「要求」と、それが必要とする「理由」、要求を説明する「背景」や「関連知識」、そして要求を満たすべく「要求仕様」です。「背景」や「関連知識」は、要求の内容によって使い分ければいいと思いますが、「理由」は不可欠の要素です。そして、読みやすさにとって大事なことは、「要求」と、それを構成する「仕様」がセットで見えることです。個々の要求に対す「仕様」が一覧形式で見えることによって、それぞれの要求に対する“仕様モレ”の検出を容易にしてくれます。
同じ意味で「要求」そのものの一覧性も重要です。分類された一覧形式は、対象が何であれ、それ自体が“モレ”を発見しやすくしてくれるものです。ドキュメントによっては、「目次」もその役割を代行してくれます。
以前は、この「要求」と「要求仕様」の２種類の一覧性を維持するために、一覧表示された「要求」を、一つづつ「要求仕様」の頭にコピーしていたのですが、最近の「WORD」などは、この問題を一気に解決してくれます。
一覧形式は、その中の一つが変更されるとき、その影響を受けるものを探すのにも威力を発揮します。そして、個々の「要求」の中で「要求仕様」が展開されていることで、要求の変更によって「影響受ける仕様」の発見を容易にしてくれます。