<< 実践 ICONIXプロセス : 要求レビュー ユースケースパッケージ図とユースケース図 | main | 実践 ICONIXプロセス : みんな考えていることが違うんだ >>

実践 ICONIXプロセス : 要求レビュー ユースケース記述

もっとも重要なユースケースから順番にレビューしてもらう。

ICONIXプロセスでは、ユースケース記述は、画面名やボタン名と用語集(ドメインモデル)の言葉を使って、具体的に簡潔に書くので、文章形式でも、レビューは十分やってもらえる。

ドメインモデルとユースケース図のレビューと改良が終わっているので、内容に違和感はないはず。

さらに効果的にやるために、ユースケースに登場する「すべての画面」を線画などで模型を作って、それを紙芝居風に順番に見せながら、ユースケースを説明していく。

すべてのユーザアクションと代替コースの説明ができる程度に、画面の詳細も描いておく。(ユースケースを書くときに、必ず画面の線画を描きながらユースケースを書いていく)

まず、基本コース。 
・晴れの日のシナリオは、ほんとうにユーザの期待にぴったりか?
・晴れの日のはずなのに、ユーザに何かひっかかりはないか?

それが終わったら、代替コースをひとつづつ順番に。

・雨の日のシナリオに違和感はないか?
・雨の日のメッセージ内容、画面の動きは、ユーザを混乱させないか?

最初は、ユーザ側と開発者の間にいろいろな意識の違いがあることがはっきりします。そもそも、画面名やボタン名が、ユーザには違和感があることが多い。

そこが重要。実際に動く画面まで作ってからのレビューは、手戻りが多い。そもそも時間的に修正がまにあわないかもしれない。

ユースケース記述のレビューの段階で、そういう違和感を検出し、修正できる効果は絶大です。

そのためにも、ユースケースの記述は、
・画面名、ボタン名は具体的に決めて記述する。
・代替コースのメッセージも含め、すべての画面の模型(線画)を描きながら、ユースケースを記述する。

ICONIXプロセスのユーズケース記述は、ユーザにわかる用語を重視して書きますが、記述の内容は、画面フローと画面処理のコーディングときわめて近い。

代替コースの記述は、そのまま if 文のコーディングになる感じ。

これがICONIXプロセスの手品のネタの一つです。

技術者からみるとコードの設計・記述にとても近い。
要求側からみると、自分たちにわかりやすく書かれている。

理解や考え方の違いが、ユースケース記述という最初の段階で、かなり具体的に発見でき、その修正は、コードの改良と直結している。

現場で実践してみると、これがマジックでもなんでもないことがよく実感できます。業務ニーズについて、技術者の勘違いや見落としを、いとも簡単に発見できます。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 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