ユーザー ストーリーのモデリング

モデルを作成することにより、チームは見積もりまたは開発予定のユーザー ストーリーを理解するのに役立てることができます。 また、開発中に製品所有者との議論を継続する中で、問題が複雑な場合にモデルを使用することもできます。

たとえば、チームが初めて触れる一連の概念がプロジェクトに含まれている場合があります。 チームは製品所有者と協力してドメイン クラス図を作成し、これらの概念およびこれらの概念間の関係を把握できます。 チームがユーザー アクティビティの主要なシーケンスを理解する必要がある場合は、アクティビティ図を作成できます。

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

ドメイン モデル: ユーザーの言語

ドメイン クラス図

ドメイン クラス図では、アプリケーションに関連付けられている概念と関係を示します。 これにより、アプリケーションに関係するすべてのユーザーが、これらの概念を使用して共通した認識を持つことができます。

前の図の例は、ソフトウェア ソリューションのクラス図をそのまま表しているものではありません。これらの関係はさまざまな形式で表される場合があります。 代わりに、この図では、ユーザー ストーリーを作成するときに使用できる語彙を表しています。

顧客は、メニューを選択し、それから注文を作成します。次に、メニューからメニュー項目を選択して、注文の注文項目を作成します。

これはプログラム内のオブジェクトではなく概念のモデルであるため、図をこの目的で使用する場合、通常は操作をクラスに割り当てません。 代わりに、アクティビティ図を使用して、ユーザーが実行するアクションを説明できます。

詳細については、「UML クラス図: ガイドライン」を参照してください。

アクティビティ図

チームで、アクティビティ図を使用して、ユーザーが実行できるアクティビティの流れを説明し、各ポイントにおけるアクションの選択肢を示すことができます。

チームでテストを作成するときに、アクティビティ図を参照して、アクティビティ図中のパスごとにテストを作成できます。

ユーザー ストーリーでは、既存のアクティビティ図にパスを導入する場合があります。 たとえば、"顧客として、現時点では支払いをせずに後で注文できるように注文内容を保存することを選択できる" というユーザー ストーリーがあるとします。開発するスプリントにこのストーリーを取り入れる場合に、アクティビティ図を更新して新しい機能を表すことができます。

チームが実装したすべてのユーザー ストーリーを反映するように図を更新した場合、アプリケーションの特定のリリースを使用してユーザーがたどることができる完全な一連のパスをアクティビティ図に示すことができます。

詳細については、「UML アクティビティ図: ガイドライン」を参照してください。

モデルを使用して認識のずれを発見する

チームは、図を使用しない場合の話し合いで生じる誤解を避けることによって、ユーザーの要求をより適切に理解できます。 たとえば、図では、注文の項目とメニューの項目が明確に区別されます。

チームはモデルを作成することで、作成していなければ開発のずっと後の段階まで発せられない可能性のある質問を発することができるようになります。 その手法をいくつか示します。

• クラス図の基数について質問します (例: "メニュー項目は複数のメニューに表示しますか")。

• クラス図内のループについて質問します (例: "注文では、すべての項目は同じメニューに属しますか")。

このような質問に対する回答を、コメントとして図に追加できます。

モデルの一貫性

チームで、モデルとユーザー ストーリーが一貫していることを確認することで、あいまいさを解消できます。

• ユーザー ストーリーでは、モデルで定義されている用語が使用され、モデルで定義されている関係との一貫性が保たれていることを確認します。 モデルでメニュー項目を定義する場合、同じものを表すのに、ストーリーで "製品" という用語を使用しないでください。 メニュー項目は 1 つのメニューにのみ属することがクラス図に示されている場合、項目を複数のメニューで共有するという内容の記述をストーリーに含めないでください。

• アクティビティ図で許可されている一連の手順を、すべてのユーザー ストーリーによって記述します。

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

モデルと製品バックログ

モデルおよびストーリーボードにマーク付けして各ユーザー ストーリーによって変更されるパートを示したり、モデルに対して色やコメントを付けて開発の計画に役立てたりできます。 たとえば、チームで、アクティビティ図内のアクションに色を付けて、実行済みのアクションおよび次のスプリントで実行するアクションを示すことができます。

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

モデルとテスト

ドメイン モデルをシステム テストの基盤として使用できます。これにより、テストとユーザーの要求の間に明確な関係が設定されます。 この関係は、チームがテストを迅速かつ正確に更新したり、製品が新しい要求を満たしていることを確認したりするのに役立ちます。

チームは、UML (Unified Modeling Language) モデルの任意の要素を、テストなどの任意の作業項目にリンクできます。 モデルのいずれかのパートが変更された場合に、チームはモデルが関連しているテストを見つけることができます。

次のようにして、ドメイン モデルを使用してテストを作成できます。

• メニュー項目や注文項目など、各型または関連付けの構築に関係する 1 つ以上のテストを作成し、その破棄に関係する 1 つ以上のテストを作成します。

• アクティビティ図に示されているすべてのパスがテストされるようにします。

  注意

  テストは、通常はアクティビティ図に示さない例外的なパスに対しても実行する必要があります。

• ドメイン モデルの語彙を使用してテストを定義します。 たとえば、テストに、メニュー項目の選択アクションのテストが含まれるとします。このテストでは、このアクションの結果として、新しい注文項目が含まれる注文が発生することを確認します。 自動テストを記述する場合は、図に直接基づいたクラスおよび関係を使用できます。

詳細については、「モデルからのテストの作成」を参照してください。