Wylie カレッジ

要求管理計画書

 

バージョン 2.0

 

 

改訂履歴

日付

バージョン

説明

作成者

1999 年 1 月 8 日

1.0

初版リリース

サイモン・ジョーンズ

1999 年 2 月 10 日

2.0 

計画を拡張 

 サイモン・ジョーンズ

 
 
 
 
 
 
 
 

 


目次

1.     はじめに  

1.1      目的  

1.2      範囲  

1.3      定義、頭字語、略語  

1.4      参考資料  

2.     要求管理

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

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

3.     要求管理プログラム   

3.1      要求の識別  

3.2      追跡可能性  

3.2.1     製品要求の評価基準

3.2.2     ユースケース要求の評価基準

3.2.3     テスト・ケースの評価基準

3.3      属性  

3.3.1      ユースケースの要求属性

3.3.2     テスト・ケースの属性

3.4      レポートと測定  

3.5      要求変更管理

3.6      作業分野とタスク  

4.     マイルストーン  

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


要求管理計画書

1.                  はじめに

1.1               目的

「Requirements Attributes Guidelines」 では、Wylie カレッジでのすべてのソフトウェア・プロジェクトの要求の管理に使用する属性の確認と説明をします。 さらにこの文書では、開発中に各プロジェクトで記録を付けておく要求追跡可能性についても概説します。

各要求に割り当てられる属性は、ソフトウェア開発の管理と、リリースごとの諸機能の優先順位の設定とに使用されます。

要求追跡可能性の目的は、 開発サイクルの後半になって見つかる不具合の件数を減らすことです。ソフトウェア要求、 設計、テスト・ケースに含まれるすべての製品要求を確実に把握しておけば、製品の品質が改善されます。

1.2            範囲

本書に示す属性と追跡可能性のガイドラインは、Wylie カレッジのすべてのソフトウェア・プロジェクトの製品要求、ソフトウェア要求、テスト要求に適用されます。

1.3                定義、頭字語、略語

Rational Unified Process と Rational RequisitePro のマニュアル類とに定義されている用語を使用します。

1.4                参考資料

次の参考資料が Wylie カレッジのソフトウェア・プロセス Web サイトにあります (または同サイトからリンクが張ってあります)。

1. 「Wylie カレッジ構成管理計画書」
2. 「Rational Unified Process」
3. 「Wylie カレッジ開発個別定義書」

2.                  要求管理

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

個々のプロジェクトの「ソフトウェア開発計画書」で規定されます。

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

要求の属性と追跡可能性の管理には Rational RequisitePro が使用されます。  ほかのインフラストラクチャーの詳細については、Wylie カレッジのソフトウェア・プロセス Web サイトに記してあります。

3.                  要求管理プログラム

3.1                要求の識別

プロジェクトごとに、次の要求タイプの識別と管理が行われます。

 

ワーク・プロダクト

 

要求タイプ

説明

開発構想書

製品要求

製品の特性、制約事項、品質範囲、その他の製品要求。

ユースケース・モデル

ユースケース

ユースケース (Rational Rose で文書化)

テスト計画書

テスト・ケース

システムが期待どおりの動作を示すことをどのようにして確認するかを示すケース。

 

3.2                追跡可能性

3.2.1     製品要求の評価基準

「開発構想書」に規定された製品要求は、  「ユースケース仕様書」と「補足仕様書」とに記したユースケース要求または補足要求のうち、 それぞれに対応する要求までトレースされます。

各製品要求の元をたどっていけば、 1 つ以上のユースケース要求と補足要求に行き着きます。

各製品要求の元をたどっていけば、 1 つ以上のユースケース要求と補足要求に行き着きます。

3.2.2     ユースケース要求の評価基準

「ユースケース仕様書」と「補足仕様書」とで規定したユースケース要求は、  「テスト計画書」で規定したテスト・ケースのうち、それぞれに対応するテスト・ケースにまでトレースされます。

各ユースケース要求の元をたどれば、 1 つ以上のシステム・テスト・ケースに行き着きます。

3.2.3     テスト・ケースの評価基準

「テスト計画書」に規定されたテスト・ケースの元をたどれば、 個々のテスト・ケースで検証される製品要求 (「開発構想書」) とユースケース要求とに行き着きます。

1 つのテスト・ケースの元をたどれば、1 つ以上の製品要求とユースケース要求に行き着きます。テスト・ケースで派生要求または設計を検証する場合だと、 そのテスト・ケースは、元の製品要求へもユースケース要求へも辿れない場合があります。

3.3                属性

3.3.1      ユースケースの要求属性

ユースケース要求と「補足仕様書」は、 このセクションで規定する属性を使用して管理されます。この属性は、 開発作業の管理、反復コンテンツの決定、ユースケースとその Rose モデルとの関連付けを行うのに便利です。

ステータス

分析によりユースケースの草案ができた後に設定します。 ユースケースの最初の草案からユースケースの最終的な確認に至るまでユースケースの開発の進捗を常に把握します。

提案済み

レビューと承認はまだ実行されていないが、確認は済んでいるユースケース。

承認済み

設計と実装をさらに進めてもよいという承認を得たユースケース。

検証済み

システム・テストで検証の済んだユースケース。

優先度

プロジェクト管理者が設定します。 開発リソースをユースケースに割り振ることと、 ユースケースの開発の進捗を監督することとの重要性の観点からユースケースの優先順位を決定します。一般に優先順位を決める基準になるのは、 ユーザーにとって効果のある利点、計画済みのリリース、計画済みの反復、ユースケースの複雑さ (リスク)、ユースケースの実装作業です。

ユースケースの実装を詳細に監視することと、 リソースが正しく当該タスクに割り当てられることとを確実に行うことに関して、高い優先順位を持つユースケースです。

ほかのユースケースに比べて中くらいの優先順位を持つユースケースです。

優先順位の低いユースケースです。このユースケースの実装は重要度が低く、その後の反復またはリリースに回されたりスケジュールが組み直されたりすることがあります。

作業量の見積もり

開発チームが設定します。 一部のユースケースはほかに比べて多くの時間とリソースが必要なため、 例えば何チームで何週間かかるか、何名で何週間かかるか、必要なコードの行数、機能ポイントといった項目を見積もることは、 複雑さを判断したり、所定の時間枠の中で何ができて何ができないかの予想を立てたりするのに最良の方法です。 適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。プロジェクト管理者は、この作業量の見積もりを使用して、 プロジェクトのスケジュールを立て、効果が上がるよう各タスクへのリソースの割り当て計画を練ります。

1 日の 就業時間を 7.5 時間と仮定して、人日単位での作業量を見積もります。

技術的なリスク

作業量の超過、設計の欠陥、多数の不具合、低い品質、低い性能など、 望ましくないことがユースケースに発生する確率を基にして開発チームが設定します。 こうした望ましくないことが発生する原因は、往々にして、 要求事項に対する理解不足、要求の規定のあいまいさ、知識不足、リソース不足、技術面での複雑さ、新しい技術、新しいツール、新しい装置などにあります。

Wylie カレッジのプロジェクトでは、各ユースケースの技術的なリスクが高、中、低に分類されます。

リスクの影響も大きく、リスクの発生する確率も高い。

リスクの影響、リスクの発生する確率のいずれかまたは両方とも低い。

リスクの影響が最小で、かつリスクの発生する確率も低い。

対象となる開発反復

ユースケースが実装される開発反復を記録します。 プロジェクトの作成フェーズの間、 いくつかの開発反復にわたって各リリースの開発が実行されることが予想されます。

プロジェクトの管理者は、各ユースケースに割り当てる反復番号を使用して プロジェクト・チームのアクティビティーを計画します。

値は <letter>-<iteration number> という形式で 表されます。<letter> のところには、I、E、C、T のいずれかが入ります。 それぞれ方向づけ (inception)、推敲 (elaboration)、作成 (construction)、移行 (transition) の意味です。  例えば次のようになります。

 E-1

推敲フェーズ、反復 1 にスケジュールされます。

C-1

作成フェーズ、反復 1 にスケジュールされます。

C-2

作成フェーズ、反復 2 にスケジュールされます。

C-3

作成フェーズ、反復 3 にスケジュールされます。

割り当て

さらに分析、設計、実装を進めるため、個人個人か開発チームかいずれかにユースケースが 割り当てられます。単純なプルダウン・リストを使用することにより、プロジェクト・チームに参加しているだれもが任務をよりよく理解できます。

Rational Rose モデル

ユースケース要求に割り当てられる Rose ユースケース・モデルを識別します。

3.3.2     テスト・ケースの属性

テスト・ステータス

テストの指導者が設定します。 各テスト・ケースの状況が記録されます。

テスト未実施

まだテスト・ケースが実行されていません。

不合格

テストは実行されたが不合格に終わりました。

条件付き合格

テストは完了したが、いくつか問題点が残りました。いくつかアクションが完了した時点で「合格」という状態を割り当てられたテストです。

合格

テストが正常に完了しました。

ビルド番号

特定のテスト・ケースの検証が行われるシステム・ビルドが記録されます。

テスト担当者

テスト・ケースの実行と検証を行うよう任命された担当者のこと。 この簡単なプルダウン・リストにより、プロジェクト・チームのだれもが、責務をより理解することができます。

テスト日

テストの実施予定日または実際の実施日。

テスト・メモ

テストの計画やテストの実行に関連する一切のメモ。

3.4                レポートと測定

TBD (未定)

3.5                要求変更の管理

「Wylie カレッジ構成管理計画書」を参照してください。

3.6               作業分野とタスク

「Wylie カレッジ開発ケース」を参照してください。

4.                  マイルストーン

これについては、個々のプロジェクトの「ソフトウェア開発計画書」の中で述べます。

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

これについては、個々のプロジェクトの「ソフトウェア開発計画書」の中で述べます。