カレッジ・スポーツ・ページング・システム

要求管理計画書
 
 

バージョン 1.0


 



 
 

改訂履歴


日付
バージョン
説明
作成者
2000 年 7 月 2 日
1.0
初版
Context Integration


目次
 
 

1.はじめに

1.1 目的

1.2 範囲

1.3 定義、頭字語、略語

1.4 参考資料

2.要求管理

2.1 組織、責務、インターフェース

2.2 ツール、環境、インフラストラクチャー

3.要求管理プログラム

3.1 要求の識別

3.2 追跡可能性

FEAT 基準

NEED 基準

UC 基準

SUPP 基準

3.3 属性

FEAT 属性

NEED 属性

UC 属性

SUPP 属性

3.4 レポートと測定

3.5 要求変更管理

3.6 ワークフローと作業

4.マイルストーン

5.トレーニングとリソース
 


要求管理計画書

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 要求の識別

 
成果物 (文書タイプ)
要求タイプ
説明
開発構想書 (VIS)
利害関係者のニーズ (NEED)
主な利害関係者またはユーザーのニーズ
開発構想書 (VIS)
基本要件 (FEAT)
このリリースのシステムの条件または機能
ユースケース・モデル
ユースケース (UC)
このリリースのユースケース (Rational Rose に文書化、Rational RequisitePro に詳細あり)
補足仕様書 (SS)
補足要求 (SUPP)
ユースケース・モデルには取り込まれない機能外要求
表 3.1.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