<< 実践 ICONIXプロセス : 要求レビュー ドメインモデル | main | 実践 ICONIXプロセス : 要求レビュー ユースケース記述 >>

実践 ICONIXプロセス : 要求レビュー ユースケースパッケージ図とユースケース図

ユースケースパッケージ図
機能一覧であり、メニュー体系です。

アクター名、ユースケース名、パッケージ名がユーザにしっくりくる名前になっていて、パッケージのまとめ方も違和感がなければ、ユーザから特に指摘はでません。

ユーザから何か発言があったら、丁寧に受け止めましょう。どこに見落としがあったか、どこがユーザと感覚が違っていたかを発見することに集中しましょう。

全体の機能の中で、現在は、この部分(パッケージ)から取りかかっている、という優先順位が正しいかも、このユースケースパッケージ図で確認できます。

ユースケース図

それぞれのパッケージ単位とか、優先して取り掛かっているユースケースについて、ユースケース図で確認してもらいます。

このとき、気をつけること。
・アクターとユースケースの線はできるだけ少なくする。なくとも良い。
・ユースケースの包含、拡張は「絶対に」やらない。
・ユースケースから別のユースケースへの連携( precedes や invoke ) は、単に矢印で示す。

ようするに、UML 的な表現は一切やめるということ。

・顧客が使う機能は、これこれです。
・操作の流れは、これこれです。

ということがぱっと理解できる図にする。

ユースケース図も、ユースケースパッケージ図も、ユーザに説明が不要なレベルを目指してください。

もちろん、質問やコメントは丁寧に受け止める。要求する側の意図、優先度を開発者が取り違えている兆候です。 どこが理解が一致していないのかを把握して、図を修正しましょう。

【注意】
思考を停止して、言われたとおりに図を修正してはだめ。
自分で考えて、理解しなおした内容を確認するために、図を修正する。修正したら、レビューしてもらい、理解が一致していることを確認する。

関係者でいろいろな理解の不一致がある。優先順位の考え方の違いがある。これが大前提です。だから、誰にでも共通にわかる言葉と表記方法で、ドメインモデリングとユースケースモデリングをやり、レビューして、不一致点を早く見つける。

それが、ICONIXプロセスの「要求レビュー」の目的。この時点の不一致の発見の価値はほんとうに大きい。

コードを書いてからの、リリースが迫ってからの不一致の発覚は悪夢です。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM