機能要求を「ユースケース」(利用者=アクターから見たシステムの利用場面)としてまとめ,それを基に分析設計することが一般化してきた。ところが「ビジネス・ルールを入れ込んだり,if~thenレベルのロジックまで書き込んだりと,誤った書き方をしている人が結構多い」と,日本を代表するITアーキテクトの1人,榊原彰氏(日本IBM 東京基礎研究所 IBMディスティングイッシュト・エンジニア)は指摘する。どんどん詳細化し,必要ない情報まで盛り込んでしまうのだ。

   「詳細化しないと気が済まないのだろう。『分析麻痺(Analysis Paralysis)』と言える」と同氏。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進するチェンジビジョンの平鍋健児氏(代表取締役)も同意見。「画面レイアウトなど情報量が多過ぎることが結構ある。ユースケースはシステムの目的なのに,ユースケース=機能と考えるからそうなる」(平鍋氏)。

 ユースケースに詳細を書くと,かえって分析設計の邪魔になる。「どんな条件で起動し,何を実行し終了したときにどんな状態になるかという流れがスッキリ書いてあればいい」(榊原氏)。に悪い例と良い例を示したので参考にしてほしい。

図●悪いユースケースと良いユースケースの例
図●悪いユースケースと良いユースケースの例
悪いユースケースは,中途半端な構造記述を用いているほか,メインのシナリオ,代替シナリオ,バリエーションが混在しており,ビジネス・ルールも書き込んでいる。一方,良いユースケースは,メインのシナリオ,代替シナリオ,バリエーションを区別しており,シナリオの把握に不要なビジネス・ルール(注文参照番号は顧客番号と当該顧客の注文番号から成るなど)は,別途カタログとして作成している
[画像のクリックで拡大表示]