要求収集の進め方

「ユースケース導入ガイド」という本を買って読んだのでそのまとめ。

要求収集をFacade、Filled、Focused、Finishedという4つのフェーズにわけ、イテレータブル且つインクリメンタルに要求収集を行う。

・目標

提案されたアプリケーションに対してユーザが行うことが予想される、 個々の主要な相互作用の記述場所を確保すること。

・要約

アクターとシステムの間の最も重要な相互作用を表す。 セキュリティ、監査、バックアップ、リカバリといった活動は、 主要なビジネス相互作用を支援するものなので後のイテレーションに回す。

・役割

• 要求分析者：Facadeユースケース、ユースケース図、ビジネスルールの作成。
• 関係者：インタビューへの参加。
• 技術アーキテクト：仲間内でのレビューの出席。
• プロジェクト管理者：作業ステートメント作成支援、問題ステートメント作成支援。

・成果物

• システムコンテキストユースケース
• 問題ステートメント：完了。ただし将来改訂する可能性アリ。
• 作業ステートメント：完了。ただし将来改訂する可能性アリ。
• リスク分析：完了。ただし、リスクは全てのイテレーションで追加または 削除される。
• Facadeユースケース：後に機能が書き込まれる領域としての枠組み。

・目標

アプリケーションについて記述してるユースケースとビジネスルールを、 包括的に揃えること。

・要約

システムを記述するのに十分な情報が集まっている。 多くのプロジェクトにおいては、 このイテレーションにおいて作成されたユースケースと同程度のものを使って、 設計を開始することができる。

・役割

• 要求分析者：ユースケースとビジネスルールの詳細情報の追加。
• 関係者：インタビューへの参加。
• 技術アーキテクト：非機能的要求の決定支援。
• プロジェクト管理者：作業ステートメントと問題ステートメントの更新。

・成果物

• 問題ステートメント：改訂されたもの、もしくは変更なし。
• 作業ステートメント：改訂されたもの、もしくは変更なし。
• リスク分析：追加されたもの。
• Filledユースケース：基本フロー、代替パス、例外パス。
• ビジネスルール：一覧の初版を作成。
• 非機能要求：開始。
• シナリオテスト：重要なユースケースのシナリオを書き、テストする。
• ユースケースの追加

・目標

明らかにされた選択肢のうち最善なものを選択して、 プロジェクトの適用範囲に含めるようにする。 →重複するプロセスを除去する。 ドキュメント作業の方針が整理整頓されて、 明確なプロジェクト要求だけが残される。 本質的なことと、単なる願望を区別する。 適用範囲を注意深く検討し、無駄を排除すること。

・要約

ユースケース間に存在するすべての依存性を明らかにして、 可能なところでは常に整理統合を行う。

・役割

• 要求分析者：仮定が正しいことを確認するためにインタビューを行う。 インタビューによりユースケースの整理統合。
• 関係者：インタビューへの参加。
• 技術アーキテクト：非機能要求の洗練化。レビューへの参加。
• プロジェクト管理者：作業ステートメントと問題ステートメントの洗練化。

・成果物

• 問題ステートメント：改訂されたもの、もしくは変更なし。
• 作業ステートメント：改訂されたもの、もしくは変更なし。
• リスク分析：追加されたもの。
• Focusedユースケース：ユースケースを洗練。
• ビジネスルール：一覧の初版を作成。
• ユースケースの追加、統合

・目標

ユースケースに非機能要求を統合して、 ユーザインタフェースに関する要求を加えまとめあげる。

・要約

要求の収集が完了する。 設計の過程で実装されることになる、 ユーザーインターフェース要求の概要を記述する。

・役割

• 要求分析者：ユースケースの整理統合。
• 関係者：承認への関与。
• 技術アーキテクト：非機能要求の洗練化。レビューへの参加。
• プロジェクト管理者：作業ステートメントと問題ステートメントの洗練化。

・成果物

• 問題ステートメント：改訂されたもの、もしくは変更なし。
• 作業ステートメント：改訂されたもの、もしくは変更なし。
• リスク分析：追加されたもの。
• Finishedユースケース：非機能要求をステレオタイプとして追加。
• ビジネスルール：変更。
• ユーザインターフェースガイドライン：開始して完了。