昨日のブログで書いた、要求仕様書の規約IEEE830だが、実際の仕様書に起こそうとすると、こまることがある。ざっと考えて以下の３点
１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない
２．機能の定義の仕方が、オブジェクト指向などと合わない可能性がある
→オブジェクト指向では、このフォーマットだと書きにくい
ちょっと、かえればいいだけなんだけどね。
３．外部設計の規約IEEE 1016と、あわせてつかうと、へなちょこになる
→つーか、IEEE1016が、へなちょこ！
で、今回は、「１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない」について。
で、この話をする前提として、IEEE830の内容は、このページを参考にしています。
１．この順番で書くと、機能を理解するために、膨大な用語定義を見ないといけない
ビジネスプロセスを創出する場合、まあ、いろいろあるわけなんですけど、（で、はぶさんはプロセスからと主張するのですが（ここ））、まあ、大きく２つのケースに分けちゃえるんじゃないでしょーか？
（あ）プロセスからきまっている。
→じつは、その上に、どんなものを乗せても、扱ってもＯＫ！
（い）扱う商品によって、業務内容が決まる
なんですが、まあ、（い）のケースで考えたほうが無難だったりします。
で、（い）の場合、ビジネス構築の流れは、こんなかんじ。
（１）はじめに、なにを（どんな商品サービス）を、どうやって売るか（カネを回収するか）を決める
ここは、社長など、経営陣が決めることが多い。
（２）次に、人（幹部連中）をあつめる
最近のビジネスは、自分でノウハウを持っているというより、経営陣は、Know Whoであって、できそうな人を知っている。あとは、その人に任せるというかんじも、けっこうある。
（３）幹部が、業務プロセスを決める
って感じになる。。
で、そういう流れのビジネスについて、システム開発するとする。
このとき、いきなり、業務プロセスの機能にいってしまうと、わかりにくい。
たとえば、ドメイン取得サービス業務をかんがえよう。
ドメイン取得業務において、いきなりプロセスにはいると、
こんなことばが、いきなりでてくることになる
JPRSに、申請する
？？わかんない？？。
まず、商品として、jp,comなど、あつかうドメインの説明があって、
jpドメインの場合の登場人物として、JPRS（日本レジストリサービス）があることを理解しないと、そのあとのプロセスすべてが？？？マークになってしまうだろう。
（ＪＰドメインの取得には、JPRSの指定業者になるか、指定業者の代理店になるなどの手がある）
もちろん、JPを扱わない場合、JPRSはしらなくていいし、代理店、たとえば、お名前.comの代理店であれば、お名前の仕組みだけを知っていればいいことになるからJPRSはしらなくていい。
つまり、商品と、仕入れ元、仕入先と現金回収者などなどがわかんないと、プロセスがわかんないときがある。
てなわけで、登場人物と、ものの説明がいるんだけど、このIEEE830のフォーマットだと、その辺の話をぜーんぶ、用語定義にかかないといけなさそう（順番的に）。。。
そうすると、「辞典よめー」みたいなかんじになっちゃいそーで、わけわからなそーなのよね。
なんで、ビジネスのカラクリ（登場人物の説明と、その登場人物間にながれる、モノとカネの交換の静的な側面）を、機能を説明する前、用語定義の前にかるく説明したいのよね。
そこで、システム概要みたいなのは、「はじめに」の最後じゃなくって、はじめにもってきちゃって、そこで、システムの目的、システムの登場人物、システムのカラクリと全体構成を説明しちゃいたいのよ。
そーすると、ビジネスの考え方の流れに沿ってるし、経営陣は、そこだけ見れば、いいわけだから（あとは、幹部が読めばいい）
で、用語定義は、付録に持っていきたいなあ。。いっぱいあるしい。。見なくていいことも多いしい。。
アクセス
トータル
ランキング
