要件 (CMMI)
このトピックでは、要件の作業項目の詳細を設定する方法を学習できます。要件は、製品またはシステムの顧客にとって価値のある機能を表すものです。各要件は、ユーザーが求めるソフトウェアの機能を、ユーザーの視点に立って簡単に説明している必要があります。詳細については、「プロジェクトの計画 (CMMI)」を参照してください。
このタイプの作業項目を作成する方法については、「作業項目とワークフロー (CMMI)」を参照してください。
このトピックの内容 |
関連トピック |
---|---|
|
プロセス ガイダンス ブック ダッシュボードとレポート フィールド参照 |
必要なアクセス許可
要件を表示するには、読み取りユーザー グループのメンバーであるか、または [このノードの作業項目を表示します] が [許可] に設定されている必要があります。要件を作成または変更するには、貢献者グループのメンバーであるか、または [このノードの作業項目を編集します] のアクセス許可が [許可] に設定されている必要があります。詳細については、「アクセス許可の管理」を参照してください。
要件の定義
要件を記述する際、機能がだれを対象としているのか、および機能の対象者がその機能で何をどのような理由で達成したいのかに焦点を当てる必要があります。機能の開発方法を示すような記述は行わないでください。
要件を作成する際は、タイトルのみを指定する必要があります。ただし、次の図に示されているように、その他のさまざまな情報を指定して要件をさらに詳しく定義することができます。
要件を定義する場合は、タイトルを定義する必要があります。他のフィールドは、空白または既定値のままでかまいません。
要件を定義するには
[タイトル] (必須) に、簡単な説明を入力します。
要件のタイトルは、顧客にとって価値のある、またはチームで実装する必要がある機能を反映したタイトルにします。
作業項目フォームの右のセクションで、次のような情報を一つ以上指定します。:
担当者 の一覧で、要件を担当するチーム メンバーの名前を選択します。
[!メモ]
作業項目は、貢献者グループのメンバーにのみ割り当てることができます。
要件の担当者を割り当てないままにすると、要件を定義するユーザーが自動的に担当者になります。
[状態] ボックスでは、既定値である提案済みをそのまま使用します。[理由] ボックスでは、既定値である新規をそのまま使用します。
[状態] フィールドおよびこのフィールドを使用してワークフローを追跡する方法の詳細については、このトピックの「要件の状態の変更」を参照してください。
優先度 の一覧で、4 ~ 1 の範囲で要件の重要度を (最も重要) を選択します (最も重要)。
トリアージ の一覧で、トリアージのサブ状態を選択します。
有効な値は [保留] (既定)、[詳細]、[情報取得済み]、および [トリアージ済み] です。このフィールドでは、提案済み状態にある要件のトリアージ レベルを指定します。
ブロック の一覧で、問題が要件の実装に向けた作業の進行がブロック あり を選択します。
コミット済み の一覧で、要件を実装するコミットが行われ あり を選択します。
区分 と イテレーション の一覧で、適切な区分とイテレーションをクリックします。
[!メモ]
各チーム プロジェクトのプロジェクト管理者は、プロジェクトの区分とイテレーション パスを定義することで、チームがその指定によって進行状況を追跡できるようにします。詳細については、「区分およびイテレーションの作成および修正」を参照してください。
種類で、定義する要件の種類を選択します。
既定値は 機能性です。
DESCRIPTION のタブで、満たされているかどうかを検証するためにチームが使用する基準と条件を記述します。
開発者による要件の実装、およびテスト担当者による要件のテストが確実に行われるようにするためには、できるだけ詳細な情報を入力する必要があります。
チームはこの情報を使用して、タスクとテスト ケースの作業項目を作成します。詳細については、「タスク (アジャイル)」および「テスト ケース (アジャイル)」を参照してください。
ANALYSIS のタブで、要件が実装されない場合についてユーザーに影響します。
この要件が Surprise カテゴリ、Required カテゴリ、または Obvious カテゴリにあるかどうかについて、Kano モデル上に詳細を含めることができます。
そのほか のタブで、次の情報を指定する:
領域の専門家の下で、顧客はこの要件にある問題領域で予測を理解している最大 3 人のチーム メンバーの名前を選択します。
[最初の見積もり] ボックスに、要件の実装にかかると予想される作業時間を表す数値を入力します。
[!メモ]
通常は、次の 2 つのフィールドは、最初に要件を定義するときではなく開発サイクルの後半で定義します。
統合 の一覧で、開発チームが要件を統合したビルドの名前または番号を選択します。
テスト の一覧で、この要件のユーザー受け入れテストの状態を選択します。
有効な値は [成功]、[失敗]、[準備不完了]、[準備完了]、または [省略] です。[準備不完了] は要件の状態がアクティブのときに指定し、[準備完了] は要件の状態が解決済みの場合に指定する必要があります。
[実装]、[変更要求]、[テスト ケース]、および [すべてのリンク] の各タブでは、要件からタスク、変更要求、テスト ケース、バグ、懸案事項などの他の作業項目へのリンクを作成できます。
[添付ファイル] タブでは、実装する要件に関する詳細を提供する仕様やイメージなどのファイルを添付できます。
詳細については、このトピックの次のセクションを参照してください。
要件からその他の作業項目へのリンクの設定
要件への詳細、添付ファイル、またはハイパーリンクの追加
作業項目の保存を選択 します。
[!メモ]
要件を保存すると、作業項目ツール バーの下のタイトルに識別子が表示されます。
要件からその他の作業項目へのリンクの設定
要件とその他の作業項目の間に関係を作成することにより、より効果的なプロジェクトの計画、より正確な依存関係の追跡、より明確な階層構造関係の表示、およびより迅速な関連情報の検索を実行できます。要件の作業項目フォームから、要件に自動的にリンクされる作業項目を作成することも、既存の作業項目へのリンクを作成することもできます。
特定の種類の作業項目への特定の種類のリンクを作成するには、[実装]、[変更要求]、[テスト ケース]、および [すべてのリンク] の各タブを使用します。各タブの制限事項の詳細については、「Linking Work Items (CMMI)」を参照してください。
[!メモ]
必要条件の概要レポートおよび必要条件の進行状況レポートについては、要件とタスクの間、および要件とテスト ケースの間にリンクが作成されている必要があります。
タスク、バグ、変更要求、テスト ケース、またはその他の作業項目を作成して要件にリンクするには
要件の作業項目フォームを開き、次のいずれかの操作を行います。
タスク、バグを作成してリンクは、またはサブ要件は、実装 のタブをクリックし、新規作成を 選択します。
変更要求に作成し、リンクするには、変更要求 のタブをクリックし、新規作成を選択 します。
テスト ケースを作成し、リンクするには、テスト ケース のタブをクリックし、新規作成を選択 します。
そのほかの種類の作業項目を作成し、リンクするには、すべてのリンク のタブをクリックし、新規作成を選択 します。
[リンクされた新しい作業項目の追加] ダイアログ ボックスが開きます。
リンクの種類 の一覧で、既定値をそのまま使用するか、次の選択項目の 1 つがを選択する:
タスクにリンクするには、バグ、またはサブ要件は、子を選択します。
変更要求にリンクするには、影響元を選択します。
テスト ケースにリンクするには、テスト担当者を選択します。
そのほかの種類の作業項目にリンクするには、リンクの 関連 または追跡する関係を表す別の種類を選択します。
作業項目の種類 の一覧で、作成する作業項目の種類を選択します。
[タイトル] で、実行される作業の説明を具体的かつ簡潔に入力します。
(省略可能) コメントで、追加情報を入力し、OKを選択します。
指定した作業項目の種類の作業項目フォームが開き、入力した情報が表示されます。
次のトピックで説明されているように、残りのフィールドを指定します。
作業項目の保存を選択 します。
複数の既存の作業項目を要件にリンクするには
要件の作業項目フォームを開き、次のいずれかの操作を行います。
一つ以上のタスク、バグにリンクするには、またはサブ要件は、実装 のタブをクリックし、リンク先を選択します。
一つ以上の変更要求にリンクするには、変更要求 のタブをクリックし、リンク先を選択 します。
一つ以上のテスト ケースにリンクするには、テスト ケース のタブをクリックし、リンク先を選択 します。
他の型の一つ以上の作業項目にリンクするには、すべてのリンク のタブをクリックし、リンク先を選択 します。
[要件へのリンクの追加] ダイアログ ボックスが表示されます。
リンクの種類 の一覧で、既定値をそのまま使用するか、次の選択項目の 1 つがを選択する:
タスクにリンクするには、バグ、またはサブ要件は、子 か 親を選択します。
変更要求にリンクするには、影響元を選択します。
テスト ケースにリンクするには、テスト担当者を選択します。
そのほかの種類の作業項目にリンクするには、リンクの 関連 または追跡する関係を表す別の種類を選択します。
[参照] をクリックします。
[リンクされた作業項目の選択] ダイアログ ボックスが表示されます。
[作業項目 ID] に作業項目の ID を入力するか、リンクする作業項目を参照します。
チーム クエリを実行して、リンクする作業項目を検索することもできます。これらのクエリには、[アクティブなバグ]、[変更要求]、[タスクを開く]、[テスト ケースを開く]、および [タスクを開く] があります。
要件にリンクする各作業項目の横にあるチェック ボックスをオンにします。
詳細については、「リンクまたはインポートする作業項目の検索」を参照してください。
(省略可能) リンクする作業項目の説明を入力します。
OKを選択し、作業項目の保存をクリック します。
[!メモ]
リンクした要件と作業項目の両方が更新されます。
要件への詳細、ファイル、およびハイパーリンクの追加
詳細は、次の方法で要件に追加できます。
[詳細] タブの [説明] フィールドまたは [履歴] フィールドに情報を入力します。
ファイルを添付します。
たとえば、電子メールのスレッド、文書、イメージ、ログ ファイルなどのさまざまな種類のファイルを添付できます。
サーバーまたは Web サイト上に保存されている Web サイトまたはファイルへのハイパーリンクを追加します。
要件に詳細を追加するには
詳細 のタブをクリックし、履歴に、履歴レコードの一部として取り込むコメントを追加します。
チーム メンバーが作業項目を更新するたびに、変更日、変更を行ったチーム メンバー、および変更されたフィールドが履歴に表示されます。
情報の書式を設定すると、強調文字や箇条書きリストを使用できます。詳細については、「要件フィールド参照 (CMMI)」を参照してください。
作業項目の保存を選択 します。
要件にファイルを添付するには
[添付ファイル] タブで、次のいずれかの操作を行います。
ファイルを添付ファイル領域にドラッグします。
次にファイルをコピーします CTRL-V を選択 するか、を貼り付けるします。
追加を選択し、参照を選択します。[添付ファイル] ダイアログ ボックスで、添付するファイルの名前を入力するか参照します。
(省略可能) [コメント] ボックスに、添付ファイルに関する追加情報を入力します。
添付ファイル のダイアログ ボックスを閉じるには、OKを選択します。
作業項目の保存を選択 します。
要件にハイパーリンクを追加するには
すべてのリンク のタブで、リンク先を選択 します。
リンクの種類 の一覧で、ハイパーリンクを選択します。
[アドレス] ボックスに、リンク先のアドレスを入力します。
リンク先が Web サイトである場合は、[アドレス] ボックスに URL を入力するか、インターネット ブラウザーから URL をコピーして貼り付けます。リンク先がサーバーである場合は、アドレスを UNC 名の形式で入力します。
(省略可能) [コメント] ボックスに、ハイパーリンクに関する追加情報を入力します。
OKを選択し、作業項目の保存を選択 します。
要件の状態の変更
チームは、要件の [状態] フィールドを次のいずれかの値に設定することで、要件の進行状況を追跡できます。
提案済み
アクティブ
解決済み
Closed
要件を作成すると、その要件は既定で提案済みの状態になります。チームは、現在のイテレーションの要件を受け入れると、作業項目をアクティブ状態にし、その作業項目を実装するためのタスクを作成します。チームがタスクを完了し、システム テストによって要件が正常に実装されたことが確認されたら、作業項目を解決済み状態にします。最後に、要件の検証が完了したら、作業項目を終了状態にします。
要件の状態はどのチーム メンバーでも変更できます。
作業項目の状態を追跡するために使用できるデータ フィールドの詳細については、「割り当て、ワークフロー、および計画 (CMMI)」を参照してください。
要件の状態を変更するには
要件の作業項目フォームを開きます。
状態 の一覧で、アクティブ、解決済み または 終了を選択します。
状態を提案済みからアクティブに変更すると、[理由] フィールドが自動的に承諾済みに変わります。
状態をアクティブから解決済みに変更すると、[理由] フィールドが自動的にコードの完了およびシステム テストの成功に変わります。
状態を解決済みから終了に変更すると、[理由] フィールドが自動的に妥当性確認テストに成功に変わります。
アクティブ終了状態をからに変更すると、 理由 の一覧に、適切なオプションを選択する必要があります。
有効なオプションは [分割] (既定)、[破棄]、および [スコープ外] です。
作業項目の保存を選択 します。
通常のワークフローの流れ:
例外的な遷移:
|
要件の状態 |
提案済み (新規)
チーム メンバーが要件を作成すると、次のデータ フィールドが自動的にキャプチャされます。
[作成者]: 要件を作成したチーム メンバーの名前。
[作成日]: 要件が作成された日時 (サーバー クロックで記録された日時)。
提案済みからアクティブへ
チーム メンバーは、次の表に示す理由により、要件の状態を提案済みからアクティブに変更できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
承諾済み |
トリアージ委員会が、現在のイテレーションにおける実装の要件を承諾したとき。 |
実装を担当するチーム メンバーに要件を割り当てます。 |
調査 |
トリアージ委員会が、チームが要件を実装するかどうかを決定する前に、顧客への影響を調査する必要があると判断したとき。 |
調査が完了したところで、要件の状態を提案済みに戻します。 |
チーム メンバーが要件の状態をアクティブに変更すると、次のデータ フィールドが自動的にキャプチャされます。
[アクティブ化した人]: 要件をアクティブ化したチーム メンバーの名前。
[アクティブ化された日]: 要件がアクティブ化された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の状態が変更された日時。
提案済みから終了へ
チーム メンバーは、次の表に示す理由により、提案済み状態の要件を終了できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
Rejected (却下) |
トリアージ委員会が、チームが要件を実装できない、または顧客が要件を必要としなくなったと判断したとき。 |
なし。 |
チーム メンバーが要件を終了すると、次のデータ フィールドがキャプチャされます。
[終了者]: 要件を終了したチーム メンバーの名前。
[終了日]: 要件が終了した日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の状態が変更された日時。
アクティブ
チームは、アクティブ状態の要件のみを実装する必要があります。アクティブな要件に対し、チーム メンバーはコードの記述、テスト、および文書化を行うためのタスクを作成する必要があります。すべてのタスクが完了すると、要件の状態は解決済みになります。要件が分割された場合、破棄された場合、またはスコープ外にされた場合も、チーム メンバーは要件を終了できます。
アクティブから解決済みへ
チーム メンバーは、次の表に示す理由により、アクティブな要件を解決できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
コードの完了およびシステム テストの成功 |
要件を実装するためのコードがチェックインされ、すべてのシステム テストに合格したとき。 |
テストを実行するチーム メンバーに要件を割り当てます。 |
チーム メンバーがアクティブな要件を解決すると、次のデータ フィールドが自動的にキャプチャされます。
[解決者]: 要件を解決したチーム メンバーの名前。
[解決日]: 要件が解決された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の状態が変更された日時。
アクティブから終了へ
チーム メンバーは、次の表に示すいずれかの理由により、アクティブな要件を終了できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
分割 (既定) |
要件が大きすぎるか、より具体的に定義する必要があるとき。 |
1 つまたは複数の追加要件を作成し、元の要件からリンクを設定します。新しい要件はアクティブとして承諾される必要があります。 |
破棄 |
要件を実装する必要がなくなったとき。 |
なし。 |
スコープ外 |
現在のイテレーションの要件を実装するための時間が十分にないか、進行をブロックする懸案事項が見つかったとき。 |
要件が実装されるイテレーションを指定します。要件がソフトウェアの次回リリースまで延期される場合、[イテレーション] フィールドは空白のままにし、要件がなぜ延期されたか、およびチームはいつまでに要件を実装する必要があるかについて詳しく記述します。 |
チーム メンバーがアクティブな要件を終了すると、次のデータ フィールドが自動的にキャプチャされます。
[終了者]: 要件を終了したチーム メンバーの名前。
[終了日]: 要件が終了した日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の状態が変更された日時。
アクティブから提案済みへ
チーム メンバーは、次の表に示すいずれかの理由により、アクティブな要件の状態を提案済みに変更できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
延期 |
要件を現在のイテレーションでは実装せずに、今後のイテレーションで実装する可能性があるとき。 |
なし。 |
調査完了 (既定) |
チームが要件の調査を完了し、トリアージのために再送信するとき。 |
なし。 |
チーム メンバーがアクティブな要件を終了すると、次のデータ フィールドが自動的にキャプチャされます。
[変更者]: 要件の状態を変更したチーム メンバーの名前。
[状態の変更日]: 要件の状態が変更された日時。
解決済み
要件がコード内に実装され、システム テストに合格したら、リード開発者が状態を解決済みに設定して要件をテスト担当者に割り当てます。テスト担当者は、要件が顧客の要求に基づいて実装されたかどうかを検証します。要求どおりに実装されている場合、テスト担当者が要件を終了します。要求どおりに実装されていない場合、テスト担当者がさらに作業が行われるように要件を再アクティブ化します。
解決済みから終了へ
チーム メンバーは、次の表に示す理由により、解決済みの要件を終了できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
妥当性確認テストに成功 |
要件が関連付けられているすべての妥当性確認テストに成功したとき。 |
要件を製品所有者に割り当てます。 |
チーム メンバーが解決済みの要件を終了すると、次のデータ フィールドが自動的にキャプチャされます。
[終了者]: 要件を終了したチーム メンバーの名前。
[終了日]: 要件が終了した日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の状態が変更された日時。
解決済みからアクティブへ
チーム メンバーは、次の表に示す理由により、解決済みの要件を再アクティブ化できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
妥当性確認テストに失敗 |
妥当性確認テストで要件が顧客の要求を 1 つ以上満たしていないことが示されたとき。 |
問題点をバグとして文書化し、要件をリード開発者に割り当てます。 |
チーム メンバーが解決済みの要件を再アクティブ化すると、次のデータが自動的にキャプチャされます。
[アクティブ化した人]: 要件を再アクティブ化したチーム メンバーの名前。
[アクティブ化された日]: 要件が再アクティブ化された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の状態が変更された日時。
Closed
拒否されたため、または正常に実装され、確認および検証されたために終了した要件については、チームはさらに作業を行う必要はありません。
チームは、終了した要件がスコープに戻った場合、その要件を再アクティブ化できます。通常は、ビジネス アナリストまたはプログラム マネージャーが、終了した要件を再アクティブ化します。
終了からアクティブへ
チーム メンバーは、次の表に示す理由により、終了した要件を再アクティブ化できます。
理由 |
使用する状況 |
追加で行う操作 |
---|---|---|
スコープ内に再入 |
要件を実装するためのリソースが使用できるようになったとき。 |
要件に対して定義する実装タスク、テスト ケース、および詳細が完成し、最新であることを確認します。 |
エラーによる終了 |
要件が誤って終了された場合。 |
要件に対して定義する実装タスク、テスト ケース、および詳細が完成し、最新であることを確認します。 |
チーム メンバーが終了した要件を再アクティブ化すると、次のデータが自動的にキャプチャされます。
[アクティブ化した人]: 要件を再アクティブ化したチーム メンバーの名前。
[アクティブ化された日]: 要件が再アクティブ化された日時 (サーバー クロックで記録された日時)。
[状態の変更日]: 要件の作業項目の状態が変更された日時。
参照
概念
PowerPoint のストーリーを使用して、バックログ項目
Team Web Access による要求および利害関係者フィードバックの手順
Visual Studio ALM の作業項目フィールド参照