要求仕様書にクラス図を入れるか？入るとしたら、どこにどうやって？

ゴール指向分析の「考え方は」WBSに使える
http://blog.goo.ne.jp/xmldtp/e/2efd32b1f9b8911882f6b8ddf988febe

を聞かれたときに、一緒に話題になった話なんだけど、
「要求仕様書にクラス図を入れるか？入るとしたら、どこにどうやって？？」
という件について、個人的見解。

---

まず、入れるべきかどうかの議論の前に、
入るとしたら・・・

●どこか？→入れるところは、

要求仕様書の「用語説明」の章の前ないし後
　用語説明で説明している用語がクラス図になっていること。
（ないしは、何かを定義するところ）


●どうやって？→書き方

用語説明のところで、「クラス名」にかかれている用語を、
クラス図の関連、属性、メソッドで説明することになる。
たとえば、

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（６）
http://blog.goo.ne.jp/xmldtp/e/209a97872693596c7fa43f77cdb93d86

のクラス図


の「アンケート画面」について説明すると、

用語見出し：「アンケート画面」 説明： 　アンケート画面は、問１，２，３，４，５から成り、 画面表示後、ユーザーに問の回答を入力してもらった 後に、回答実行をクリックすることで表示が終了する 画面である

どう考えても、これは要件定義で話すことではない。
ということには、このクラス図は、要件定義レベルの
図ではないということが分かるのだが、まあ、説明
の仕方としては、こんなかんじ。

　ここで示したように、
「クラス名」は、「属性」、「関連クラス」から成り
「メソッド」を行う
という形に、基本的にはなる。ただし、これだと
日本語がおかしいので、日本語を併せる必要がある。

---

ただ、上記の「説明」の例で”ユーザーに問の回答を
入力してもらった後”って書いてあるのに、クラス図
にないように、クラス図は、用語説明のすべての情報を
書き表すわけではない。制約や順番、条件や他メソッド
との関連はクラス図にはない。そこで、説明で補う。

ということは、クラス図より多い情報が説明に書かれる
ことになる。二重にものが書かれている場合、更新漏れ
の危険がある。なので、私は、「書かなくてもいいと思う」
（書くことを積極的に、否定はしないけど・・・）