カレッジ・スポーツ・ページング・システム 要求管理計画書
バージョン 1.0 改訂履歴
目次
要求管理計画書 1. はじめに1.1 目的この文書では、CSPS (カレッジ・スポーツ・ページング・システム) が使用するガイドラインについて説明され、ソフトウェア・プロジェクト要求を管理するために、要求文書、要求タイプ、要求属性、追跡可能性を規定しています。Rational
RequisitePro 要求管理ツールの
構成文書としても使用されます。
1.2 範囲この計画書はプロジェクトのすべてのフェーズに関連します。
1.3 定義、 頭字語、略語「用語集」を参照してください。
1.4 参考資料CSPS ソフトウェア開発計画書
CSPS 開発個別定義書
CSPS 測定計画書 CSPS 構成管理計画書 2. 要求管理2.1 組織、責務、インターフェースCSPS ソフトウェア開発計画書を参照してください。
2.2 ツール、 環境、インフラストラクチャーRational RequisitePro は要求の管理に使用します。このほか、インフラストラクチャーおよび環境については、CSPS ソフトウェア開発計画書を参照してください。
3. 要求管理プログラム3.1 要求の識別
3.2 追跡可能性![]() 図 1: 追跡可能性ダイアグラム FEAT 基準基本要件はユースケースまで追跡されます。
NEED 基準ユーザーのニーズは基本要件 (FEAT) まで追跡されます。FEAT まで追跡されないニーズは実装されません。
UC 基準ユースケースはテスト・ケースまで追跡されます。
SUPP 基準補足仕様書はテスト・ケースまで追跡されます。
3.3 属性FEAT 属性ステータス
プロジェクト管理チームによる協議およびレビュー後に設定されます。プロジェクト・ベースラインの定義中に進捗を追跡します。
利点 マーケティング、製品管理者、ビジネス分析者のいずれかにより設定されます。すべての要求が一様に作成されるわけではありません。ユーザーに関連する利点による要求のランク付けについて、顧客、分析者、開発チームのメンバーが検討します。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。
作業量 開発チームにより設定されます。基本要件によってはほかの基本要件よりも多くの時間とリソースを必要とするものがあるため、複雑性を評価し、与えられた時間枠の中で実現できるものとできないものを予測する場合には、延べ作業時間 (チーム週または人週)、必要なコードのライン数、機能ポイントなどを見積もるのが最善です。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。 リスク コストの超過、スケジュールの遅延またはキャンセルなど、プロジェクトに降りかかる望ましくない出来事の可能性を基に、開発チームにより設定されます。プロジェクト管理者の多くにとっては、リスクを高、中、低に分類すれば十分ですが、より細かく分類することも可能です。プロジェクト・チームのスケジュール見積もりの不確実性 (範囲) を測ることにより、間接的にリスクを評価できる場合も多くあります。 安定性 機能が変更になる、または、機能についてのチームの理解が変わる可能性を基に、分析者と開発チームにより設定されます。開発の優先順位を設定し、どの項目から付加的に引き出されたアクションが次のアクションとしてふさわしいかの決定に使用されます。 対象リリース 機能が最初に実装される予定の製品バージョンを記録します。このフィールドを使用して、開発構想書に記述されている基本要件を特定のベースライン・リリースに割り当てることができます。ステータス・フィールドと組み合わせると、リリースのさまざまな機能を、開発に委ねることなく、提案、記録、検討できます。ステータスが組み込み済みに設定され、対象リリースが定義される機能のみが、実装されます。開発範囲管理が発生する場合は、対象のリリース・バージョン番号を上げて、項目を開発構想書に残したまま後のリリースにスケジュールできます。 割り当て 多くのプロジェクトにおいて、機能は、さらに引き出されたアクション、ソフトウェアの要求の記述、実装を担当する「機能チーム」に割り当てられます。この簡単なプルダウン・リストにより、プロジェクト・チームのだれもが、責務をより理解することができます。 理由 このテキスト・フィールドは、 要求された機能のソースを追跡するのに使用されます。要求は特定の理由により存在します。このフィールドには、 説明または説明の参照先を記録します。例えば、参照先として、製品要求仕様書のページと行番号、または、 重要な顧客のインタビュー・ビデオの中の時間表示などがありえます。 NEED 属性ステータス
プロジェクト管理チームによる協議およびレビュー後に設定されます。プロジェクト・ベースラインの定義中に進捗を追跡します。
作業量 開発チームにより設定されます。ニーズによっては、ほかのニーズより多くの時間とリソースを必要とするので、延べ作業時間 (チーム週または人週)、必要なコードのライン数、機能ポイントなどを見積もることが、煩雑性を評価し、与えられた時間枠の中で何ができて何ができないかを予想する上で最良の方法です。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。 リスク コストの超過、スケジュールの遅延またはキャンセルなど、プロジェクトに降りかかる望ましくない出来事の可能性を基に、開発チームにより設定されます。プロジェクト管理者の多くにとっては、リスクを高、中、低に分類すれば十分ですが、より細かく分類することも可能です。プロジェクト・チームのスケジュール見積もりの不確実性 (範囲) を測ることにより、間接的にリスクを評価できる場合も多くあります。 安定性 ニーズが変更になる、または、ニーズについてのチームの理解が変わる可能性を基に、分析者と開発チームにより設定されます。開発の優先順位を設定し、どの項目から付加的に引き出されたアクションが次のアクションとしてふさわしいかの決定に使用されます。 対象リリース ニーズが最初に満たされる予定の製品バージョンを記録します。このフィールドを使用して、開発構想書に記述されている基本要件を特定のベースライン・リリースに割り当てることができます。ステータス・フィールドと組み合わせると、リリースのさまざまな機能を、開発に委ねることなく、提案、記録、検討できます。ステータスが組み込み済みに設定され、対象リリースが定義されるニーズのみが、満たされます。開発範囲管理が発生する場合は、対象のリリース・バージョン番号を上げて、項目を開発構想書に残したまま後のリリースにスケジュールできます。 理由 このテキスト・フィールドは、 ニーズのソースを追跡するのに使用されます。要求は特定の理由により存在します。このフィールドには、 説明または説明の参照先を記録します。例えば、参照先として、製品要求仕様書のページと行番号、または、 重要な顧客のインタビュー・ビデオの中の時間表示などがありえます。 UC 属性プロジェクト管理チームによる協議およびレビュー後に設定されます。プロジェクト・ベースラインの定義中に進捗を追跡します。
利点 マーケティング、製品管理者、ビジネス分析者のいずれかにより設定されます。すべての要求が一様に作成されるわけではありません。ユーザーに対する相対的な利点によるユースケースのランク付けについて、顧客、分析者、開発チームのメンバーが
検討します。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。
作業量 開発チームにより設定されます。ユースケースによっては、ほかの機能より多くの時間とリソースを必要とするので、延べ作業時間 (チーム週または人週)、必要なコードのライン数、機能ポイントなどを見積もることが、煩雑性を評価し、与えられた時間枠の中で何ができて何ができないかを予想する上で最良の方法です。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。 リスク コストの超過、スケジュールの遅延またはキャンセルなど、プロジェクトに降りかかる望ましくない出来事の可能性を基に、開発チームにより設定されます。プロジェクト管理者の多くにとっては、リスクを高、中、低に分類すれば十分ですが、より細かく分類することも可能です。プロジェクト・チームのスケジュール見積もりの不確実性 (範囲) を測ることにより、間接的にリスクを評価できる場合も多くあります。 安定性 ユースケースが変更になる、または、ユースケースについてのチームの理解が変わる可能性を基に、分析者と開発チームにより設定されます。開発の優先順位を設定し、どの項目から付加的に引き出されたアクションが次のアクションとしてふさわしいかの決定に使用されます。 対象リリース ユースケースが最初に実装される予定の製品バージョンを記録します。このフィールドは、ユースケースをユースケース概要から特定のベースライン・リリースに割り当てるのに使用されます。ステータス・フィールドと組み合わせると、リリースのさまざまなユースケースを、開発に委ねることなく、提案、記録、検討できます。ステータスが組み込み済みに設定され、対象リリースが定義されるユースケースのみが、実装されます。開発範囲管理が発生する場合は、対象のリリース・バージョン番号を上げて、項目を開発構想書に残したまま後のリリースにスケジュールできます。 割り当て 多くのプロジェクトにおいて、ユースケースは、さらに引き出されたアクション、ソフトウェアの要求の記述、実装を担当するチームに割り当てられます。この簡単なプルダウン・リストにより、プロジェクト・チームのだれもが、責務をより理解することができます。 理由 このテキスト・フィールドは、 要求されたユースケースのソースを追跡するのに使用されます。要求は特定の理由により存在します。このフィールドには、 説明または説明の参照先を記録します。例えば、参照先として、製品要求仕様書のページと行番号、または、 重要な顧客のインタビュー・ビデオの中の時間表示などがありえます。 SUPP 属性ステータス
プロジェクト管理チームによる協議およびレビュー後に設定されます。プロジェクト・ベースラインの定義中に進捗を追跡します。
利点 マーケティング、製品管理者、ビジネス分析者のいずれかにより設定されます。すべての要求が一様に作成されるわけではありません。ユーザーに関連する利点による要求のランク付けについて、顧客、分析者、開発チームのメンバーが検討します。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。
作業量 開発チームにより設定されます。仕様によっては、ほかの仕様より多くの時間とリソースを必要とするので、延べ作業時間 (チーム週または人週)、必要なコードのライン数、機能ポイントなどを見積もることが、煩雑性を評価し、与えられた時間枠の中で何ができて何ができないかを予想する上で最良の方法です。適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。 リスク コストの超過、スケジュールの遅延またはキャンセルなど、プロジェクトに降りかかる望ましくない出来事の可能性を基に、開発チームにより設定されます。プロジェクト管理者の多くにとっては、リスクを高、中、低に分類すれば十分ですが、より細かく分類することも可能です。プロジェクト・チームのスケジュール見積もりの不確実性 (範囲) を測ることにより、間接的にリスクを評価できる場合も多くあります。 安定性 仕様が変更になる、または、仕様についてのチームの理解が変わる可能性を基に、分析者と開発チームにより設定されます。開発の優先順位を設定し、どの項目から付加的に引き出されたアクションが次のアクションとしてふさわしいかの決定に使用されます。 対象リリース 指定された属性または機能が最初に実装される予定の製品バージョンを記録します。このフィールドは、仕様を特定のベースライン・リリースに割り当てるのに使用されます。ステータス・フィールドと組み合わせると、リリースのさまざまな仕様を、開発に委ねることなく、提案、記録、検討できます。ステータスが組み込み済みに設定され、対象リリースが定義される仕様のみが、実装されます。開発範囲管理が発生する場合は、対象のリリース・バージョン番号を上げて、項目を補足仕様書に残したまま後のリリースにスケジュールできます。 割り当て 多くのプロジェクトにおいて、指定された属性または機能は、 さらに引き出されたアクション、ソフトウェアの要求の記述、実装を担当するチームに割り当てられます。この簡単なプルダウン・リストにより、 プロジェクト・チームのだれもが、責務をより理解することができます。 3.4 レポートと測定CSPS 測定計画書を参照してください。
3.5 要求変更管理CSPS 構成管理計画書を参照してください。
次のアクセス・グループを設定して、Rational RequisitePro 内の要求へのアクセスを管理します。
Tool Administrator は、 ツールのすべての部分に完全にアクセスでき、ユーザーの追加や削除、アクセス権の 変更などができます。 Author は、 新規要求を作成できます。 Project Manager は、 要求のステータスを設定します。 Tester_QA は、 テスト・ケース要求のステータスを設定します。 3.6 ワークフローと作業CSPS 開発個別定義書を参照してください。
4. マイルストーンCSPS ソフトウェア開発計画書を参照してください。
5. トレーニングとリソースCSPS ソフトウェア開発計画書を参照してください。
|
Rational Unified Process
|