次の方法で共有

開発要件

  • [アーティクル]

要件では、利害関係者が製品に何を期待するのかを説明します。 ビジネス上の利害関係者との議論を容易にするために、ビジネス ドメインの用語や概念を使用して表現する必要があります。 実装についての議論を含めたり、実装に依存したりしないようにする必要もあります。 要件には、動作やサービス品質についてのユーザーの期待だけでなく、法的な制約や商業規格も含まれます。

Visual Studio Team Foundation Server で要件作業項目を使用して要件を記録すると、次のような利点があります。

  • 要件をテスト ケースにリンクして、要件が満たされているかどうかを確認できます。

  • 要件をタスク作業項目にリンクして、要件の実装の進行状況を監視できます。

  • 要件を全体的な要件と詳細な要件に整理できます。これにより、要件を管理しやすくなるほか、進行状況レポートに概要情報を表示できるようにもなります。

  • Visual Studio Ultimate で要件をモデリングして、モデル要素を Team Foundation Server の要件にリンクできます。

要件の特定というテーマについては膨大な資料が存在します。ここでは、それらの情報を繰り返すのではなく、 Visual Studio のツールを CMMI に準拠する方法で使用するために重要となる側面に焦点を絞ります。CMMI の詳細については、「CMMI の背景」を参照してください。

ここで説明するアクティビティは、他の開発アクティビティと同様に、決まった順番で行われるものではありません。 特定のアクティビティを他のアクティビティの改善に役立てられるように、シナリオの記述と並行してドメイン モデルを開発したり、 コーディングの時期が近づいてからシナリオを開発したりするほか、 コードの記述とデモンストレーションが完了したら、そこから得られたフィードバックをこれから実装されるシナリオに反映します。

このトピックの内容

要件を開発する時期

ビジョン ステートメントの記述

シナリオの記述

ビジネス ドメインのモデリング

サービス品質要求の開発

要件のレビュー

検証

要件の確認と編集

要件を開発する時期

Team Foundation Server は反復開発をサポートしています。この手法を効果的に活用するには、初期のイテレーションで対象ユーザーやその他の利害関係者からのフィードバックを収集し、そのフィードバックを使用して、その後のイテレーションに対応する要件を調整します。 これにより、最終的には、ユーザー評価を実施せずに同じ期間で開発した場合に比べてはるかに効果的な製品が実現します。 プロジェクトが大規模なプログラムの数多くのコンポーネントの 1 つに対応する場合は、他のコンポーネントとの統合を早期に行うことで、プログラム アーキテクトが全体的な製品を調整できるようになります。

こうした柔軟性も大切ですが、その一方で、顧客や並行するプロジェクトのパートナーに安定したコミットメントを与える必要もあるため、そのバランスを考慮してください。

したがって、要件は、一定の範囲内でプロジェクト期間を通じて開発および調整されます。 詳細な要件はプロジェクト中に変わる可能性が高いため、対応する実装の前に完全に確定してしまうと作業が無駄になるおそれがあります。

  • イテレーション 0 では、主要な機能を記述する一連の要件を開発し、製品計画を作成するのに十分な程度の詳細のみを含めます。 製品計画では、要件をイテレーションに割り当てて、各イテレーションの最後にどの要件が満たされるのかを示します。 主要な概念とアクティビティのドメイン モデルを作成し、それらの概念に対してユーザーとの話し合いと実装の両方で使用する用語を定義します。 すべての機能に関連する広範な要件を決定します (セキュリティやその他のサービス品質要求など)。

  • 各イテレーションの開始時またはその近辺で、対象となる機能のより詳細な要件を開発します。 ユーザーが従うステップを特定し、アクティビティ図やシーケンス図を使用して定義します。 例外的なケースで発生する状況も定義します。

  • 実装されたすべての要件をできるだけ頻繁に確認します。 セキュリティなどの全体に関係する要件を確認するテストは、新しい機能が追加されるたびに拡張する必要があります。 可能であれば、継続的に実行できるようにテストを自動化します。

要件の変更の管理

CMMI の要件を満たしているかどうかを監視しながらインクリメンタルなプロセスを管理するためのガイドラインを次に示します。

  • イテレーションに対して設定された要件は変更しないでください。 まれに状況が突然変わることもありますが、そのような場合は、イテレーションを取り消して、製品計画を見直してから新しいイテレーションを開始します。

  • 要件の不確実性を特定します。 初期のイテレーションのユーザー エクスペリエンスから不確実性を低減する情報が得られるように計画を立てます。

  • 変更要求作業項目を使用して、既に実装された動作の変更に対する要求を記録します (要求された変更が既に計画の一部に組み込まれている場合を除く)。 各変更要求を、該当する要件作業項目にリンクします。 詳細については、「変更要求 (CMMI)」を参照してください。

  • 各イテレーションの前に行われる製品のレビュー時に変更要求をレビューし、 依存プロジェクトやユーザーにどのような影響が及ぶかを調べて、コードの変更に関連するコストを見積もります。 変更要求が承認された場合は要件を更新します。

  • すべての要件の変更に合わせてテストを更新します。

  • 期限を設定して (イテレーション 2 または 3 の後など)、それ以降はよほどの理由がない限り要件を変更できないようにします。 顧客からの支払いが伴うプロジェクトでは、これが、顧客が要件のベースライン セットを承認し、時間払いから固定価格への切り替えが行われる日付になります。

  • バグ作業項目を使用して、明示的な要件または暗黙的な要件を満たしていない実装済みの動作を記録します。 必要に応じて、そのバグを発見できるような新しいテストを作成します。

ビジョン ステートメントの記述

ビジョン ステートメントについてチームと話し合い、それを Team Foundation Server のプロジェクトの Web ポータルに表示します。

ビジョン ステートメントとは、製品の利点を短くまとめたもので、 ユーザーがこれまでできなかったどのようなことができるようになるのかが示されています。 ビジョン ステートメントは、製品のスコープを明確にするのに役立ちます。

既存の製品の場合は、今回のバージョンのビジョン ステートメントを記述して、 その製品のユーザーがこれまでできなかったどのようなことができるようになるのかを示します。

シナリオの記述

顧客やその他の利害関係者と協力してシナリオを作成し、要件作業項目として入力して "必要条件の種類" フィールドを "シナリオ" に設定します。

シナリオ (ユース ケース) とは、イベントのシーケンスを物語的に記述したもので、特定のゴールがどのように達成されるのかが示されています。また、通常は、人または組織とコンピューターとの相互作用も含まれています。

シナリオには、一覧表示したときにすぐに見つけられるようなわかりやすいタイトルを付けます。 タイトルには、主要なアクターとそのゴールが明示されている必要があります。 たとえば、次のタイトルは適切なタイトルです。

顧客が料理を購入する。

シナリオは、次の形式で記述できます。 必要に応じて複数の形式を使用することもできます。

  • 作業項目の説明 (1 ～ 2 文の説明):

    顧客が Web サイトで料理を注文し、クレジット カードで支払いを行う。 注文がレストランに渡されて、レストランが料理を作って配達する。

  • 作業項目の説明 (ステップの箇条書き):

    1. 顧客が Web サイトを訪れて料理の注文を作成する。

    2. Web サイトが顧客を支払いのために支払いサイトにリダイレクトする。

    3. 注文がレストランの作業リストに追加される。

    4. レストランが料理を作って配達する。

  • ストーリーボード: ストーリーボードとは、基本的にはストーリーを漫画で表現したもので、 PowerPoint で描画できます。 作成したストーリーボードのファイルは、要件作業項目にアタッチするか、チーム ポータルにアップロードして作業項目へのハイパーリンクを追加します。

    ストーリーボードは、ユーザーとの相互作用を示すのに特に便利です。 ただし、ビジネスのシナリオでは、ユーザー インターフェイスの最終的な設計ではないことを示すためにスケッチ スタイルを使用することをお勧めします。

  • 要件ドキュメント: 要件ドキュメントには、各要件の詳細を必要に応じて自由に含めることができます。 要件ドキュメントを使用することに決めた場合は、各要件の Word 文書を作成し、それを要件作業項目にアタッチするか、チーム ポータルにアップロードして作業項目へのハイパーリンクを追加します。

  • UML (Unified Markup Language) シーケンス図: シーケンス図は、複数のグループがやり取りする場合に特に便利です。 たとえば、料理の注文の例では、顧客、DinnerNow Web サイト、支払いシステム、およびレストランが特定のシーケンスでやり取りする必要があります。 UML モデルでシーケンス図を描画し、Team Foundation Server にチェックインして、要件作業項目にリンクを入力します。 詳細については、「UML シーケンス図: ガイドライン」を参照してください。

具体的なシナリオ

最初に、特定のシーケンスで特定のアクターのセットを追う具体的なシナリオを記述します (例: "Carlos が DinnerNow Web サイトでピザとガーリック トーストを注文する。 Web サイトが Carlos を Woodgrove Bank の支払いサービスにリダイレクトする。 Fourth Coffee がピザを作って配達する")。

具体的なシナリオは、システムがどのように使用されるのかを想像しやすいため、機能を初めて調査するときに最も便利です。

名前付きのペルソナを作成して、人および組織の背景やその他のアクティビティを記述するのも有効です (Carlos はインターネット カフェに寝泊まりしている、Wendy はゲーテッド コミュニティに住んでいる、Sanjay は仕事中の妻のために食事を注文する、Contoso は世界中に 2,000 店の店舗を持つレストラン チェーンを経営している、Fourth Coffee は自転車で配達を行う夫婦が経営しているなど)。

"顧客"、"メニュー品目" などの言葉で記述されたより一般的なシナリオを使用すると、手間はかからないかもしれませんが、便利な機能を発見できる可能性は低くなります。

詳細レベル

イテレーション 0 では、少数の重要なシナリオのみをある程度詳細に記述し、ほとんどのシナリオは大まかに記述します。 特定のシナリオを完全に実装したり部分的に実装したりするイテレーションが近づいたら、そのシナリオの詳細を追加します。

シナリオについて最初に検討する際には、製品に関係ない側面も含め、ビジネス上のコンテキストを記述すると役に立つ場合があります。 たとえば、DinnerNow の配達方法について記述すると (配達を個々のレストランに任せるか、DinnerNow が配達サービスを提供するか)、 開発チームに有用なコンテキストを提供できます。

イテレーションの開始時に開発するより詳細なシナリオでは、ユーザー インターフェイスの相互作用を記述したり、ストーリーボードでユーザー インターフェイスのレイアウトを示したりできます。

シナリオの整理

シナリオを整理するには次の方法があります。

  • 各シナリオをユース ケースとして示すユース ケース図を描画します。 この方法を使用すると、シナリオを提示したりシナリオについて話し合ったりすることが簡単になるので、この方法を使用することをお勧めします。 詳細については、「UML ユース ケース図: ガイドライン」を参照してください。

    • シナリオを定義する作業項目に各ユース ケースをリンクします。 詳細については、「方法: 作業項目をモデル要素にリンクする」を参照してください。

    • 拡張関係を描画して、別のシナリオのバリエーションであるシナリオを示します。 たとえば、"顧客が請求先住所と配達先住所を別々に指定する" は、"顧客が注文を行う" という基本的なユース ケースの拡張です。 拡張は、後のイテレーションで実装するシナリオを選り分けるのに特に便利です。

    • 包含関係を描画して、"顧客がログオンする" など、複数のユース ケースに共通の手順を選り分けます。

    • 汎化関係を描画して、一般的なシナリオ ("顧客が支払いを行う") とそれを具体化したもの ("顧客がカードで支払いを行う") を関連付けます。

  • Team Foundation Server でシナリオ作業項目の間に親/子リンクを作成します。その階層構造はチーム エクスプローラーで表示できます。 詳細については、「要件に基づいた製品計画」を参照してください。

ビジネス ドメインのモデリング

製品の使用に関連する主要なアクティビティと概念を記述する UML モデルを作成します。 そのモデルで "ユビキタス言語" として定義した用語を、シナリオ、利害関係者との話し合い、ユーザー インターフェイス、ユーザー マニュアル、およびコード自体で使用します。

多くの要件は、顧客から明示的に指定されません。そうした暗黙の要件をくみ取ることができるかどうかは、ビジネス ドメイン (製品が使用されるコンテキスト) を理解しているかどうかにかかっています。 したがって、よく知らないドメインでの要件の収集には、そのコンテキストについての知識を得る作業が含まれます。 そうして得られた知識は、他のプロジェクトにも応用できます。

作成したモデルはバージョン コントロールに保存します。

詳細については、「ユーザー要求のモデリング」を参照してください。

動作のモデリング

アクティビティ図を描画して、シナリオの概要を示します。 スイムレーンを使用して、アクションをアクター別にグループ化します。 詳細については、「UML アクティビティ図: ガイドライン」を参照してください。

シナリオではイベントの特定のシーケンスが記述されるのが一般的ですが、アクティビティ図ではすべての可能性が示されます。 したがって、アクティビティ図を描画することで、別のシーケンスについて考えたり、それらのケースにどのように対処すべきかをビジネス上のクライアントに確認したりできます。

次の図は、アクティビティ図の単純な例を示しています。

3 つのアクションと 1 つのループがあるアクティビティ

メッセージのやり取りが重要になるケースでは、各アクターと主要な製品コンポーネントの生存線を含むシーケンス図を使用する方が効果的な場合もあります。

ユース ケース図を使用すると、製品がサポートするさまざまなアクティビティ フローの概要を示すことができます。 図の各ノードは、特定のユーザー ゴールに到達するためにユーザーとアプリケーションの間で行われる一連の相互作用を表します。 共通のシーケンスやオプションの拡張を別のユース ケース ノードにまとめることもできます。 詳細については、「UML ユース ケース図: ガイドライン」を参照してください。

次の図は、ユース ケース図の単純な例を示しています。

前のアクションのユース ケース

概念のモデリング

ドメイン クラス図を描画して、シナリオで言及されている重要なエンティティとそれらの関係を記述します。 たとえば、DinnerNow のモデルには、レストラン、メニュー、注文、メニュー品目などが示されています。 詳細については、「UML クラス図: ガイドライン」を参照してください。

関係のロール (端) に名前と基数のラベルを付けます。

ドメイン クラス図では、通常、クラスに操作をアタッチしません。 ドメイン モデルでは、アクティビティ図で動作を記述します。 プログラムのクラスへの責任の割り当ては開発作業で行われます。

次の図は、クラス図の単純な例を示しています。

Order クラスにアタッチされたコメント内のルール

静的な制約

属性と関係を制御する制約をクラス図に追加します ("注文の品目はすべて同じレストランのものでなければならない" など)。 この種の規則は製品の設計にとって重要になります。

モデルの一貫性

モデルとシナリオが一貫していることを確認します。 あいまいさの解決は、モデルの最も強力な利用法の 1 つです。

  • シナリオ記述では、モデルで定義されている用語が使用され、モデルで定義されている関係との一貫性が保たれていることを確認します。 たとえば、モデルでメニュー品目として定義されているものをシナリオで製品と呼んだり、 メニュー品目は 1 つのメニューにのみ属するとクラス図に示されているのに、メニュー品目を複数のメニューで共有する内容の記述をシナリオに含めたりしないでください。

  • すべてのシナリオに記述されている手順がアクティビティ図で認められていることを確認します。

  • シナリオまたはアクティビティで、クラス図の各クラスおよび関係がどのように作成され、どのように破棄されるのかが記述されていることを確認します (メニュー品目はどのシナリオで作成されるのか、 注文はいつ破棄されるのかなど)。

サービス品質要求の開発

サービス品質要求を指定する作業項目を作成し、 "必要条件の種類" フィールドを "サービス品質" に設定します。

サービス品質要求 (非機能的要求) には、パフォーマンス、使用性、信頼性、可用性、データ整合性、セキュリティ、経済性、サービス性とアップグレード性、提供可能性、保守性、デザイン、適合性と完成度などが含まれます。

それぞれのシナリオでこれらの各カテゴリについて検討します。

各サービス品質要求のタイトルには、その定義がわかるように、コンテキスト、アクション、および尺度を含める必要があります ("カタログ検索では 3 秒未満で検索結果を返す" など)。

また、サービス品質要求に、それが必要とされる詳細な理由が取り込まれていると役に立ちます (ペルソナがその要件を重視する理由、そのレベルのサービスが要求される理由など)。 コンテキストと根拠を示す必要もあります (有用なリスク管理情報 (市場調査、顧客フォーカス グループ、またはユーザビリティ調査のデータなど)、ヘルプ デスク レポート/チケット、その他の事例証拠など)。

作成したサービス品質要求を、その影響を受けるシナリオ (要件作業項目) にリンクします。 関連する作業項目をリンクすると、依存する要件を Team Foundation Server で追跡できるようになります。 たとえば、クエリやレポートを使用して、シナリオとして取り込まれた機能要件にサービス品質要求がどのような影響を与えるのかを確認できます。

要件のレビュー

要件を記述または更新したら、適切な利害関係者によるレビューを実施して、製品とユーザーのすべての相互作用が適切に記述されていることを確認する必要があります。 この利害関係者には、内容の担当者、ビジネス アナリスト、ユーザー操作アーキテクトなどが含まれるのが一般的です。 シナリオのレビューでは、そのシナリオが問題なくプロジェクトに実装できるかどうかを確認する必要もあります。 問題が見つかった場合は修正して、このアクティビティの最後には有効なシナリオになるようにします。

レビュー作業項目を作成してレビューを追跡します。 この項目は、SCAMPI (Standard CMMI Appraisal Method for Process Improvement) 評定のための重要な証拠となります。将来の根本原因分析の際に有力な情報源になる可能性もあります。

各シナリオのレビューでは、次の特性について確認します。

  • ユーザーが実行する必要があるタスク、ユーザーが既に知っていること、および製品とのやり取りについてのユーザーの期待がわかるように記述されている。

  • 問題の概要が示されており、解決策の提案によってわかりにくくなっていない。

  • 製品とユーザーのすべての関連する相互作用が明らかにされている。

  • 内容の担当者、ビジネス アナリスト、およびユーザー操作アーキテクトによって各シナリオがプロジェクトのコンテキストでレビューされ、すべてのシナリオを問題なく実装できることが確認されている。 有効でないシナリオは、有効になるように改訂します。

  • 利用可能な技術、ツール、およびリソースを使用して、予算とスケジュールの範囲内で実装できる。

  • 複数の意味に解釈されることなく簡単に理解できるように記述されている。

  • 他のシナリオと矛盾していない。

  • テストできる。

検証

製品の最終リリースの前にベータ版を作業環境に配置して、 そこから得られた利害関係者のフィードバックに基づいて要件を更新できるように計画を立てます。

検証とは、製品がオペレーティング環境で想定どおりに使用できるようになっているかどうかを確認することで、 MSF for CMMI では、プロジェクトでイテレーションが終了するたびに行われる、正しく機能するソフトウェアの利害関係者へのデモンストレーションによって実現されます。 初期のデモンストレーションからのフィードバックに残りのイテレーションの計画で対処できるようにスケジュールが組まれています。

正確な検証のためには、シミュレートされたコンテキストやデモンストレーションで製品を実行するだけでなく、 可能な限り実際の条件下で製品をテストする必要があります。

要件の確認と編集

ほとんどの開発タスクの基になるシナリオとサービス品質要求は、顧客要件クエリを使用して確認できます。 すべての要件を表示する場合は、要件という作業項目の種類に属するすべての作業項目を返すクエリを記述できます。 イテレーション パスが表示されるように結果の列を設定してください。 詳細については、「チーム クエリ (CMMI)」を参照してください。

クエリは、チーム エクスプローラーや Team System Web Access で直接表示する以外に、Office Excel や Office Project で開くこともできます。 作業項目をバッチとして編集したり追加したりするにはこれらのツールの方が便利です。 詳細については、「Team Foundation Server に接続している Microsoft Excel および Microsoft Project での作業」および「作業項目のツリー リストの使用によるトップダウン プランニングの実行 (Excel)」を参照してください。

ほとんどの要件をプロジェクトの初期のイテレーションで作成し、 初期のバージョンからフィードバックが得られたら、それに基づいて新しい要件を追加したり、要件を調整したりするようにします。

その他のリソース

詳細については、次の Web リソースを参照してください。