ICONIXプロセスでは、個々のユースケースを書き始めるまえに、ユースケース図でアクターとユースケースを洗い出していく。ユースケースは、すぐ増えるので扱いやすいようにパッケージ図を使って、整理(組織化)する。
このユースケース図で描いた構造を、実装すると画面上では、たとえば階層メニュー(メニューツリー)になる。アクターごとに別のトップ画面があるサービスなら、ユースケース図のパッケージとトップ画面が対応する。
ユースケースモデリングの最初のステップであるユースケース図作成が、そのままメニューの実装につながる。
ICONIXプロセスは、ここ以外にメニューの詳細設計や検討をする手順はでてきません。ユースケース図とそのパッケージ構成が、そのままメニュー構成、トップ画面構成になります。
その視点で、ユースケース図のレビューをやると、いろいろ課題や疑問がみつかります。あるいは画面プロトタイプの早い段階で、ユースケース図の構造と実際のメニュー階層ととが一致していることを確認する。
ユースケースの構成と、画面のメニュー構成に、用語・グルーピング・順番などの不一致があるのは、問題領域の理解がずれている注意信号です。敏感にキャッチして、早い段階で、不一致をつぶしましょう。
このユースケース図で描いた構造を、実装すると画面上では、たとえば階層メニュー(メニューツリー)になる。アクターごとに別のトップ画面があるサービスなら、ユースケース図のパッケージとトップ画面が対応する。
ユースケースモデリングの最初のステップであるユースケース図作成が、そのままメニューの実装につながる。
ICONIXプロセスは、ここ以外にメニューの詳細設計や検討をする手順はでてきません。ユースケース図とそのパッケージ構成が、そのままメニュー構成、トップ画面構成になります。
その視点で、ユースケース図のレビューをやると、いろいろ課題や疑問がみつかります。あるいは画面プロトタイプの早い段階で、ユースケース図の構造と実際のメニュー階層ととが一致していることを確認する。
ユースケースの構成と、画面のメニュー構成に、用語・グルーピング・順番などの不一致があるのは、問題領域の理解がずれている注意信号です。敏感にキャッチして、早い段階で、不一致をつぶしましょう。