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

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

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

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

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

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

ユースケース図

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

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

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

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

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

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

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

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

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

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

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

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM