« 年金の過払いについて(あるいは社保庁のシステムについて) | トップページ | 選択エージェンシーと「監修料」と「告訴」について »

UML:ユースケースは、コミュニケーションツールです

 誰とコミュニケーションするかって? それは、書いた人と読む人だけでなく、書く人とシステムそのものをコミュニケートするツールともいえます。

 つまりこういうこと。最初にユースケースが描かれるとき、「システム」へ何を期待するかは必ずしも100%決まっているわけではありません。分析を繰り返していくうちに、ユースケースを書き換え/書き足していくうちに、書き手は「システム」がどうふるまうべきなのかを知るのです。

 ユースケースは読まれることを前提に書かれるべきです。かなりの書き手はこの大切な事実を見逃しています。レベルは最も低いレベルに合わせるべきです。最も低いレベルは、おそらく顧客(発注者)でしょう。顧客は、システムへの要望は把握しているが、そのためにシステムが何をしなければよいか分からないからです。

 ユースケースの書き手は、システムがどう振舞ってほしいのかを、外側(アクター)から見ても理解できる形、粒度で書きます。そうすることで、真に理解してもらうべき顧客(アクターが何を期待しているのか押さえている人)に分かってもらえるのです。

 ユースケースはいつまで更新されつづけるべきなのでしょうか? ユーザーレビューをするたびにユースケースの追加が起きているのであれば、顧客はRFP(request for proposal)をまとめられないということです。RFPをまとめきれない顧客は、往々にしてその組織体制に問題があることは経験的に自明です(そんな担当にRFPを任せているという致命的な問題も含む)。その場合は、残念ながら頑張って顧客よりも業務に詳しい人になるか、業務担当と裏で通じるしかありません。

 いずれにせよ、顧客(または業務部門の人)から「システムに期待する振舞い」が全て明らかになり、顧客自身の口からその機能が説明できるような段階になれば、ユースケース分析の段階は完了したといえるでしょう…
















さて、この記事、どこから理想論となっているでしょう?


  • どこも理想論ではない
  • 最初のパラグラフから
  • 最後のパラグラフから
  • 題名から理想論だよもん

*この記事では「ユースケース」とは「ユースケースシナリオ」および「ユースケース図」の意味で書きました

**このアタリマエな事実を、私はよく忘れます。自戒の意味でアップして、ときどき読み返すことで、1を目指します
--

|

« 年金の過払いについて(あるいは社保庁のシステムについて) | トップページ | 選択エージェンシーと「監修料」と「告訴」について »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: UML:ユースケースは、コミュニケーションツールです:

« 年金の過払いについて(あるいは社保庁のシステムについて) | トップページ | 選択エージェンシーと「監修料」と「告訴」について »