1 つのプロジェクトでは、任意の数のタイプのドキュメントを生成できます。ここでは RequisitePro がドキュメントのアウトラインを提供するタイプのドキュメントについて説明します。
開発構想書では、より詳細な技術要求に対する上位レベルの基本を提供し、上位レベルの要求 (機能) とデザイン制約を取り込みます。開発構想書では、ユーザーのニーズ、目標と目的、ターゲット市場、ユーザー環境、製品機能に焦点を当てています。このドキュメントは、管理、マーケティング、プロジェクト チーム間のコミュニケーションの円滑化、プロジェクトの一般的な理解の促進、上位レベル機能の範囲と優先順位の確立などに役立ちます。
用語集ドキュメントは、問題のある範囲専用の用語を定義するために使用します。ユース ケース記述またはその他のプロジェクト ドキュメント内の、読者になじみのない用語について説明します。このドキュメントを非形式的データ ディクショナリとして使用してデータ定義を取り込み、ユース ケース記述やその他のプロジェクト ドキュメントでは、システムがその情報を使用して行うべきことに注目することができます。このドキュメントには、用語集で参照されているすべてのドキュメントの完全なリストを提供するセクションがあります。
ユース ケース仕様ドキュメントでは、アクターが実行するアクションとシステムがそれに応答して行うアクションについて説明しています。ユース ケースは、テキスト記述であり、主な目的はシステムの動作をわかりやすくドキュメント化することです。内容は、アクターとシステム間でのダイアログ形式で記述する必要があります。ユース ケースでは、システム内で発生する事柄について記述するもので、方法または理由は記述しません。ドキュメントには基本的なフローと代替フローが含まれます。ユース ケースのテキスト内には、簡単な代替フローが示されていることもあります。
一般的にこれらのドキュメントは、チームで扱う必要のある実際の問題と、チームで推奨する解決法によって影響を受ける利害関係者について、プロジェクト チームが明確に理解してから生成されます。これらは、追加機能が必要になり、新規ユース ケースが識別されたときにプロジェクト内で後から改訂されたり詳述される場合がありますが、一般的にはプロセスの最初の段階で生成されます。ドキュメントは、問題の定義、解決法によって提供される機能の一覧表示、すべての関係者が同じ方法で用語を使用し同じシステム環境であることの確認、システムから提供される動作の定義に重要なツールです。このようなアクティビティに時間を割くことにより、チーム メンバー全員の間でのコミュニケーションが向上し、相互理解が深まります。
補足要求仕様ドキュメントでは、特定のユース ケースに結び付けることができない要求、ほとんどの非機能要求とデザイン制約を取り込みます。
テスト計画ドキュメントは、既存のプロジェクト情報やテストするソフトウェア コンポーネントを識別し、上位レベル テスト用の推奨要求を一覧表示し、使用するテスト戦略を記述し、必要なリソースを識別し、テスト労力の見積りとテスト プロジェクトの提供可能な要素を提供します (Rational TestManager をインストールした場合は、そのツールを使用してすべてのテスト成果物を開発することをお勧めします)。
補足要求仕様ドキュメントとテスト計画ドキュメントが生成されるのは、プロセスの後半におけるすべての必要な機能とユース ケース識別後です。