Share via

変更要求 (CMMI)

  • [アーティクル]

このトピックでは、変更要求の作業項目の詳細を設定する方法について学習できます。 チームは、変更要求の作業項目を使用して、製品の一部に対して提案された変更を追跡できます。 変更制御されている作業生産物に対して変更が提案されるたびに、変更要求を作成できます。 詳細については、「変更の管理 (CMMI)」を参照してください。

このタイプの作業項目を作成する方法については、「作業項目とワークフロー (CMMI)」を参照してください。

このトピックの内容

関連トピック

  • 変更要求の定義

  • 変更要求の要件、タスク、またはその他の作業項目へのリンク

  • 変更要求への詳細、添付ファイル、またはハイパーリンクの追加

  • 変更要求の状態の変更

プロセス ガイダンス

ブック

フィールド参照

必要なアクセス許可

変更要求を表示するには、読み取りユーザー グループのメンバーであるか、[このノードの作業項目を表示します] が [許可] に設定されている必要があります。 変更要求を変更するには、貢献者グループのメンバーであるか、[このノードの作業項目を編集します] のアクセス許可が [許可] に設定されている必要があります。 詳細については、「アクセス許可の管理」を参照してください。

変更要求の定義

変更要求の作業項目フォームは、次の図に示すフィールドとタブにデータを保存します。

変更要求の作業項目フォーム

   

CMMI の変更要求作業項目フォーム - タブ

変更要求を定義する場合は、タイトルを定義する必要があります。 他のフィールドは、空白または既定値のままでかまいません。

単一の変更要求を定義するには

  1. 作業項目フォームの最上部のセクションで、次のような情報を 1 つ以上指定します。

    • [タイトル] (必須) に、簡単な説明を入力します。

      適切なタイトルを付けると、影響を受ける製品の領域と、どのような影響を受けるかについて理解しやすくなります。 変更や、影響を受ける可能性がある領域をより正確に定義できるように、必要に応じてテキストを更新できます。

    • [担当者] ボックスで、変更要求を対応するチーム メンバーの名前をクリックします。

      注意

      作業項目は、貢献者グループのメンバーにのみ割り当てることができます。

      変更要求の担当者を割り当てないままにすると、要件を定義するユーザーが自動的に担当者になります。

    • [状態] ボックスでは、既定値である提案済みをそのまま使用します。

      既定では、[理由] フィールドの値は新規です。 このフィールドの詳細とこのフィールドを使用してワークフローを追跡する方法については、このトピックの「変更要求の状態の変更」を参照してください。

    • [区分] および [イテレーション] ボックスで、適切な区分とイテレーションをクリックします。

      注意

      プロジェクト管理者は、区分およびイテレーション ツリー階層を定義することで、チーム メンバーがそれらの指定によって進捗状況を追跡できるようにします。 詳細については、「区分およびイテレーションの作成および修正」を参照してください。

    • [優先順位] ボックスで、変更要求の重要度を 1 (最も重要) ～ 4 (最も重要ではない) の範囲で指定します。

      既定値は 2 です。

    • [トリアージ] ボックスで、トリアージのサブ状態をクリックします。

      このフィールドでは、提案済みの状態にある変更要求に対して決定したトリアージ レベルを指定します。 有効な値は [保留] (既定)、[詳細]、[情報取得済み]、および [トリアージ済み] です。

    • 懸案事項があるため、チームが変更要求を実装できない場合は、[ブロック] ボックスで [はい] をクリックします。

  2. [詳細] タブに、チームが何を変更する必要があるかについての説明をできる限り詳細に入力します。

    開発者による変更要求の実装、およびテスト担当者による変更要求のテストが確実に行われるようにするためには、変更要求についてできる限り詳細な情報を入力する必要があります。 チームはこの情報を使用して、タスクとテスト ケースの作業項目を作成できます。 詳細については、「タスク (CMMI)」および「テスト ケース (アジャイル)」を参照してください。

  3. [根拠] タブで、変更要求に対応することで顧客や製品に反映される値 (価値) についての説明をできる限り詳細に入力します。

  4. [分析] タブで各テキスト ボックスをクリックし、次の領域に対する変更要求の影響について詳しく入力します。

    • アーキテクチャへの影響

    • ユーザー エクスペリエンスへの影響

    • テストへの影響

    • デザインおよび開発への影響

    • 技術発行物への影響

    変更を実装することによって生じるコストに加え、影響を受ける特定の領域を示すことができます。

  5. [その他] タブで、次のような情報を指定します。

    • [最初の見積もり] ボックスに、変更要求の実装にかかると予想される作業時間を数値で入力します。

      注意

      通常、次のフィールドは、最初に変更要求を定義するときではなく開発サイクルの後半で定義します。

    • [統合] ボックスで、開発チームによって変更要求が統合されたビルドの名前または番号をクリックします。

  6. [すべてのリンク] タブで、変更要求を、要件やタスクなどの 1 つ以上の他の作業項目にリンクします。

  7. [添付ファイル] タブでは、実装する変更要求に関する詳細を提供する仕様やイメージなどのファイルを添付できます。

    詳細については、このトピックの次のセクションを参照してください。

    • 変更要求の要件、タスク、またはその他の作業項目へのリンク

    • 変更要求への詳細、添付ファイル、またはハイパーリンクの追加

  8. 保存 [作業項目の保存] をクリックします。

    注意

    変更要求を保存すると、作業項目ツール バーの下のタイトルに識別子が表示されます。

変更要求の要件、タスク、またはその他の作業項目へのリンク

変更要求とその他の作業項目の間に関係を作成することによって、より効果的なプロジェクトの計画、より正確な依存関係の追跡、より明確な階層構造関係の表示、より迅速な関連情報の検索を実行できます。 変更要求の作業項目フォームから、変更要求に自動的にリンクされる作業項目を作成することも、既存の作業項目へのリンクを作成することもできます。

[リンク] タブで、特定の種類の作業項目への特定の種類のリンクを作成できます。 詳細については、「作業項目のリンク (CMMI)」を参照してください。

タスク、バグ、要件、またはその他の作業項目を作成して変更要求にリンクするには

  1. 変更要求の作業項目フォームを開き、[すべてのリンク] タブをクリックして、リンクされた新しい作業項目の追加 ([新規作成]) をクリックします。

    [リンクされた新しい作業項目の追加] ダイアログ ボックスが開きます。

    [リンクされた新しい作業項目の追加] ダイアログ ボックス

  2. [リンクの種類] ボックスで、リンク先の作業項目の種類に基づいて、作成するリンクの種類をクリックします。

    • タスクまたはバグへのリンクを設定するには、[子] リンクを作成します。

    • 要件、リスク、または懸案事項へのリンクを設定するには、[影響元] リンクを作成します。

    • テスト ケースへのリンクを設定するには、[テスト担当者] リンクを作成します。

    • その他の種類の作業項目へのリンクを設定するには、[関連] または追跡する関係を表す別の種類のリンクを作成します。

  3. [作業項目の種類] ボックスで、作成する作業項目の種類をクリックします。

  4. [タイトル] に、提案される変更要求の説明を具体的かつ簡潔に入力します。

  5. (省略可能) [コメント] に、追加情報を入力します。

  6. [OK] をクリックします。

    指定した作業項目の種類の作業項目フォームが開き、入力した情報が表示されます。

  7. 次のトピックの説明を参照して、残りのフィールドを設定します。

  8. 保存 [作業項目の保存] をクリックします。

複数の既存の作業項目を変更要求にリンクするには

  1. 変更要求の作業項目フォームを開き、[すべてのリンク] タブをクリックして、リンクの追加 ([リンク先]) をクリックします。

    [変更要求へのリンクの追加] ダイアログ ボックスが表示されます。

    [要件へのリンクの追加] ダイアログ ボックス

  2. [リンクの種類] ボックスで、リンク先の作業項目の種類に基づいて、作成するリンクの種類をクリックします。

    • タスクまたはバグへのリンクを設定するには、[子] リンクを作成します。

    • 要件、リスク、または懸案事項へのリンクを設定するには、[影響元] リンクを作成します。

    • テスト ケースへのリンクを設定するには、[テスト担当者] リンクを作成します。

    • その他の種類の作業項目へのリンクを設定するには、[関連] または追跡する関係を表す別の種類のリンクを作成します。

  3. 次のどれかの操作を実行します。

    • [作業項目 ID] に、検索する作業項目の ID を入力します。 複数の ID を指定するときは、コンマまたは空白で区切ります。

    • 一覧から作業項目を指定するには [参照] をクリックします。

      [リンクされた作業項目の選択] ダイアログ ボックスが表示されます。

      [リンクされた作業項目の選択] ダイアログ ボックス

      [保存されたクエリ] ボックスで、追加する作業項目を含むクエリをクリックします。 たとえば、[作業項目を開く]、[アクティブなバグ]、または [アクティブなタスク] をクリックできます。

      [検索] をクリックし、変更要求にリンクする作業項目の横にあるチェック ボックスをオンにして、[OK] をクリックします。

    • (省略可能) リンクする項目の説明を入力します。

  4. [OK] をクリックします。

    詳細については、「リンクまたはインポートする作業項目の検索」を参照してください。

  5. 保存 [作業項目の保存] をクリックします。

    注意

    リンクした変更要求と作業項目の両方が更新されます。

変更要求への詳細、添付ファイル、またはハイパーリンクの追加

詳細情報を入手した段階で、次の方法で変更要求に情報を追加できます。

  • [詳細]、[根拠]、または [分析] タブのテキスト ボックスに情報を入力します。

  • ファイルを添付します。

    たとえば、電子メールのスレッド、文書、イメージ、ログ ファイルなどのさまざまな種類のファイルを添付できます。

  • サーバーまたは Web サイト上に保存されている Web サイトまたはファイルへのハイパーリンクを追加します。

変更要求に詳細を追加するには

  1. [詳細]、[根拠]、または [分析] タブをクリックし、ボックスに情報を入力します。

    情報の書式を設定すると、強調文字や箇条書きリストを使用できます。

    注意

    チーム メンバーが作業項目を更新するたびに、履歴には変更日、変更を行ったチーム メンバーの名前、および変更されたフィールドが表示されます。

    詳細については、「変更要求フィールド (CMMI)」および「タイトル、ID、説明、および履歴 (CMMI)」を参照してください。

  2. 保存 [作業項目の保存] をクリックします。

添付ファイルを変更要求に追加するには

  1. [添付ファイル] タブで、次のいずれかの操作を行います。

    • ファイルを添付ファイル領域にドラッグします。

    • 貼り付け をクリックするか、Ctrl キーを押しながら V キーを押して、コピーしたファイルを貼り付けます。

    • 添付ファイルの追加 [追加]、[参照] をクリックし、[添付ファイル] ダイアログ ボックスに、添付するファイルの名前を入力するか、参照します。

      (省略可能) [コメント] ボックスには、添付ファイルに関する追加情報を入力します。 [添付ファイル] ダイアログ ボックスを閉じるには、[OK] をクリックします。

  2. 保存 [作業項目の保存] をクリックします。

変更要求にハイパーリンクを追加するには

  1. [すべてのリンク] タブで、リンクの追加 ([リンク先]) をクリックします。

    ハイパーリンク アドレスの URL の指定

  2. [リンクの種類] ボックスで、[ハイパーリンク] をクリックします。

  3. [アドレス] ボックスで、次のいずれかの操作を行います。

    • リンク先が Web サイトである場合は、[アドレス] ボックスに URL を入力するか、インターネット ブラウザーから URL をコピーして貼り付けます。

    • リンク先がサーバーの場所である場合は、UNC アドレスを入力します。

  4. (省略可能) [コメント] ボックスには、ハイパーリンクに関する追加情報を入力します。

  5. [OK] をクリックします。

  6. 保存 [作業項目の保存] をクリックします。

変更要求の状態の変更

トリアージ チームまたは製品計画会議では、これらの作業項目を確認して、提案された変更を分析、承認、または却下します。 変更要求が承認された場合、チームはタスクを生成して変更を実装します。 チームが変更を実装すると、チームは最終的に変更要求を終了します。

作業項目の状態を追跡するために使用できるデータ フィールドの詳細については、「割り当て、ワークフロー、および計画 (CMMI)」を参照してください。

次の状態を使用して、変更要求の進行状況を追跡できます。

  • 提案済み

  • アクティブ

  • 解決済み

  • 終了

変更要求の状態はどのチーム メンバーでも変更できます。

既定では、作業項目を作成したときの変更要求の状態は、提案済みです。 チームは、現在のイテレーションの変更要求を受け入れると、作業項目をアクティブの状態にし、変更要求を分析し、実装に関する詳細を確認して、タスクを作成します。 タスクが完了し、システム テストによって変更要求が正常に実装されたことが確認されたら、変更要求を解決済みの状態にします。 最後に、変更要求の検証が完了したら、チーム メンバーは変更要求を終了の状態にします。

変更要求の状態を変更するには

  1. 変更要求を開きます。

  2. [状態] ボックスで、[アクティブ]、[解決済み]、または [終了] をクリックします。

    • 状態を提案済みからアクティブに変更すると、[理由] フィールドが自動的に [承諾済み] に変わります。

    • 状態をアクティブから解決済みに変更すると、[理由] フィールドが自動的にコードの完了およびシステム テストの成功に変わります。

    • 状態を解決済みから終了に変更すると、[理由] フィールドが自動的に [妥当性確認テストに成功] に変わります。

  3. 保存 [作業項目の保存] をクリックします。

通常のワークフローの流れ:

  • チーム メンバーが、既定の理由である [新規] を指定して、既定の状態である提案済みの変更要求を作成する。

  • チーム メンバーが、既定の理由である [承諾済み] を指定して、変更要求の状態を提案済みからアクティブに変更する。

  • 要件のコードが完成し、システム テストに合格した時点で、チーム メンバーが変更要求の状態をアクティブから解決済みに変更する。

  • 変更要求が顧客の要求を満たしていることが検証された時点で、チーム メンバーが変更要求の状態を解決済みから終了に変更する。

例外的な遷移:

  • チーム メンバーが、既定の理由である [却下] を指定して、変更要求の状態を提案済みから終了に変更する。

  • チーム メンバーが、既定の理由である [調査完了] を指定して、変更要求の状態をアクティブから提案済みに変更する。

  • チーム メンバーが、変更要求がスコープ外または無関係であると判断して、変更要求の状態をアクティブから終了に変更する。

  • 変更されたコードが妥当性確認テストで不合格になった時点で、チーム メンバーが変更要求の状態を解決済みからアクティブに変更する。

  • チーム メンバーが、作業項目が誤って終了したか、スコープ内にあると判断して、変更要求の状態を終了からアクティブに変更する。

変更要求の状態の図

変更要求のワークフロー

提案済み (新規)

チーム メンバーは、チームがバグを検出した場合、または別のイベントによって、変更制御されている作業生産物に対して変更が必要であると判断された場合、変更要求の作業項目を作成できます。

チーム メンバーが変更要求を作成すると、次のデータ フィールドが自動的にキャプチャされます。

  • [作成者]: 変更要求を作成したチーム メンバーの名前。

  • [作成日]: 変更要求が作成された日時 (サーバー クロックで記録された日時)。

提案済みからアクティブへ

変更要求には、製品またはベースラインへの変更が記述されます。 変更制御委員会は、チームが提案する各変更を調査して、変更を承認、または却下します。

チーム メンバーは、次の表に示す理由によって、変更要求の状態を提案済みからアクティブに変更できます。

理由

使用する状況

追加で行う操作

承諾済み

変更制御委員会が、現在のイテレーションにおける実装の変更要求を承諾したとき。

実装を担当するチーム メンバーに変更要求を割り当てます。

調査

変更制御委員会が要求を承認する前に、要求による影響を調査する必要があると判断したとき。

調査が完了した時点で、変更要求の状態を提案済みに戻します。

チーム メンバーが変更要求の状態をアクティブに変更すると、次のデータ フィールドが自動的にキャプチャされます。

  • [アクティブ化した人]: 変更要求をアクティブ化したチーム メンバーの名前。

  • [アクティブ化された日]: 変更要求がアクティブ化された日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

提案済みから終了へ

チーム メンバーは、次の表に示す理由によって、提案済みの状態の変更要求を終了できます。

理由

使用する状況

追加で行う操作

Rejected (却下)

変更制御委員会が、チームが要求を実装できない、または顧客が要求を必要としなくなったと判断したとき。

なし。

チーム メンバーが変更要求を終了すると、次のデータ フィールドがキャプチャされます。

  • [終了者]: 変更要求を終了したチーム メンバーの名前。

  • [終了日]: 変更要求が終了した日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

アクティブ

チームは、アクティブ状態の変更要求のみを実装する必要があります。 アクティブな変更要求に対し、チーム メンバーはコードの記述、テスト、および文書化を行うためのタスクを作成する必要があります。 すべてのタスクが完了すると、チーム メンバーが変更要求の状態を解決済みにします。 変更要求が破棄された場合、またはスコープ外にされた場合も、チーム メンバーは変更要求を終了できます。

アクティブから解決済みへ

チーム メンバーは、次の表に示す理由によって、アクティブな変更要求を解決できます。

理由

使用する状況

追加で行う操作

コードの完了およびシステム テストの終了

変更要求を実装するためのコードがチェックインされ、すべてのシステム テストに合格したとき。

テストを担当するチーム メンバーに変更要求を割り当てます。

チーム メンバーがアクティブな変更要求を解決すると、次のデータ フィールドが自動的にキャプチャされます。

  • [解決者]: 変更要求を解決したチーム メンバーの名前。

  • [解決日]: 変更要求が解決された日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

アクティブから終了へ

チーム メンバーは、次の表に示す理由によって、アクティブな変更要求を終了できます。

理由

使用する状況

追加で行う操作

破棄

変更要求を実装する必要がなくなったとき。

なし。

スコープの外

現在のイテレーションの変更要求を実装するためのリソースが不十分であるか、進行をブロックする別の懸案事項が見つかったとき。

[イテレーション] フィールドを更新して、チームが変更要求を実装する可能性があるイテレーションを指定します。 変更要求がソフトウェアの次回リリースまで延期される場合、[イテレーション] フィールドは空白のままにし、延期された理由、および実装する必要がある時期について詳しく記述します。

チーム メンバーがアクティブな変更要求を終了すると、次のデータ フィールドが自動的にキャプチャされます。

  • [終了者]: 変更要求を終了したチーム メンバーの名前。

  • [終了日]: 変更要求が終了した日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

アクティブから提案済みへ

変更要求が調査としてアクティブ化された場合は、チームが調査を完了した後で状態を提案済みに変更します。 アクティブな変更要求の状態を提案済みに変更すると、次のデータ フィールドが自動的にキャプチャされます。

  • [変更者]: 変更要求の状態を変更したチーム メンバーの名前。

  • [状態の変更日]: 変更要求の状態が変更された日時。

解決済み

チームが変更要求を実装すると、リード開発者が状態を解決済みに設定し、テストを開始できるようにテスト担当者に変更要求を割り当てます。

解決済みの変更要求は実装済みであり、システム テストに合格します。 ただし、顧客の要求に応じて変更要求が実装されたかどうかを確認するため、チームは、解決済みの変更要求を顧客と共に検証する必要があります。 妥当性確認テストに合格すると、チームは変更要求を終了します。 合格しなかった場合は、さらに作業を行うために再アクティブ化します。

解決済みから終了へ

チーム メンバーは、次の表に示す理由によって、解決済みの変更要求を終了できます。

理由

使用する状況

追加で行う操作

妥当性確認テストに成功

変更要求がすべての妥当性確認テストに合格したとき。

変更要求を製品所有者に割り当てます。

チーム メンバーが解決済みの変更要求を終了すると、次のデータ フィールドが自動的にキャプチャされます。

  • [終了者]: 変更要求を終了したチーム メンバーの名前。

  • [終了日]: 変更要求が終了した日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

解決済みからアクティブへ

チーム メンバーは、次の表に示す理由によって、解決済みの変更要求を再アクティブ化できます。

理由

使用する状況

追加で行う操作

妥当性確認テストに失敗

妥当性確認テストで要件が顧客の要求を 1 つ以上満たしていないことが示されたとき。

テスト担当者は、テストの失敗に対するバグを作成し、懸案事項への対処方法を決定するリード開発者に変更要求を割り当てます。

チーム メンバーが解決済みの変更要求を再アクティブ化すると、次のデータが自動的にキャプチャされます。

  • [アクティブ化した人]: 変更要求を再アクティブ化したチーム メンバーの名前。

  • [アクティブ化された日]: 変更要求が再アクティブ化された日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

終了

チームは、終了済みの変更要求に対して作業を行うことができません。 変更要求は、変更制御委員会が変更要求を却下した場合、またはチームが要求を正常に実装、検証、妥当性を確認した場合に終了になります。

チーム メンバー (通常はビジネス アナリストまたはプログラム マネージャー) は、終了したリスクがスコープに戻った場合、その変更要求を再アクティブ化できます。

終了からアクティブへ

チーム メンバーは、次の表に示す理由によって、終了した変更要求を再アクティブ化できます。

理由

使用する状況

追加で行う操作

エラーによる終了

チーム メンバーが誤って変更要求を終了したとき。

実装タスク、テスト ケース、および変更要求の詳細の定義が適切であり、開発をサポートするのに十分であることを確認します。

  • チーム メンバーが終了済みの変更要求を再アクティブ化すると、次のデータが自動的にキャプチャされます。

  • [アクティブ化した人]: 変更要求を再アクティブ化したチーム メンバーの名前。

  • [アクティブ化された日]: 変更要求が再アクティブ化された日時 (サーバー クロックで記録された日時)。

  • [状態の変更日]: 変更要求の状態が変更された日時。

参照

その他の技術情報

変更要求フィールド (CMMI)

作業項目とワークフロー (CMMI)