この節では，形式仕様の技術を概観している．
KAOSの場合，次のようなステップをとる．［図式＋自然言語］→［図式＋形式記述］．SyntropyやCatalysisの系譜と同じである．ただ，この両者が基本的に分析・設計段階を対象にしていたのに対して，KAOSが対象とするのは，その前の要求段階である点が異なっている．
KAOSでは，最終的に［図式＋形式記述］となるため，準備として，本節で形式記述に関する情報が与えられる．広く，形式仕様記述を対象としているが，主題ではないため，内容は限定される．
ここも少し長くなる．全体を先に見ておく．
4.4.1 文を形式化するための基盤としての論理
4.4.2 履歴ベースの仕様
4.4.3 状態ベースの仕様
4.4.4 イベントベースの仕様
4.4.5 代数仕様
4.4.6 他の仕様パラダイム
4.4.7 形式仕様：長所と限界
命題論理・述語論理から始まる．4.4.2は，主として時制論理である．4.4.3の状態ベースでは，Z言語のような集合論に基づく形式仕様を取りあげる．4.4.4のイベントベースでは，STATEMATEのような時間記述を持ったふるまい表現の説明がある．
「形式」という言葉を使うのは，通常なんらかの数学に基づいているからである．何度か引用しているJ. Lacan だと，純粋に象徴界に属する．想像界や現実界と接点を持つが異なる世界である．必要以上に意味を読み込んだり，現実を反映していると思いたくなるときがあるが，避けるべきである．
(nil)
半形式化した仕様における「形式的な部分」は，一般に図式言語によって与えられる(p.144)
冒頭にあるように，次の役割分担を考えている．図式とそこに書かれるテキストを考えたときに，図式は形式性を受け持つ．図式中に書かれるテキストは非形式的である．従って，全体としては「半」形式的である．
図式を徹底することはもちろん出来るだろう．ただ，それは図式がテキスト化するだけで，可読性や編集容易性というメリットを失う．
ここでは，あくまで図とテキストに分かれると考える．この2分割によって，次節からはテキスト部分の形式化の話題に進む．
もちろん，Lamsweerdeさんがいうように，図式の形式化すらも矩形などの単純な図形と矢印だけなのだから表層的であるというのも，正しいだろう．
少しだけ違った視点から，「表層的には」使える図式表現といえども，更に難しさがあるということを考えてみたい．人の書く図式を見る機会は余りないのだが（最近は特に少なくなった気がする），先日，大学生にKAOSを説明する機会に恵まれた．採点しながら思ったのは，人間というのは，なんと発想力に優れた生き物かということである（イヤミではなく，素直に良いと思った）．
席が近い人以外は同じ図式にはならないのだが，そこからは，その人がどう考えたか，何を気にしたかが伝わってくる．これが一番の図式の魅力だろうと思う．同じコトを自然言語で実現しようとすると，よほど練った文章にする必要がある．
逆に言えば，図式の細部にこだわりながら正確に書かれたとしても，読者にがんばったね！以外に何も伝わらない図式は，意味をなしていないということである．図式は，数学に相当する正確さを持ち得ないと思っている（どんな図式でもノードとして使えるのはたかだか10個程度しかないのだから）．しかし，表層的とも思わない．多くの人（利害関係者の多くは，ソフトウェアが専門ではないだろう）が，重要な点を一瞥できるには，どうすべきかということに対して，魅力的な道具だと思う．
いつまでもKAOSのモデル図にたどり着けないが（原書ではあと100頁ほど先である），採点していて思った（ゴールモデルを）作成するときの注意点を残しておく．もちろん，学生のみなさんにはあらかじめ注意はしていないし，そもそも私の頭の中にはなかった．慣れてしまうと気がつかない点を教えてもらったと，みなさんには感謝している．
- （業務フロー的）フローは，意識しないこと
- 最も重要なゴールは何かを意識すること
- システムをイメージしないこと
- 関連と洗練を混同しないこと
(nil)
ここまでで様々な図式を見てきた．手法を考えるとき，単一の図式だけを用いることは少なく，通常は複数の図式を組み合わせることになる（KAOSもそうである）．システムを記述するには，異なるビューが必要で，各ビューには適切な書き方（図式）がある，ということになる．
この項は，具体的な例がないので，幾つか知っている範囲で示してみる．
STATEMATE
3つのチャートを使用する．アクティビティチャート・ステートチャート・モジュールチャートである．アクティビティチャートは機能視点を示す．各機能のふるまいは，ステートチャートによって記述する．最終的なモジュール構成は，モジュールチャートによって示す．
OMT（Object Modeling Technique）
一時期は代表的なオブジェクト指向の手法であったが，今ではOMTという略語はオステオパシー治療の略としての方が有名かもしれない．教科書の表紙にあるように，オブジェクトモデル・状態モデル・機能モデルからなる．オブジェクトモデルは，クラス図であり，状態モデルは，ステートチャートの簡易版を使う．機能モデルは，DFDだが実際にはあまり推奨されなかった．
シュレイアー・メラー法
オブジェクト情報モデル・状態モデル・プロセスモデルからなる．オブジェクトモデルには，クラス図的なものである．状態モデルのベースは一般の状態遷移図である．プロセスモデルは，Mellor氏が，ワード氏と共にリアルタイム構造化分析手法を開発したこともあり，制御フローを含んだアクションDFDという図式を用いる．とにかく，あちこちにIDを振るところが特徴的である．
3つの手法概要を見て頂くと分かるとおり，おおむね機能／ふるまい／構造の3つの表現を持つ．STATEMATEのような反応型システムの場合は，ふるまいを重視するし，OMTやシュレイアー・メラー法のようなオブジェクト指向系は，構造を中心にしている．
手法の全盛時代は過ぎ，いま主流なのは，手法と直接にリンクしないUMLの様な図式リストである．機械設計における図面は，3次元に形を変えたが残っている．図面メタファの図式というのは，ソフトウェアの場合に成立しづらいということだろうと思う．
もちろん，それでもメタメソッド的な考え方をしている人もいる．問題に合わせて，手法の断片を組合せる．その断片に適切な図式（それはUMLにある適切な何かの図）を組み合わせるという方法である ．
（nil）