要求仕様書の中で使用される「用語」にも配慮が求められます。特に、ある概念を表す用語は、その使い方や表現を統一しなければなりませんし、略語を使う際には、突然現れることの無いようにしなければなりません。どうしても、その場で説明を入れることが、仕様書として馴染まないとすれば、末尾か別冊に用語集をつけ、本文中では用語集を参章することを指摘しておくことが必要になります。
設計者間でさえも、一つの用語に対して、解釈や理解が異なっていることもしばしばです。
要求仕様書は全ての始まりであることを認識すべきです。ここでボタンを掛け違えたら、とくに解釈が違ったまま作業を進めるようなことになれば、おそらくテストでも発見されないでしょう。
この用語集は別冊にして要求書の段階から用意し、その後、要求仕様書にも引き継ぐことをお勧めします。そうしていけば、すぐにその開発組織で必要な知識の小冊子ができ上がります。
（インデックスに戻るときはウィンドウをクローズしてください）
一般に、機能的要求は記述しやすいのですが、品質的要求は、仕様の記述に工夫が求められることがあります。単に「性能の向上」のままでは、そこから設計者が「行動」を引きだすことが出来ません。「パフォーマンス」や「操作性」なども、表現に注意しなければ、適切な「行動」が引き出せません。もちろん、それが実現していることを確かめるテストも出来ません。
「仕様」である以上、パフォーマンスなら具体的な応答時間で示したり、比較するモデルに比べて何％というように、具体的に記述すべきです。
操作性の場合も、何をもって操作性がよいとするか、それを表現することが必要です。
プログラム・サイズも、具体的に「○○ＭＢ以内に収める」と規定しないかぎり、達成できるものではありません。
残念ながら、多くの開発現場では、この品質的要求をほとんど規定していないため、機能は満たされていても、製品として使用に堪えないものを作ってしまうのです。しかも、作った後で行われる性能を引きだす為の修正作業は、機能の修正と違って、一般に大掛かりな手直し作業となり、モジュールの構造などを壊してしまうことになります。
（インデックスに戻るときはウィンドウをクローズしてください）
「要求」がまとまらないということは無いでしょうが、「仕様」がなかなかまとまらないということはしばしばあります。そのため、多くの開発現場では、仕様の確定作業が遅れ、設計者は、仕様なしで作業をすすめていることも少なくありません。ソフトの完成（？）と要求仕様書の完成が同時ということも珍しくありません。結局、設計者達は、要求仕様書を見ていないのです。
このようなことが起きるのは、「仕様」が“完成”していなければならないという思い込みがあるからでしょう。そのため、未完成の「仕様」は出せないということになります。それでも提示を求めたら、至る所に「TBD(to be defined)」の文字“だけ”の仕様書が出てきます。機能カテゴリ（に相当するもの）があって、その下が真っ白けで真ん中に「TBD」と書かれているだけです。
「仕様」をまとめる作業も、当然プロジェクト全体の中で行われる以上、適当な期間が与えられるはずで、その期間の中で「８０％」の出来を目指すことです。一旦決まった仕様であっても、途中で変更されることは避けられないし、必ずしもそれを拒否できません。そのために、《要求管理》の仕組みがあるわけです。残りの「２０％」は、《要求管理》の中でフォローします。
実際問題として、その要求に対する仕様の全てが決まらないということはなく、表示が縦方向か横方向か決まらなかったり、パフォーマンスの目標値が決まらなかったり、イリーガル時の対応が決まらなかったり、プロトコルの標準化で一部の決定が遅れたり、というのがほとんどです。
したがって、「要求仕様」の中では、この項目が「未決」であることを明示し、同時に、決まっていないことをそのまま表現したり、「候補」をそのまま見せてしまいます。こうすることで、設計者は、大体の方向は見えますので、作業を進めていくことができます。しかも、あとで変更されることも分かっているわけですから、「要求番号」を使って検索しやすいようにしておくことです。
余談ですが、「８０％」と数えることが出来るのは、未決項目をそのまま“未決”として表現することで可能となります。
（インデックスに戻るときはウィンドウをクローズしてください）
要求書の機能カテゴリの分け方が荒すぎると、一つのカテゴリの中にいろいろな仕様が混じってしまいます。“いろいろな仕様”というのは、いろいろな「要求」を実現するための要件でもあります。それでも、きちんと分けられていればまだ耐えられるのですが、途中で、項目が追加されたりすることを考えると、せっかく分けたつもりでも、すぐに崩されそうです。
たとえば、＜画面操作＞というカテゴリの中では、項目の選択だけでなく、追加や削除といったことに関する記述も混じってくる可能性があります。そうなると、一体何を考えていたのか分からなくなります。それだけでなく、レビューアーも、何をチェックしているのか分からなくなります。
それほど粗っぽいカテゴリ分けでなくても、仕様を書いている時に、時々、それまでの項目と性質が異なることに気付くことがあります。そのようなときは、
“これって、「要求」はなんだろう？”
“どういう「要求」から導き出されるものだろう？”
と自問してください。そうして、必要であれば、「要求書」に新しい「要求」を追加してください。時には、機能カテゴリを分割し、あたらなカテゴリを設定するほうがすっきりとまとまることもあります。そうして新たに設定された「要求」から、改めて適切な「仕様」を導き出します。
（インデックスに戻るときはウィンドウをクローズしてください）
「仕様」の捉え方に、要求を実現するための仕様の記述とは別に、「前提事項」とか「制限事項」といったキーワードを併用する方法があります。設計時には、これらの項目は、「チェック項目」として扱われることになり、それが明確にされて分かりやすい方法です。
ただ、仕様の書き手によっては、「前提」や「制限」として認識することに不安があったり、自身がないような場合には、それらもまとめて「仕様」として書いてください。設計者が、設計時にそれらの「仕様」の中から、事前のチェック項目を拾い出してくれるはずです。