もっとも重要なユースケースから順番にレビューしてもらう。
ICONIXプロセスでは、ユースケース記述は、画面名やボタン名と用語集(ドメインモデル)の言葉を使って、具体的に簡潔に書くので、文章形式でも、レビューは十分やってもらえる。
ドメインモデルとユースケース図のレビューと改良が終わっているので、内容に違和感はないはず。
さらに効果的にやるために、ユースケースに登場する「すべての画面」を線画などで模型を作って、それを紙芝居風に順番に見せながら、ユースケースを説明していく。
すべてのユーザアクションと代替コースの説明ができる程度に、画面の詳細も描いておく。(ユースケースを書くときに、必ず画面の線画を描きながらユースケースを書いていく)
まず、基本コース。
・晴れの日のシナリオは、ほんとうにユーザの期待にぴったりか?
・晴れの日のはずなのに、ユーザに何かひっかかりはないか?
それが終わったら、代替コースをひとつづつ順番に。
・雨の日のシナリオに違和感はないか?
・雨の日のメッセージ内容、画面の動きは、ユーザを混乱させないか?
最初は、ユーザ側と開発者の間にいろいろな意識の違いがあることがはっきりします。そもそも、画面名やボタン名が、ユーザには違和感があることが多い。
そこが重要。実際に動く画面まで作ってからのレビューは、手戻りが多い。そもそも時間的に修正がまにあわないかもしれない。
ユースケース記述のレビューの段階で、そういう違和感を検出し、修正できる効果は絶大です。
そのためにも、ユースケースの記述は、
・画面名、ボタン名は具体的に決めて記述する。
・代替コースのメッセージも含め、すべての画面の模型(線画)を描きながら、ユースケースを記述する。
ICONIXプロセスのユーズケース記述は、ユーザにわかる用語を重視して書きますが、記述の内容は、画面フローと画面処理のコーディングときわめて近い。
代替コースの記述は、そのまま if 文のコーディングになる感じ。
これがICONIXプロセスの手品のネタの一つです。
技術者からみるとコードの設計・記述にとても近い。
要求側からみると、自分たちにわかりやすく書かれている。
理解や考え方の違いが、ユースケース記述という最初の段階で、かなり具体的に発見でき、その修正は、コードの改良と直結している。
現場で実践してみると、これがマジックでもなんでもないことがよく実感できます。業務ニーズについて、技術者の勘違いや見落としを、いとも簡単に発見できます。
ICONIXプロセスでは、ユースケース記述は、画面名やボタン名と用語集(ドメインモデル)の言葉を使って、具体的に簡潔に書くので、文章形式でも、レビューは十分やってもらえる。
ドメインモデルとユースケース図のレビューと改良が終わっているので、内容に違和感はないはず。
さらに効果的にやるために、ユースケースに登場する「すべての画面」を線画などで模型を作って、それを紙芝居風に順番に見せながら、ユースケースを説明していく。
すべてのユーザアクションと代替コースの説明ができる程度に、画面の詳細も描いておく。(ユースケースを書くときに、必ず画面の線画を描きながらユースケースを書いていく)
まず、基本コース。
・晴れの日のシナリオは、ほんとうにユーザの期待にぴったりか?
・晴れの日のはずなのに、ユーザに何かひっかかりはないか?
それが終わったら、代替コースをひとつづつ順番に。
・雨の日のシナリオに違和感はないか?
・雨の日のメッセージ内容、画面の動きは、ユーザを混乱させないか?
最初は、ユーザ側と開発者の間にいろいろな意識の違いがあることがはっきりします。そもそも、画面名やボタン名が、ユーザには違和感があることが多い。
そこが重要。実際に動く画面まで作ってからのレビューは、手戻りが多い。そもそも時間的に修正がまにあわないかもしれない。
ユースケース記述のレビューの段階で、そういう違和感を検出し、修正できる効果は絶大です。
そのためにも、ユースケースの記述は、
・画面名、ボタン名は具体的に決めて記述する。
・代替コースのメッセージも含め、すべての画面の模型(線画)を描きながら、ユースケースを記述する。
ICONIXプロセスのユーズケース記述は、ユーザにわかる用語を重視して書きますが、記述の内容は、画面フローと画面処理のコーディングときわめて近い。
代替コースの記述は、そのまま if 文のコーディングになる感じ。
これがICONIXプロセスの手品のネタの一つです。
技術者からみるとコードの設計・記述にとても近い。
要求側からみると、自分たちにわかりやすく書かれている。
理解や考え方の違いが、ユースケース記述という最初の段階で、かなり具体的に発見でき、その修正は、コードの改良と直結している。
現場で実践してみると、これがマジックでもなんでもないことがよく実感できます。業務ニーズについて、技術者の勘違いや見落としを、いとも簡単に発見できます。