チェックポイント
短納期開発プロジェクトに適した要求管理のアプローチ
「要求を構造化でき、不備を発見しやすくすること」「要求のセットを明確にし、合意を得ること」「変更による影響範囲を正確に把握できること」）
要求管理のために。
良いユースケースというのは、機能要件を知るべき人々にとって円滑なコミュニケーションを可能にする
ユースケースというのは、要求管理の重要な一部分
開発が進む過程で要求のエラーを修正するにはコストがかかりすぎる。そもそもユースケースは、何を構築するのか、あるいは何を構築しないのかをまず明確にすることから始まる。
ユースケースは機能要件をストーリーとして書き出すことが必要である。その後、ダイアグラムに落としていく。しかし、機能要件を書き出す段階が難しい。表（個条書き）のように書いてしまうのは簡単だが、それでは機能要求を十分に補完することは難しい。そのため、一貫した“話（ストリー）”として表現しなければならないのだ。何がどうなったら、どうなるのか。これが起こらなかったら、何が起こるのか？というように。構造化手法で
システム開発の経験があるエンジニアがよく陥る。
では、何をアクターにし、何をユースケースとするのか。その判断基準は何だろうか。アクターの定義にはいろいろな解釈があるが、標準的なTipsとしては、プリンタやDBはアクターにはならない、プログラムをしているシステムはアクターにはならない、デバイスはアクターとしてモデリングしないなどの “常識”を知っておくとよい。このような基本的な指針に沿ってアクターを決めていく。行き詰まったら、無視して先に進むこと。重要だと思ったら、後から追加すればよい。
ユースケースを書くにはスタイルがある。例えば、フローのステップごとに番号を打つのかタイトルだけにするのか、メインフローとサブフローを分けて表現するのか、使われる用語などなど。ユースケースを書くうえでスタイルを統一することが重要だ。これが守られていない例は多い。
ラショナルが提唱するスタイルは、各ステップにナンバリングをするか名前をつける。メインフロー（main flows）のステップは、代替フロー（alternate flows）を参照しないようにするなどだ（メインフローとは、搭載される予定の機能がトラブルなく推移するフローであり、代替フローは、例外やエラーなどを含むフローである）。ユースケースのスタイルは現在およそ30種類ほどあるが、どれが一番優れているかという議論には意味がない。スタイルが統一されているかどうかが重要になる。スタイルの統一がされていないユースケースは非常に読みにくく、機能要件がうまく伝わらない。ただ、ラショナルでは、要求管理から設計に至るまでをサポートするRUPの存在があり、ユースケースのスタイルとも密接な関係を保っている部分が優位だと考える。もちろん、方法論はなくても開発はできるし、ユースケースも書けるが、ないよりはあった方がいい。
関連ドキュメント
分からないことは？
最終更新：2009年07月15日 19:18
