次の方法で共有

要件に基づいた製品計画

  • [アーティクル]

顧客要件を十分に分析して、製品に何が求められているのかを把握できたら、製品を実装するための計画を立てる必要があります。 既存の製品の場合は、足りない機能を特定して、変更のための計画を立てます。 ただし、要件から自動的に計画が決まるわけではありません。

ここでは、一連の要件から計画を作成する方法の概要を説明します。 ここで説明する方法は、Visual Studio で使用できるさまざまな方法の一例にすぎません。また、この方法を使用する際には、個々のニーズに合わせて調整する必要があります。

このトピックの内容

要件と機能

シナリオの分解

リーフ シナリオのイテレーションへの割り当て

機能 - 各イテレーションで満たされる要件

サービス品質機能

製品計画

イテレーション計画

要件と機能

この方法には、顧客要件と機能という 2 種類の要件があります。 顧客要件は、顧客が製品に何を求めているのかを分析することによって特定される要件です。 機能は、製品計画の項目で、顧客要件の小さなサブセットに相当します。 そのサブセットに、複数のユーザー エクスペリエンス領域や複数の機能領域に対応する部分が含まれる場合もあります。

顧客要件

  • 顧客要件は、対象ユーザーなどの利害関係者との話し合いによって特定されます。

  • 顧客要件を分析する際には、ストーリーボードとモデルを作成して、ツリーを構成する小さなステップへとシナリオを分解するのが一般的です。 ユース ケースやアクティビティなどのモデリング要素をシナリオ作業項目にリンクできます。

  • 顧客要件には次の 2 つの種類があります。

    • シナリオ (ユース ケース)。特定のゴールを目指して行われるユーザーと製品の一連のやり取りを表します。 たとえば、"ユーザーが本を購入する" というタイトルのシナリオなどが考えられます。

    • サービス品質要求。パフォーマンス、セキュリティ、使用性などの基準が含まれます。

  • これらの要件は、種類が要件の作業項目として表すことができます。"必要条件の種類" フィールドを "シナリオ" または "サービス品質" に設定します。

  • これらの要件作業項目は、システム テストにリンクされている必要があります。これにより、すべての要件がテストされることが保証されます。

  • これらの要件作業項目の一覧を表示するには、[顧客要求] クエリを使用します。

  • どの要件が満たされているのかを監視するには、必要条件の進行状況レポートを使用します。

詳細については、「開発要件」、「チーム クエリ (CMMI)」、「必要条件の進行状況レポート (CMMI)」、および「要件またはユーザー ストーリーを使用したテスト計画の作成」を参照してください。

機能

  • 機能とは、タスクのグループを表す製品計画の項目です。 製品計画では、開発チームと利害関係者のそれぞれの代表者が機能をイテレーションに割り当てます。 詳細については、「プロジェクトの計画 (CMMI)」を参照してください。

  • 機能は、要件作業項目として入力します。"必要条件の種類" フィールドを "機能" に設定します。

  • 機能のタイトルでは、それまでのイテレーションではできなかったどのようなことができるようになるのかをユーザーの言葉で説明します。 新しいユーザー価値を提供しない項目は計画に (ほとんど) 含まれません。

    たとえば、次の一連の機能から実装計画を作成できます。

    • "購入者は、一覧から本を選択して購入予定商品の一覧に追加できる。"

    • "本の一覧には価格が表示される。 購入予定商品の一覧には合計金額が表示される。"

    • "販売店は本にタグを添付できる。 購入者は本の一覧をタグでフィルター処理できる。"

    これらの機能はいずれも、ユーザー エクスペリエンスの 1 つのステップでのみ使用される機能でも、製品アーキテクチャの 1 つの部分にのみ関係する機能でもありません。 したがって、これらの機能を実装する際には、複数の機能が見直され、それらに新しいユーザー価値が追加されます。

  • 機能は、製品計画でイテレーションに割り当てられます。 1 つの機能のタスクはすべて同じイテレーションに割り当てる必要があります 詳細については、「プロジェクトの計画 (CMMI)」を参照してください。

  • 機能は、顧客要件の部分的な実現を記述します。 顧客要件のサブセットに相当し、各顧客要件を限られた範囲で実装できます。

  • すべての機能を、その機能によって表される部分の要件をテストする 1 つ以上のテスト ケースにリンクできます。 それらのテスト ケースは、顧客要件にリンクされたシステム テストのサブセットです。

  • 機能のテストが完全に定義されて、すべてのテストに合格するまでは、機能の状態を完了にすることはできません。

  • すべての機能は、開発タスクとテスト タスクのグループであり、 Visual Studio Team Foundation Server のタスク ツリーのルートです。 開発タスクは、機能によって記述される部分の要件を実装します。 テスト タスクは、適切なテスト ケースを設計および実行します。

  • 機能の一覧を表示するには、[製品要求] クエリを使用します。 製品計画を表示するには、[列のオプション] をクリックし、表示される列の一覧に [イテレーション パス] を追加します。 行をイテレーションで並べ替えるには、[イテレーション パス] 列をクリックします。 詳細については、「チーム クエリ (CMMI)」を参照してください。

機能の特定

要件をインクリメンタルな機能に分類する作業は、開発者、アナリスト、および利害関係者が参加する必要があるクリエイティブな作業です。 機能は、周囲から切り離して実装しても問題がない製品の機能の一部を定義します。 したがって、一連の機能を定義して計画を作成する作業は、システムのアーキテクチャにある程度依存します。

そのため、製品の計画と初期設計は並行して行う必要があります。計画の概要を決定するイテレーション 0 では特にそうする必要があります。

シナリオの分解

要件を機能に割り当てる際には、シナリオを小さなステップに分解すると便利です。

この作業には、多くの場合、ストーリーボードが役に立ちます。 ストーリーボードとは、シナリオを一連の絵で表現したものです。 代替パスを示すには UML アクティビティ図が、複数のアクターの相互作用について話し合うには UML シーケンス図が便利です。 これらのツールを使用してシナリオを分析したら、分解されたシナリオをチーム エクスプローラーに入力します。 これにより、シナリオにテスト ケースをリンクして、要件が満たされているかどうかを確認できるようになります。 詳細については、「UML アクティビティ図: ガイドライン」および「UML シーケンス図: ガイドライン」を参照してください。

この短いチュートリアルでは、一連の顧客要件をシナリオの小さなツリーとして入力します。 これは、後ほど機能を作成するときに使用する例になります。

Excel で顧客要件のツリーを開くには

  1. チーム エクスプローラーで、MSF for CMMI Process Integration v5.0 のプロジェクトを開きます。

  2. [作業項目]、[チーム クエリ]、[計画と追跡] の順に展開して、[顧客要求] を実行します。

  3. [イテレーション パス] 列と [必要条件の種類] 列が表示されない場合は、[列のオプション] をクリックし、表示される列の一覧にこれらの列を追加します。

    [区分パス] 列を追加することもできます。

  4. ツリーを表示するようにクエリを設定します。

    1. [クエリの編集] をクリックします。

    2. [クエリの種類] を [作業項目のツリー] に設定します。

    3. [クエリの保存] をクリックします。

      [チーム クエリ] に保存できない場合は [マイ クエリ] に保存します。

    4. [結果の表示] をクリックして編集ビューを閉じます。

  5. [Microsoft Office で開く] をクリックし、[Microsoft Excel でクエリを開く] をクリックします。

  6. Office Excel で、[タイトル 1] という見出しの列の後に [タイトル 2] および [タイトル 3] という見出しの列が表示されていない場合は、[チーム] タブをクリックし、[ツリー レベルの追加] をクリックして、追加の列を作成します。

これで、シナリオをバッチとして入力できるようになりました。

実際の状況では、最初に 1 つのレベルのシナリオを入力して、その後に各シナリオを別々の操作で小さなステップに分解できます。

シナリオを入力するには

  1. 既存の作業項目がある場合はその一番下の行の次の行で、[タイトル 1] 列にトップレベルのシナリオのタイトルを次のように入力します。

    顧客が料理を注文する。

  2. ビジネス上の利害関係者との話し合いを通じて、トップレベルのシナリオを構成する主要なステップを特定できます。

    トップレベルのシナリオに続く行の [タイトル 2] 列に以下のステップを入力します。

    顧客がレストランを選択する。

    顧客がレストランのメニューから品目を選択して注文を作成する。

    顧客が支払いの詳細を入力する。

    レストランが、注文された料理を作って配達する。

    顧客のカードに支払いが請求される。

  3. UML アクティビティ図や相互作用図を使用するなどしてさらに詳しく分析すると、これらのシナリオの一部についてより詳細なステップを特定できます。

    "顧客がレストランを選択する" の下にいくつかの行を挿入して、[タイトル 3] 列に以下のステップを入力します。

    顧客が配達先の郵便番号を入力する。

    Web サイトが、その住所への配達を行っているレストランの一覧を表示する。

    顧客は、表示されたすべてのレストランのメニューを閲覧できる。

    顧客が 1 つのレストランを選択して注文を開始する。

    余った行があれば削除します。

  4. すべての新しい行で、[作業項目の種類] 列を [必要条件] に設定します。

  5. すべての新しい行で、[必要条件の種類] 列を [シナリオ] に設定します。

  6. これらの要件を Team Foundation Server に発行するには、作業項目テーブルの任意のセルを選択し、[チーム] タブの [発行] をクリックします。

これで、顧客要件のツリーを作成できました。このツリーは、Office Excel またはチーム エクスプローラーでさらに編集できます。

リーフ シナリオのイテレーションへの割り当て

"リーフ" シナリオとは、自身の子を持たないシナリオです。

"イテレーション パス" フィールドを設定して、シナリオの最も基本的なステップをイテレーションに割り当てます。 この作業は、Office Excel ビューで行うことができます。

次に、子を持つシナリオを、それぞれが使用可能になると考えられる最も早いイテレーションに割り当てます。

次の例では、最も基本的なシナリオをイテレーション 1 と 2 で実装し、その後のイテレーションでその他の機能を追加しています。

  • イテレーション 2 - 顧客がレストランを選択する。

    • イテレーション 5 - 顧客が郵便番号を入力する。

    • イテレーション 2 - DinnerNow がレストランの一覧を表示する。

    • イテレーション 3 - 顧客は各レストランのメニューを閲覧できる。

    • イテレーション 2 - 顧客が 1 つのレストランを選択して注文を作成する。

  • イテレーション 1 - 顧客がメニューから品目を選択して注文を作成する。

    • イテレーション 1 - 顧客がメニュー品目をクリックして注文に追加する。

    • イテレーション 2 - 注文の概要に注文の合計金額が表示される。

    • イテレーション 1 - 顧客が [確認] をクリックして注文を完了する。

  • イテレーション 4 - 顧客が支払いの詳細を入力する。

  • イテレーション 2 - レストランが、注文された料理を作って配達する。

  • イテレーション 4 - 顧客のカードに支払いが請求される。

これらの割り当てでは、システムの全体的な設計を早い段階で行い、多くの詳細を後回しにすることができます。 リスクが少ないと思われる側面も後のイテレーションに回すことができます。 この例では、カード決済システムへのリンクについてはチームに経験があるため、 その部分を後のイテレーションに回しています。

場合によっては、次の図に示すように、リーフ シナリオをさらに細かく分解して、単純なバージョンと複雑なバージョンをそれぞれ異なるイテレーションに分類することもできます。

シナリオ作業項目のツリー

機能 - 各イテレーションで満たされる要件

機能とは、各イテレーションの完了時にユーザーが行えるようになることをまとめた要件です。 各イテレーションに対して複数の機能を作成できます。 機能は要件作業項目として入力し、[必要条件の種類] を [機能] に設定します。

機能は、シナリオの作業項目への割り当てを使用して定義できます。 次の機能計画は、前のセクションで行ったシナリオのイテレーションへの割り当てに基づいています。

  • イテレーション 1

    • 顧客がメニューから品目を選択し、それらを注文に追加して、配達先の住所を追加する。

  • イテレーション 2

    • 顧客は、最初にレストランの一覧を表示してレストランを選択する。

    • 顧客が注文を完了すると、選択したレストランの画面に注文が表示される。

    • 各品目の価格と合計金額が注文に表示される。

  • イテレーション 3

    • レストランは、作った料理が配達されると注文を "完了" としてマークする。 料理がレストランに対して記録される。

    • 各レストランはメニューを入力したり更新したりできる。

    • 顧客はレストランを選択する前にすべてのレストランのメニューを閲覧できる。

  • イテレーション 4

    • 顧客は注文の完了時に支払いの詳細を入力する。 レストランが注文を "完了" としてマークすると顧客のカードに料金が請求される。

    • "完了" としてマークされた注文の料金がレストランに支払われる。

  • イテレーション 5

    • レストランは配達エリアを設定できる。 顧客はセッションの開始時に郵便番号を入力する。 Web サイトは、そのエリアに配達できるレストランのみを表示する。

部分的に実装されたシナリオ

シナリオを小さなステップに分解すると、早い段階で実装できるステップを、後回しにできるステップから分離できます。

しかし、シナリオのその他の側面を分離できる場合もあります。 たとえば現在の例では、基本的なバージョンのユーザー エクスペリエンスを初期のイテレーションで実装し、後から改良を加えていくことも考えられます。 その場合、たとえば次のような機能を追加できます。

  • イテレーション 6 - レストランは、メニューの配色とフォントを選択したり、レストランのロゴと料理の写真をアップロードしたりできる。

この種の機能は、シナリオをステップに分解することによって直接明らかになるのではなく、通常は、ストーリーボードについての話し合いの中で特定されます。 ユーザー エクスペリエンスの機能は後期のイテレーションに割り当てられるのが一般的です。

機能の入力および検査

種類が要件である作業項目を作成し、"必要条件の種類" フィールドを "機能" に設定します。 タイトルには、機能の短い説明を使用します。

機能をバッチで入力したり、機能のイテレーションへの割り当てについて話し合ったりするには、[製品要求] クエリに調整を加えて、Office Excel ビューを使用します。

機能を入力および編集するには

  1. チーム エクスプローラーで、MSF for CMMI Process Improvement v5.0 のプロジェクトを開きます。

  2. [作業項目]、[チーム クエリ]、[計画と追跡] の順に展開して、[製品要求] を開きます。

  3. [列のオプション] をクリックし、表示される列の一覧に [最初の見積もり] と [イテレーション パス] を追加します。

  4. [Microsoft Office で開く] をクリックし、[Microsoft Excel でクエリを開く] をクリックします。

  5. クエリを保存するかどうかを確認するダイアログ ボックスが表示されたら、[はい] をクリックします。

  6. (省略可能) Office Excel で、一連の機能のタイトルを入力し、イテレーション パスを設定して、行をイテレーション パスで並べ替えます。

  7. 変更を Team Foundation Server に保存するには、作業項目テーブルの任意のセルをクリックし、[チーム] タブの [発行] をクリックします。

機能から要件へのトレース

機能を要件にリンクするには次の方法があります。

  • 機能作業項目を、そのイテレーションのリーフ シナリオ要件にリンクします。 リーフ シナリオには既に親があるため、[関連項目] リンクを使用する必要があります。

  • テスト ケース作業項目を、対象となるシナリオおよびサービス品質要求にリンクし、 機能を、開発が完了したときに合格する必要があるテスト ケースのサブセットにリンクします。 これにより、テスト ケースが機能と顧客要件の間のリンクとして機能するようになります。

サービス品質機能

サービス品質要求は、一般に、ソフトウェア設計のあらゆる側面に関係します。 たとえば、セキュリティの要件は、通常は特定の開発タスクに関連付けられることはありません。

それでも、各サービス品質要求に対して、サービス品質基準が満たされているかどうかを確認するテスト タスクを主な子とする機能作業項目を作成する必要があります。 これらの作業項目をサービス品質機能と呼びます。

一部のサービス品質機能には開発タスクを含めることもできます。 これにより、たとえば、少数のユーザーのみを処理できるバージョンのシステムを概念実証として初期のイテレーションで実装し、 顧客要件に示されている目標キャパシティを指定する機能を後のイテレーションで追加することができます。

製品計画

各イテレーションを開始する前に、会議を開いて製品計画のレビューを行います。 最初の製品計画会議で計画を作成し、その後の会議で、その計画をそれまでのイテレーションに基づいて見直します。 詳細については、「プロジェクトの計画 (CMMI)」を参照してください。

製品計画レビューでは、ビジネス上の利害関係者と機能について話し合います。機能の優先順位を変更したり、機能を別のイテレーションに割り当てたりできるようにしておく必要があります。 この会議には、ビジネス上の利害関係者と、開発チームの代表者が参加します。

会議では、機能の開発順序について話し合います。 これは、[製品要求] クエリの Office Excel ビューを表示して (プロジェクターまたは画面共有を使用します)、機能をイテレーションで並べ替えることによって行うことができます。

そのほかに、機能を特定の順序で並べて、各イテレーションでどこまで開発できるかを検討するという方法もあります。 この方法を使用すると、たとえば、"顧客は価格を表示できる" という機能をイテレーション 2 からイテレーション 3 に移動するかどうかを話し合う際に、その機能をいちいち移動する必要がなくなります。 項目を順序で並べ替えるには、"順位" という名前の列をスプレッドシートに追加して、順序を表す整数を挿入し、 その列でスプレッドシートを並べ替えます。 順位は Team Foundation Server に保存されませんが、そのスプレッドシートを保存することができます。 保存したスプレッドシートを再び開くときには、作業項目テーブルの任意のセルをクリックし、[チーム] タブの [最新の情報に更新] をクリックします。

製品計画では、機能の優先順位と開発コストについて検討します。 優先順位は、ビジネス上の利害関係者が提出します。リスクに関する開発者のアドバイスも考慮されます。 コストの見積もりは開発者が提出します。 開発チームがコストを正確に把握するためには、製品のアーキテクチャの作業がある程度完了している必要があるほか、場合によっては、それまでのイテレーションから得た知識も必要になります。 そのため、コストの見積もりは製品計画レビューのたびに調整する必要があります。

イテレーション計画

製品計画レビューが終わったら、イテレーションの計画を立てます。 製品計画によって、イテレーションの終わりまでに実現される機能が決まります。 イテレーション計画では、それらの機能を実装およびテストするためにチームが行う作業を決定します。

イテレーション計画には、次のアクティビティが含まれます。

  • 開発およびテストのタスクを作成し、それらを子として機能要件にリンクします。

  • 各機能で開発される顧客要件の側面のテスト ケースを作成します。 作成したテスト ケースは、要件がどの程度完了したかを監視できるように顧客要件にリンクする必要があります。

また、テスト ケースを機能にリンクして、機能と要件の対応関係を追跡できるようにすることもできます。 リンクされているテスト ケースに合格するまでは、機能を完了としてマークすることはできません。

詳細については、「イテレーションの計画 (CMMI)」を参照してください。