トピック

そのほかの計画との関係 ページの先頭へ

要求管理計画書には、程度の違いこそあれ、ほかの計画書で言及されている場合がある情報が含まれます。

組織、責務、インターフェイス ページの先頭へ

../../papers/apprmuc.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんホワイト ペーパー: ユース ケースを使用した要求管理の適用」に記述されているように、要求管理はプロジェクトの成功を確実にするために重要です。  プロジェクト失敗の原因として最も多く引用されるものには、次のものがあります。

  • ユーザー インプットの欠如
  • 不完全な要求
  • 要求の変更

要求のエラーは最も一般的なエラーにもなることが多く、修正にも最もコストがかかります。

利害関係者と正しい関係を持つことは、これらの問題への対処に役立ちます。利害関係者は、要求の定義や要求の優先順位付けの理解に対して重要な意見を提供してくれます。ただし、利害関係者は、要求した機能によるコストやスケジュールへの影響に対する配慮に欠けていることが多く、したがって開発組織は利害関係者の期待を統制する必要があります。  

利害関係者との関係を築くには、次のことを定義します。

  • 利害関係者の責務: コンサルティングのためにスタッフを現場に用意できるか。その時間を事前に指定できるか。
  • 利害関係者のプロジェクト成果物への可視性: すべての成果物に対してオープンな可視性を許可するか。予定したマイルストーンに対してのみに可視性を制限するか。

追跡対象の要素の識別 ページの先頭へ

追跡可能性アイテムについて説明し、それらを命名する方法、マーク付けする方法、および番号付けする方法を定義します。 「Concepts: Requirement Types」および「概念: 追跡可能性」を参照してください。

追跡可能性の指定 ページの先頭へ

追跡可能性のリンクを識別することに加え、リンクの濃度を指定することも必要です。一般的な制約には次のものがあります。

  • 承認された各機能は、1 つまたは複数の補足要求、または 1 つまたは複数のユース ケース、あるいはこの両方に対してリンクしていなければなりません。
  • 各補足要求と各ユース ケース セクションは 1 つまたは複数のテスト ケースにリンクしていなければなりません

追跡可能性についての詳細は、ホワイト ペーパー「../../papers/traceability.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんTraceability Strategies for Managing Requirements With Use Case」に記載されています。

属性の例 ページの先頭へ

以下に、必要に応じて

利害関係者のニーズページの先頭へ

ソース: 要求を出す利害関係者 (これは、追跡可能性として「利害関係者」追跡対象の要素に実装されることもあります)。

貢献: ビジネスの機会全般や、プロジェクトで対処される問題への問題の貢献を示します。パーセント (0 ~ 100%)。すべての貢献は、合計が 100% 以下でなければなりません。次に示す例「../workguid/wg_paret.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんパレート図」は、複数の利害関係者のニーズそれぞれに対する貢献を示しています。

5 つの問題がビジネス上の機会全体に与える相対的な影響を示すグラフ

機能、補足要求、ユース ケースページの先頭へ

ステータス: 要求がレビューされたかどうか、"公式の認定者"によって許可されたかどうかを示します。この値の例には、提案済み、却下済み、承認済みなどがあります。

これは、契約上のステータス、つまり拘束力のある決定を行う資格のある作業グループが設定したステータスになることがあります。

利点: 利害関係者の視点から見た重要度。

  • 最重要 (または主要): これらは、常に、システムの主なタスク、その基本機能、システムの開発目的である機能に関係しています。これらが欠如すると、システムは第一の使命を果たすことができません。これらは、アーキテクチャ設計を決定するもので、最も頻繁に用いられるユース ケースである傾向があります。
  • 重要 (または二次的): これらは、常に、統計的データのコンパイル、レポートの生成、監督、機能テストなどの、システムの機能のサポートに関係しています。これらが欠如していても、システムは依然として (しばらくの間) 基本的使命を果たしますが、サービスの質が低下します。モデリングでは、最重要ユース ケースよりも低い重要性がこれらに与えられます。
  • 便利 (あるとよい): これらはいわゆる"快適"機能で、システムの主要な使命には関連しませんが、使用や市場での位置付けにおいて有効です。

作業: 要求の実装にかかると予想される作業日数

たとえば、これは低、中、高のようなカテゴリに設定し、低 = 1 日未満、中 = 1 ~ 20 日、高 = 20 日以上のように設定します。<>

作業を定義する場合は、どのオーバーヘッドを見積もりに含めるのか (管理作用、テスト作用、要求作業など) を明確に示す必要があります。

サイズ: テスト コードを除いた、予想されるコメント以外のコードのソース行 (SLOC)

より正確なコスト見積もりのために、新規 SLOC と再利用される SLOC を区別することもできます。

リスク: 要求の実装において生じる可能性のある、重大な望ましくないイベントの発生可能性をパーセントで示したもの (コストの超過やキャンセルなど)

たとえば、これは低、中、高のようなカテゴリーに設定し、低 = 10% 未満、中 = 10~50%、高 = 50% 超のように設定します。

リスクについての別のオプションとして、技術リスクを別に追跡することがあります。これは、そのドメインにおける経験不足や必要な技術の欠如などによって要求の実装が極めて難しくなる可能性をパーセントで示したものです。したがって、全体のリスクは、ほかの属性 (サイズ、作業、安定性、技術リスク、アーキテクチャ上の影響、組織的な複雑さなど) に基づいて重み付けされた合計として算出されます。   

組織的な複雑さ: 要求を開発する組織に対する制御の分類

  • 内部: 社内の 1 箇所における開発
  • 地理的: 地理的に分散されたチーム
  • 外部: 会社内の外部組織  
  • ベンダー 外部で開発されるソフトウェアの契約または購入

アーキテクチャ上の影響: この要求によってソフトウェア アーキテクチャが受ける影響の大きさを示す

  • なし: 既存のアーキテクチャへの影響はない
  • 拡張: 既存のアーキテクチャの拡張が必要
  • 修正: 要求を受け入れるために既存のアーキテクチャの修正が必要   

安定性: この要求が変更される、または開発チームの要求に対する理解が変更する可能性 (50% 超 = 高、10 ~ 50% = 中、10% 未満 = 低など) ><

目標リリース 要求を満たすように意図された製品リリース (リリース 1、リリース 1.1、リリース 2、など)

危険レベル / 重大度: 健康、福利または経済的な結果に影響を与える可能性。一般的には、ソフトウェアの欠陥や予想外の動作によって発生する。

  • 無視してよい: 重大な人的危害や機械へのダメージにはつながらない
  • 重要でない: 人的危害やシステムのダメージなしで制御できる
  • 重大: 人的危害やシステムのダメージにつながる可能性があるか、人的またはシステムへの損害を防ぐために迅速な修正作業が必要とされる
  • 破局的: 重大な怪我や死亡、または完全なシステム損失につながる可能性がある

危険度は、別個の要求タイプとして認識されることもあり、関連するユース ケースにリンクされます。また、危険度の可能性、修正作業、または回避措置を追跡することもできます。 

解釈: 要求が正式な契約として形成されるような場合は、要求の言葉を変えるのが難しく、またコストがかかることがあります。開発組織による要求の理解度が深まるにつれ、要求の正式な言葉を変えるだけでなく、その解釈を示すテキストを添付する必要があるでしょう。 

ユース ケースページの先頭へ

上記に加え、次のユース ケース属性を追跡することも役に立ちます。

% 詳細: ユース ケースが推敲された度合い

  • 10%: 基本的な説明が提供された。
  • 50%: 主な流れが文書化された。
  • 80%: 記述は完了したがレビューが済んでいない。事前条件や事後条件がすべて十分に指定されている。
  • 100%: レビューが完了して承認された。

テスト ケースページの先頭へ

ステータス: テキスト開発の間での進捗の追跡

  • 作業なし: このテスト ケースの開発中に達成された作業はない
  • マニュアル: マニュアル スクリプトが作成され、関連する要求を検証できるものとして承認された
  • 自動: 自動スクリプトが作成され、関連する要求を検証できるものとして承認された

一般的な属性ページの先頭へ

一般的に適用できるその他の要求属性には次のものがあります。

  • 計画反復
  • 実際反復
  • 責任当事者

属性の選択 先頭のページへ

属性は、通常、ステータスやレポート作成を目的として追跡対象の要素に関連付けられた情報を追跡する場合に使用します。各組織は、組織独自の特性の追跡情報を必要とすることがあります。属性を割り当てる前に、次のことを考慮してください。  

  • この情報を誰が提供するのか
  • この情報を誰が使用するのか、またなぜこの情報が有用なのか
  • この情報の追跡にかかるコストは、その利益に見合っているか

範囲管理のために要求を優先順位付けしたり、要求を反復に割り当てたりするためには、リスク、利点、作業、安定性アーキテクチャ上の影響の各属性を追跡する必要があります。これらの属性は、まず機能に、その後すべてのユース ケースと補足要求に追跡します。

引き出される情報の考慮

直接要求属性を使うだけでなく、別の要求タイプへの追跡可能性によってこれらの要求属性から情報を引き出すこともできます。導出の一般的なパターンには次のものがあります。

  • 下方向に導出 - 上記の追跡可能性で、製品機能に属性"目標リリース"があるとします。この場合、この製品機能によって追跡された各ユース ケースは、指定された目標リ リースにおいて、またはそれ以前にも利用可能であると見なすことができます。
  • 上方向に導出 - 上記の追跡可能性で、ユース・ケース・セクションに属性「予測される作業」があるとします。製品機能のコストは、追跡するユース・ケース・セクションのために予測される作業を合計することによって見積もることができます。複数の製品機能が同じユース・ケース・セクションにマップしている場合もあるため、この方法は注意して使用してください。

したがって、要求属性を要求タイプに割り当てるには、次のことを考慮する必要があります。

  • この属性から引き出したい情報は何か。また、どのようなレポートを作成したいか。
  • 追跡可能性の階層におけるどのレベルで、この属性を追跡するか。

属性の依存性

属性のなかには、開発の特定のレベルでしか適用できないものがあります。たとえば、ユース ケースの「予測される作業」属性は、そのユース ケースが完全に設計に表現されると、設計要素の作業見積もりによって置換されることがあります。

レポートと測定 ページの先頭へ

以下は、要求関連のレポートと測定の例です。プロジェクトに関する必要なレポートと測定のセットを選択すると、要求管理計画書の必要な属性を引き出すことができます。

レポート / 促成の説明 使用対象
ユース ケースの開発優先順位 (リスク、利点、作業、安定性、アーキテクチャ上の影響ごとにソートされたユース ケースのリスト) これは、別々にソートされた複数のリストであることも、これらの属性の重み付けされた組み合わせによってソートされた単一のリストであることもあります。「作業: ユース ケースの優先順位付け」も参照してください。
各ステータス カテゴリの機能のパーセント プロジェクト ベースラインの定義中に進捗を追跡します。
 - 目標リリースによる分類  - リリースごとの進捗の追跡
 - 作業による重み付け  - より正確な進捗の測定を提供
リスクでソートされた機能 - リスクを伴う機能の割り出し。範囲管理、機能の反復への割り当てに役立ちます。
 - 目標リリースによる分類、各目標リリースについて開発リスクを合計  - リスク機能がプロジェクトの早期または後期のいずれにおいてスケジュールされたのかを評価するのに役立ちます。
安定性によってソートされたユース ケース セクション  安定させる必要のあるユース ケース セクションの決定
 - 影響する成果物によって重み付けまたはソートされる  - アーキテクチャ上重要なユース ケースや作業量の多いユース ケースから順に安定化されるように優先順位付けするのに役立ちます。
属性が定義されていない要求 最初に要求が提案されたとき、必ずしもすべての属性を即座に割り当てるわけではありません (たとえばデフォルトの "未定義" 値を使用するなど)。 「チェックポイント: ソフトウェア要求仕様」では、このレポートを使ってこのような未定義の属性をチェックします。
追跡可能性リンクが不完全な追跡対象の要素 不正確または不完全な追跡可能性リンクのレポートは、チェックポイント: ソフトウェア要求仕様で使用されます。

要求変更の管理 ページの先頭へ

変更は避けられないものであるため、それに備えておく必要があります。変更が起きる理由として、次のものがあります。

  • 解決する必要のある問題に変更があった。これは、新しい規則や経済的な圧力、技術革新などによります。
  • 利害関係者が、システムに実行してほしいと思うことに対する考えや理解を変えた。これにはさまざまな理由が考えられますが、たとえば責任者が変わったり、問題の理解度が深まったりすることがあります。
  • 最初の要求を定義したときに、すべての利害関係者を参加させることができなかった、あるいは正しい質問すべてを尋ねることができなかった。

変化する要求を管理するための戦略として、次のものがあります。

  • 要求をベースライン化する
  • 変更を管理するための単一のチャネルを確立する
  • 変更履歴の維持

要求をベースライン化するページの先頭へ

推敲フェーズが終わりに近づくにつれ、システム分析者は既知の要求すべてをベースライン化します。これは通常、要求成果物がバージョン管理されていることを確認し、ベースラインを形成する成果物のセットとそのバージョンを識別することによって行います。

ベースラインの目的は、要求を凍結することではありません。そうではなく、新しい要求や修正された要求を識別し、コミュニケートし、見積もったり管理したりできるようにすることです。

変更を管理するための単一のチャネルを確立するページの先頭へ

利害関係者による変更の希望は、予算やスケジュールを正式に変更するものとは見られません。通常、変更が承認される前に交渉や予算の調整を行う必要があります。多くの場合、変更は互いにバランスがとれている必要があります。

すべての変更が 1 つのチャネル、すなわち変更管理委員会 (CCB) を通過するようにして、変更によるシステムへの影響を判断したり、変更について正式に承認を得たりすることが重要です。変更の提案のためのこのメカニズムでは、変更依頼を、提出します。提出されたものは変更管理委員会によりレビューされます。

変更履歴の維持ページの先頭へ

個々の要求への変更の監査記録を保持しておくと役に立ちます。この変更履歴により、要求に対するこれまでの全変更や属性値への変更、変更の根本的理由を見ることができます。これは、要求の実際の安定性を評価したり、変更管理プロセスが稼動していないケースを識別したりするのに役立ちます (たとえば、適切なレビューや承認を受けていない要求変更を識別するなど)。



Rational Unified Process   2003.06.15