UMLで要求仕様を書くと、データ的に矛盾がある業務手順でも、かけてしまったりして！

　ＵＭＬで要求仕様を書くとすると、作成するのは、普通
　・ユースケース図
　・アクティビティ図
であり、この段階では、普通、クラス図を作成しない（と思う）。
　ユースケース図、アクティビティ図とも、作成時、プロセス（ユースケースないしアクション状態）だけに着目して書こうと思えば、かけてしまう。
　もちろん、アクティビティ図において、オブジェクトを記載「することもできる」が、書かない気になれば、書かなくても、かまわない。

　そうすると、ユースケースやアクティビティ、ユースケースシナリオを作成しても、その中に出てくるプロセスで操作するモノのデータ構造がわからない。

　特に、違うデータに同じ名前を付けてしまった場合、データの入出力について着目すれば気づくはずのケースでも、気づかないで済んでしまうケースがある。

　たとえば、以下のケースを考える
　　・在庫管理リストをみて、毎日発注するというプロセスと、
　　・在庫管理リストを作成するというプロセスがあった場合、
　後者で作成し、前者でそれを参照しているので、一見問題はない。
　しかし、前者の在庫管理リストは、それをもとに、毎日発注するのだから、在庫管理リストは、日時あるいはそれ以下の単位である。一方後者は、（日時でもＯＫだけど）、月次で作ってるかもしれない。月１回しか作らない資料をみて、毎日発注？？
　おかしいですよね。

これらを防ぐ方法として、ＥＲ図をいれるという方法もあるが、そもそもＥＲ図は、ＤＯＡの枠組みで作成されるもので、ＵＭＬの図にはない。したがって、ＥＲ図と、そのほかのダイアログとの関係は、びみょーになる。

UMLを使って、本当に要求仕様を記述しきれるのだろうか？

　素朴な疑問。
　ＵＭＬで、いろんな図がありますが、あれらの図を使って、はたして、要求仕様を不足なく、記述できるんでしょうか（多すぎる分には、問題ないとします）？
　もし、仮にですよ、ＵＭＬを使って、要求仕様を記述できないとしたら、ＵＭＬのドキュメントをベースにして、要求仕様をまとめている開発（って、いまや結構多いと思うんですけど）って、やばくないですか？
　ＵＭＬの図を使ったばっかりに、知らぬ間に要件が抜けているっつーことなわけで。。。

　いまやＵＭＬの図を使って要件を書く流れっていうのは、ある程度定着しつつあるから、もし、要求仕様がＵＭＬの図で記述できないのであれば（不足があるのであれば）、それを補うドキュメントなり、なんなりをつくらないといけないですよね。

　だけど、その話のスタートラインである、「ＵＭＬの図を使って、要求仕様を不足なく、記述できるのかどうか」って、考えていないような気がするんです。

　それって、やばくないっすか？？
　本当はＵＭＬを使っても、要求仕様、記述できないかもしれませんよ。

　もちろん、ここで、いってるのは、非機能要件の話ではありません。
　非機能要件は、書けないのは、わかります。それをだれも、期待しないでしょう。
　ここで言っているのは、業務そのもの、機能要件が、記述できるのかどうかです。

---

　うーん、なんか世の中、そんなことを考えず、ＵＭＬで要求仕様をかくとおしゃれ、もしくは、お金になるから、ＵＭＬを使っている気がするぞ。。

　で、こんなブログを書くということは、ＵＭＬで、要求仕様を記述できないと思っているからだろう。。。と、察しのいい人は、思うと思います。

　そう、そうなんですが、詳しくは、またこんど。