昨日のブログで、
（１）結局何をするのか
→これは、動詞であらわされる
と書きましたが、要求仕様であらわされる動詞は、すべて業務要件というわけではないです。さらに、ある動詞は、業務要件でも、非業務要件にも分類されないけど、これを見落とすと、あとあと、仕様の行き違いになり、プログラムのバグや、開発の問題になることがあります。
今日は、その話を書いておきます。
動詞には、動作を表す動詞と、状態をあらわす動詞があります。
たとえば、走る、書く、送るなどが、動作を表す動詞です。
それに対し、である、持っている、構成されているなどが、状態を表す動詞です。
業務要件は、「なにをする」かを規定したものです。
このなにをするというのは、まさに、動作を表す状態になります。
で、前回のブログで書いた、アクティビティ図、ユースケース図につながってくるのは、この動詞になります。
では、状態を表す動詞は、なにをあらわしているのかというと、用語の意味、関係をあらわします。たとえば、「～である」というのは、あるものと、あるものの関係をあらわします（is-a関係とか）。
なので、ＵＭＬの図であらわすとすると、クラス図で表せないこともないのですが、要求仕様の段階で、この部分のクラス図を書いたとかりにしても、そのクラス図で、十分表現できるかどうか、そもそも、ユーザーに、そのクラス図をみせて、確認できるかどうか？？という問題が起こります。
そこで、これら状態で表される動詞は、物事の関係をあらわすものとして、用語集の中で、定義していくことになります。
この用語の定義が、意外と重要で、プロジェクトの問題を引き起こしたりします。
たとえば、在庫一覧ということばで表されているものが、リアルタイムのその時点の在庫一覧を表すのか、月次でいいのか、日次なのか、製品在庫なのか、商品在庫なのかで、業務フローも、関係する部署も変わってきてしまいます。
でも、それをどこにも定義しないと、あいまいなまま、ことがすすんで（営業的に、わざとあいまいではなしをすすめることも、ないことはないが）あとで、「え、考えてること、ちがうじゃん、日次レベルではもとまるけど、リアルタイムなんて、オンラインでつながってないんだから、もとまんないよ！」なんてーよーな、おばかなこともあるわけです。
で、用語定義することばの抽出と、その定義というのは、プロジェクトの成否を左右するほど、じつは大切なのですが（というか、要求をつくりだすときは、まさに、その用語の定義と、その用語（もの）を、どう動かすか（業務フロー）につきる）、この部分は、機能要件・非機能要件から漏れてしまうためか、その方法は、かかれてない本が多い気がします。
たとえば、ＵＭＬシステム設計実践技大全では、この辺のつくりは、かいていません（このほんは、そこまで書くものではないのだろうけどね。。。要求仕様書のまとめ方の本ではないのだから）
ＳＥのための仕様の基本は、上記の用語集を導き出す日本語解析は書いてあるんだけど、それが、用語集とむすびついていない。事実、６４ページの要件仕様書のサンプルには、「定義・用語集」は「なし」となっている。
図解入門 よくわかる最新システム開発者のための要求定義の基本と仕組みの場合は、もちょっと（いや、かなり）ましで、Ｐ２１３ページに「用語集」データディクショナリをつけますとあり、そのデータディクショナリの作り方は、Ｐ２０４に、ＤＦＤ、ＥＲＤとのからみで作ると書いてあります。これは、一般的にいわれることなのですが、じゃあ、具体的にどう作り出すかという、日本語解析部分に関しては、くわしくはかいてません。
たしか、これは、ＯＭＴの本にあったような気がする。。。（記憶違いかも？？今手元に確認できる本がない）
で、昨日と同じで、こんなことを何で書いたかは、また後日。
アクセス
トータル
ランキング
