引き続き，書式等を定める要求文書記述の方法である．
決定表
複雑な要求を，決定表の形で示す．同一レベルの要求の組合せが多い場合は有効である．列車全制動の例も，決定表を用いることで，明確にすることができる．
テンプレート
ここでのテンプレートは，各要求に記載する内容を，あらかじめ定める方式である．イメージとしては，表計算ソフトウェアにおいて，行がひとつの要求を示す．列には，次の内容を示すカラムがある．
- 識別子：要求が階層的である場合，識別子も階層化する
- カテゴリ：要求が，機能要求なのか，品質要求なのか，前提なのか等を記載する
- 要求仕様：実際の要求である
- 適合基準：各役割（要求分析者・設計者・テスタ等）の人にとって，どうなれば要求仕様を満たしているのかを示す
- 要求源：どこ（利害関係者もしくは文書）から，その要求を導き出されたかを示す
- 理由：その要求が必要な理由．要求の理解と追跡可能性のため
- 要求関連：補足のような正の関連か，衝突のような負の関係か
- 優先度レベル：他の要求の比較と，優先度による判断のため
- 安定性と共通レベル：変更管理のため（6章に詳細あり）
このうち，適合基準は，要求仕様を明確化し，ある種の合理性を担保するために重要である．一般には網羅を意図する余り書かれないことが多いのではと思う．
以下は，図書館システムにおける例である．
文献検索機能は，問い合わせに対して素早く応答を返すこと．
90%の問い合わせに対して，2秒未満．他の問い合わせに対しても，5秒を超えないこと．
最初の文が要求仕様であり，後者が適合基準の例である．
ISO 15504 に基づくプロセス能力（しかし不思議な言葉だ）の評定を行うSPICE（Software Process Improvement and Capability dEtermination）の中でも，乗用車向けの規格Automotive SPICE （A-SPICE）では，検証基準と双方向リンクを強調する．ここでの検証基準は，（検証を行う人にとっての）適合基準に相当する．
(nil)
文書の書き方については，これまでも，さまざまな取り組みがなされてきている．最初の紹介は心得である．細かな規則を定めることによって，良い文書とする努力である．先ずは，その内容を紹介する．
- 誰が読むのかを考えてから，書く
- 書く前に，何を書こうとしているのかを説明する
- 動機を最初に書き，まとめは後にする
- 全ての概念は，使用する前に定義しているかを確認する
- 次のことを問い続ける「これは読者に理解可能か．読者はこの点で迷わないか．詳細度のレベルは適切か．ここに書いていることは，他の場所の記述と関係していないか．十分に記述したか．違った風に解釈されることはないか．他に単純な言い回しはないか」
- 一文に，2つ以上の要求・前提・問題領域の特性を記述していないか
- 文を短くする
- 規範的文には，「であること（shall）」を用いる．望むことには，「であることが望ましい（should）」を用いる．
- 不必要な専門用語や略語を避ける
- 抽象的な文を明確にするために，分かりやすい例をつける
- 先行する文を詳細化する項目は，中黒付きリストとする
- 複雑な項目間の関係を示すために，図と説明をつける
- 視覚的な全体像と，重要な点を説明するために，図を用いる
- 関連する事実は，表によって示す
- 量的情報を関連づけるために式を用いる
- 複雑な（入れ子や曖昧さを持つ）条件を組み合わせることは避ける
正直に云うと，こうした注意事項を書くことができる勇気がうらやましい．おまえはどうなのだ，といわれると困る．
しかし，彼の文章は明快で，とうぜんその資格があると思う．
（nil）
本フェーズの入力は，様々なタイプの多数の合意文である．最上位の目的，システム要求，ソフトウェア要求，環境に対する前提，関連する問題領域の特性と概念定義である．（…）出力は，要求文書（RD）の最初のバージョンである．(p.119)
以前のスパイラルモデルの第4象限にあたるのが，本章である．この章では，形式的・半形式的・自由形式での様々な書き方の紹介がある．ここに深入りすると終わらなくなるので，注意しながら説明していきたい（それでも横道にそれるだろうが）．
「制約のない自然言語による自由形式」方式
利害関係者が多数いる場合，自然言語による方法は，形式としてはもっとも障害が少ない．一方で，曖昧さの問題がつきまとう．
以下が例のひとつである．
次の場合に，列車は全制動しなくてはならない．失効した加速指令を受けたとき，または，X m.p.h より速い速度で駅区画に入ったとき，かつ先行する列車との距離がYメータより近くなったとき．
ここでは，「または」と「かつ」が混在しているので，全制動するのがいつなのかが，分かりにくくなっている．次のパターンが考えられるとしている．
- 失効したコマンドを受け取ったとき，或いは，（駅区画に速い速度で入って）先行する列車と近づきすぎたとき
- 先行する列車と近づきすぎたとき
今，条件らしきものは三つあって，構造は，A or B and C となっている．これを，A or (B and C) と考えるか，(A or B) and C と考えるかである．
ここで，後者は，なぜ C だけに単純化できるか？ ORで繋ぐ2つの条件式は，意味がないというのが，ここでの説明である．但し，Case1とCase2に重なり合う部分がないとする．
if Case1 then <Statement1> or if Case2 then <Statement1>
この真偽は，次のように変形することで求めることができる．
(not Case1 or Statement1) or (not Case2 or Statement2) // 含意に対して良く用いる命題論理式の変形
これは，次の様に変形できる．
not (Case1 and Case2) or Statement1 or Statement2
not false or Statement1 or Statement2
ここから明らかに，恒真式となる（not false は true でそれが，OR結合しているから）．
従って，中黒の2番目「先行する列車と近づきすぎたとき」のみが残ることになる．
論理式については，別途まとめることになるが，ここでは重要なのは，自然言語を論理式に置き換えることによって，曖昧さを取り除けるかもしれないということである．論理式が自然言語よりすばらしいということではない．
(nil)