この前のブログのつづき、要求仕様書の規約IEEE 830に準拠して書くと、こまること。
その２：
２．機能の定義の仕方が、オブジェクト指向などと合わない可能性がある
→オブジェクト指向では、このフォーマットだと書きにくい
についてです
上記の規約において、機能用件をかくところについて。
以下のような項目がある。（ここから引用）
◆外部インタフェース
ソフトウェア・システムの入出力について具体的に説明する。ただし、インタフェースの説明を補足するものであるため、同じ情報は繰り返さないほうがいい。
◆機能
入力の受付と処理および出力の処理と作成時に必要となる基本的な動作を定義する。機能要求を下位機能や下位プロセスに分けることが適切な場合もある。ただしソフトウェア設計でも要求の機能階層と同じ階層構造で下位機能に分解されるとは限らないので注意しておく。
つまり、機能を記述する際に、入出力について、具体的に示さないといけない。
このとき、DFDであれば、入出力は明確になっているので、簡単。そのまま書けばいい。
そして、この規約が決まった当時、１９９８年ごろは、たいてい、機能の定義とは、（業務フローにおいても）
○○、■■を入力とし、△△を出力する
といった、入出力による、業務内容の規定が中心だった。だから、この形で、なんら困らない。
ところが、オブジェクト指向になると、出力や入力について、その出力物、（たとえば、受注伝票とか）入力データそのものをクラスとしてしまう形で、話をすすめることが可能となる。
とくに、要求仕様段階では、業務内容をアクティビティ図、ユースケース図（ユースケース）で定義してしまった場合、入出力データの具体的な内容について定義しないで話を進められる。
この進め方は、昔の人たちから見ると、プロセスを検証していないことになるので、大きなリスクを抱えると思うだろう。
（あとから、この入力では、このプロセスは、実施できないと気づくリスクとか。。たとえば、ピザを配達するといったとき、顧客データ（クラス）という形にまとめてしまうがゆえに、住所は、どこで取ってくるのか、誰がいつ入力するのかを検証しないで、あいまいにして話を進めることが可能になってしまうケースとか）
でも、いま、そんなことをいって、「だから、オブジェクト指向分析で、業務プロセスから追っていくのは危険です」といったら、「空気よめー」といわれてしまい、意見を言うのもはばかられる。ふつう。
なので、入出力データについて、オブジェクト指向分析でやった場合（＝最近の分析）だと、はっきりしない。
なお、上記のケースは、アクティビティ図、ユースケース図を中心にしたからで、オブジェクト指向における業務分析でも、図を、BPMNで記述した場合には、（って、どういう図？という場合には、ここをみてね）データオブジェクトに、データは、表現されるジャン！っていう意見もあると思います。
それはそれで、確かなのですが、データオブジェクトは、補足的な情報で、必ずしも、きっちりしっかり書くというわけではないし。。ということで、アクティビティ図、ユースケース図だけよりかはいいかもしれないけど、まだ、データオブジェクトを使って、プロセスの内容を検証できるかどうかがはっきりしないという点で、不十分な気がします。
こまった。どうしよう。
でも、逃げ手があるんだな。
IEEE 830では、機能の要求の書き方として、８とおり考えています。（さっきのところから引用）
A1 ：外部インタフェースを記述してから、運用状態ごとに機能要求を記述する
A2 ：運用状態ごとに、外部インタフェースと機能要求を記述する
A3 ：外部インタフェースを記述してから、ユーザー種別ごとに機能要求を記述する
A4 ：外部インタフェースを記述してから、オブジェクトごとに、属性と機能要求、メッセージを記述する
A5 ：外部インタフェースを記述してから、サービス種別ごとに、目的、刺激と応答、機能要求を記述する
A6 ：外部インタフェースを記述してから、刺激ごとに機能要求を記述する
A7 ：外部インタフェースを記述してから、データフロー図を用いて機能要求を階層的に記述する
A8 ：外部インタフェースを記述してから、複数の視点の組み合わせごとに機能要求を記述する。
このA1を、無理やりだけど、こう解釈してしまう。
３−１．外部インターフェース
ってかいて、このシステムの外部とやりとりする入出力データを書いてしまって、
３−２．機能
って書いて、詳細化した業務内容（アクティビティ図、ユースケース図）を、いっぺんにかいてはり込んじゃえば（＾＾；）
上の人とかには、ばれなさそう（＾＾；）
機能を書くとき、こーいう書き方をしてきた部下がいたら、「ウィリアムのいたずらって知ってる？」と聞いてみましょう（＾＾；）
そのやり方が問題で、このプロセスをデータで裏づけないあいまいさが、システムの現場を混乱させていたり、デスマーチを招いていることはたしかなんだけど、「だから、オブジェクト指向に問題がある」とか言い出したら、みんなから袋叩きにあって、だれも会社でいうことを聞いてくれなくなるのが現状でしょう。
だから、表面的には、「オブジェクト指向まんせー」っていっておいて、上みたいな仕様書を書く。
もちろん、個人的には、データの流れを追っていって、おかしいところをチェック、予防線を張っておくんだけど（インターフェースのサンプルデータを書くという方法でチェックする）、それは仕様書には書かないし、だれにもいわない。マネージャーやプロジェクトリーダーのお仕事っていうのは、そういう想定をどこまで読みきるかにあるよね！（実際、今、サンプルデータって、くるでしょ。それは、その危険性を理解して、わたしてくれているわけよ）。
当然、オブジェクト指向で、みんな考えて、安易にクラス化、隠蔽してしまうと、たいてい、こういうデータ間の矛盾があとから矢継ぎ早に出てくる（データがとってこれないっていうやつ）。そのとき、想定していた予防線を、「想定の範囲内です」といって、披露すればいい。
はじめからいったら、みんなにぼこぼこにされて、うつ病になっちゃうからね。
まあ、そのままつっぱしっても、どーしょーもなくなって、うつ病になってしまうんだが。。。。
