![[PukiWiki]](image/seasar.png "[PukiWiki]")
新業務フローが画面遷移に当たるので、そこからUIモックを作ることになります。
特に難しいことはありません。
ただし、UIモックはできるだけ早い段階で顧客レビューした方が良いです。
UIモックでのフィードバック(要求漏れの発現)の遅れは、
質、量ともに重要で、発現が早くなる分リスクが減ります。
タイミングとしては、新業務フローが確定しないまでもある程度固まってきたら、
同時にUIモックの作成をはじめた方が良いです。
ロバストネス分析前にラフな画面イメージをレビューしてもらう感じです。
このとき、「開発途中のものなので・・・」というフォローは使い方を気を付けましょう。
顧客が、
(本当はナビとしてこういう情報が必要だけど、それぐらいわかってるだろうし、開発中だから含まれてないんだろうな)
というような思考になって要求が出てこないことがあります。
バウンダリのイベント毎に、
という観点でコントロールを抽出し、
コントロールが
ということでエンティティを抽出します。
ロバストネス分析を行う単位は、シナリオ毎が目安になります。
但し、登録、変更、削除等が極めて近いフローで行われいたり、
個々のシナリオのフローが短くて、
分けるよりも一つに纏めた方が楽で分かりやすいというような場合は、
複数シナリオを一枚にしても問題ありません。
UIモックとロバストネス図のバウンダリとコントロールから、
項目とデータの関連と入力チェックを中心に纏める。
エンティティ毎にエンティティの属性とその特性を纏める。
属性の抽出は、
を集めればよいはずです。
シナリオをUMLのシーケンス図で書きます。
まず、バウンダリと業務ロジックとDAOを登場させます。
次に、バウンダリから業務ロジックへコントロールに当たるメソッドを呼び出します。
あとは、コントロールをアトミックなユーザ機能になるまで分解しながらシナリオが通るように進めます。
シナリオは、
のケースについて分析します。
このとき抽出されたユーザ機能は、ルールに基づいてインターフェイスに纏めながら進めます。
シナリオ分析の粒度は、一つのシナリオです。
ロバストネス分析と違って、複数のシナリオが纏められることは殆どありません。
逆に一つのシナリオが大きくなりすぎることもあるため、
そういう場合は、複数枚のシーケンス図に分解することになるかもしれません。
全てのシナリオをシーケンス図に書き終わったらシナリオ分析完了です。
あとは、インターフェイス毎に仕様書を書けば内部設計完了です。
