<< 実践 ICONIXプロセス : 要求レビュー 小さくやる | main | 実践 ICONIXプロセス : 要求レビュー ユースケースパッケージ図とユースケース図 >>

実践 ICONIXプロセス : 要求レビュー ドメインモデル

要求レビューで、ドメインモデルはクラス図の形式なので、ユーザが引いてしまうことがあります。

これを避け、実りあるレビューにするために。

ユーザにわかる言葉だけ使う

ICONIXプロセスでは、ドメインモデルは「用語集」です。システムが何ができるべきかを説明するときの、関係者の共通の言語です。
Domain-Driven Design ( DDD : ドメイン駆動設計 ) の ユビキタス言語パターンですね。

ドメインモデル図上の言葉は、ユーザが分かる言葉を使うことに時間とエネルギーを使ってください。「ユースケース駆動開発実践ガイド」では、最低でも80%の用語は、ユーザにわかる言葉にすべきとガイドしています。 

ドメインモデリングの過程でユーザが作成した資料とは別の、より妥当と思われる言葉が見つかることがあります。 概念がわかりやすくなるのであれば、そういう言葉は積極的に使うべきです。 (ユーザに分かりやすいこと、が前提です)

もし、ユーザの言葉と新しい概念(言葉)が一致しないときは、画面の紙芝居のほうは、ユーザの言葉にしておいて、ドメインモデルの用語との対応関係を画面で説明すると、わかりやすい。

例えば、画面の「足跡」情報はドメインモデルでは「アクセス履歴」としています、という感じですね。

ドメインモデルのレビューは「違和感のある言葉や意味の通じない言葉を指摘してください。」と切り出します。
指摘は素直に受け取りましょう。ユーザにぴんとこない言葉は、たぶん理解のズレを表しています。 説明して納得してもらうのではなく、別のより適切な、ユーザに分かりやすい言葉をいっしょに探しましょう。

汎化

汎化のシンボルの説明はしないこと。「汎化・特化」なんていう言葉はタブーです。

モデルを説明するときに、
「支払い方法」の種類には「クレジットカード」「現金振込み」「代金引換」があります。
と具体的に説明する。図の配置もこのグルーピングがわかるように描く。

これ以上、よけいな説明は不要です。概念(用語と整理のしかた)に違和感がなければ、ユーザからは質問はでてきません。

汎化・特化は、人間の思考であたりまえのやり方なので、概念が自然を描ければ、UMLの知識がまったくない人にも違和感は生じません。

集約

集約は、菱形の記号がみなれないため、多くのユーザがとまどいます。まちがっても「集約」という言葉で説明しないこと。

ドメインモデルの「集約」のほとんどは、
・ひとつの画面にいっしょに表示する情報 (それも中核の画面)
または
・ある画面からリンクでナビゲートする情報
として実現します。

ですから、画面イメージでこの集約関係を説明するとわかりやすい。

説明の例:

「書籍一覧」画面から「書籍」画面に遷移します。
「書籍」画面に、「著書」・「出版社」・「顧客レビュー」を表示します。

もちろん、ドメインモデル図は、すべての画面遷移を表しているわけではありません。
「基本」の遷移のみを示します。

集約の説明を、画面遷移の説明にすりかえる(?)ことで、いろいろな指摘がでてきます。

顧客レビューは、顧客プロファイルからも遷移できる、とかね。
その時に、「もっとも基本的な遷移はこれだと思うですが、どうでしょう?」という確認が効果がある。

そのソフトウェアをどう利用しようとしているか、何が重要な機能かの確認ができるわけです。

アプリケーションによっては、顧客プロファイルからたどる顧客レビューのほうが、書籍画面に顧客レビューを表示することより重大な関心ごとの可能性はある。

ドメインモデルの集約関係は、
・中核の画面とそこに表示する情報のグループの定義
・ミニマムな必須の画面遷移の定義
をあらわします。

ここを作らなくても良いから、こっちが欲しい、という指摘があれば、ドメインモデル図の関連を修正しましょう。

ここはもちろん必要。でも、こういう遷移も、という指摘は、ユースケースの追加候補です。

ユースケースとしてもおかしい「どこでもドア」が欲しいという画面遷移の要求は、私は、利用者にわかりにくい操作だと思うので、実装に反対します。「今は基本の流れをまず完成させましょう」とね。

言葉と配置

経験上、言葉がしっくりきて、上下や左右が自然な配置になっているドメインモデルはUML クラス図の形式でも、ユーザは違和感を持ちません。

・言葉がしっくりこない
・位置関係がしっくりこない
・線の意味がわからない

という指摘がでてきたら、良いことです。 ドメインモデルの問題箇所が見つかりました。 われわれの理解と顧客の理解が一致していない点が見つかりました。
しっくりくるようにモデルの改良に取り組みましょう。

受け入れテスト段階になって大騒ぎになる心配はまずなくなります。

早い段階で、ユーザとの理解の不一致を見つけることが、ICONIXプロセスの第3ステップ「要求レビュー」の目的です。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 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