OOSC2を読んで思うこと。
OOSC1の時から思っていたのですが145ページ目辺りの
「ユースケースは順序性を決めてしまっているのでダメだ」って話を読んで
「なんだかなぁ」とか思ったりするわけです。
「順序性を後の工程に回すことによるメリットは何だ？」
確かに順序性を変えることによる仕様変更に対するシステムへのデメリットは大きいとは思う。
しかし(現代では)ワークフローエンジンを用いれば表向きには解決できること*1だと思うし
順序性を後に回したところで実装工程では何らかの順序性を決めなくてはならない。
でもMayer先生の本なので最後はどんでん返しで納得させられそうだけど。
「UMLモデリングの本質」をずいぶん前に読んで思ったのですが
ドメインモデルのUMLとかOCLとか見せて
理解してくれる客ってこの世にいるんですかね？
個人的にはユースケースで重要なのは「最低保証と成功時保証」だと思うんだけど
レベルが低く(具体的)なると順序性が必要なんだよな。
最近になって思うんだけど自分たち開発者は
「試行錯誤するのが当たり前」って主張をするんだけど
エンドユーザの試行錯誤を認めてないよね。
ユースケースや業務フローをまとめて仕様どおりに作って
後で順序性が異なれば要件変更でお金をもらう。
会社のビジネスフローに合わせてシステムを作るのだが
上記の論理からすると(担当者レベルでは)論理的に矛盾しているように思うし
エンドユーザも目的に対して「試行錯誤をするのではないか？」とか思った。
そういう観点に立つと要件定義には(順序性のない)ストーリーカードと
業務フローが動的に変更できるシステムが望ましいのかもしれません*2
