要件タイプの概要

要件とは「システムが従わなければならない条件または機能」と定義されます。

また次のようにも定義することもできます。

• 顧客またはユーザーが問題を解決したり、目的を達成するために必要な機能
• 契約、標準、仕様、規制、またはその他正式に課せられた文書を満足するように、システムが準拠または保有する必要がある機能
• 関係者によって課される制限

図 1 は、さまざまなレベルの要件からなる要件ピラミッドです。

最上位レベルの要件は、関係者のニーズです。通常、プロジェクトにはこのような上位レベルのニーズが 5 ～ 15 個あります。下位レベルには、機能、ユースケース、補足仕様があります。これらの要件のさまざまなレベルでは詳細も異なります。下位のレベルほど、要件はより詳細になります。たとえば、「データを永続的なものにする」というニーズがあります。機能レベルでは、この要件は「システムでリレーショナル・データベースを使用する」という詳細で具体的なものになります。補足仕様レベルでは、この要件は「システムで Oracle 9i データベースを使用する」とさらに具体化されます。下に進むほど、要件は具体的になります。

上に戻る

要件間の追跡可能性

追跡可能性とは、システムのさまざまなレベルの要件を関連付ける手法です。この手法は、任意の要件の発生元を確認する場合に役立ちます。図 2 は、上位レベルから下位レベルへと要件を追跡する方法を示しています。通常、すべてのニーズはいくつかの機能にマッピングされ、機能はユースケースと補足要件にマッピングされます。

ユースケースでは機能要件を記述し、補足仕様では機能以外の要件を記述します。さらに、すべてのユースケースは多数のシナリオにマッピングされます。このため、ユースケースからシナリオへのマッピングは 1 対多の関係です。同様に、シナリオも 1 対多の関係でテストケースにマッピングされます。一方、ニーズと機能の間には多対多のマッピングがあります。

追跡可能性にはいくつかの重要な役割があります。

• 実装によってすべての要件が満たされることを確認する (顧客が要求したことがすべて実装された)
• アプリケーションが要件内容のみを実行することを確認する (顧客が要件していないものを実装しない)
• 変更管理を支援する (要件の変更時に、この変更のテストのために再実行が必要になるテストケースを確認したい)

追跡可能性の項目は、別のプロジェクト要素から追跡する必要があるプロジェクト要素です。IBM Rational RequisitePro では、すべてが要件タイプのインスタンスによって表されます。RequisitePro の要件タイプの例として、関係者のニーズ、機能、ユースケース、アクター、用語があります。

RequisitePro には、特別のビューで追跡可能性を表示する便利な方法があります。図 3 は、機能からユースケースへのマッピングの例です。

ここで、矢印の向きはどちらを向いていればよいのか (下位レベルから上位レベルなのか、それとも上位レベルから下位レベルなのか) という疑問が湧いてきます。RequisitePro の 2 つの例でもガイドラインが異なりますが、その答えは、プロジェクト全体で一貫して使う限り、どちらの向きでも問題はありません。

上に戻る

アクターとユースケース

アクターとは、システムを操作する人または機能です。ユースケースとは、アクションのシーケンスという観点からシステムを記述したものです。ユースケースにより、アクターが確認できる結果または値が生成されます。ユースケースには次のような特徴があります。

• アクターによって開始される
• アクターとシステム間の相互作用をモデル化する
• アクションのシーケンスを記述する
• 機能要件に対応する
• アクターに値を供給する
• 意味のある完全なイベント・フローを表す

ユースケースの目的は、システムによって何を実行するかについて、開発者、顧客、およびユーザー間の合意を容易にすることです。ユースケースは、開発者と顧客間のある種の契約になります。ユースケースは、ユースケースで表された内容を実現するための基盤にもなり、設計で重要な役割を果たします。また、ユースケースからシーケンス図、コラボレーション図、クラス図を作成することができます。さらに、ユースケースを基にユーザー・ドキュメントを作成することもできます。ユースケースは、繰り返し行われることに関する技術的内容を計画する際にも役立つかもしれず、ユースケースによって、システム開発者はシステムの目的をより良く理解するようになります。最後に、テストケースの入力としてユースケースを使用することができます。

ユースケース図は、アクターとユースケース間の関係を表します。この記事では、プロジェクトの例としてオンライン書店を取り上げます。図 4 は、このプロジェクトのユースケース図です。

ユースケースの一般的な形式は次のとおりです。

1. 簡単な説明
2. イベント・フロー
   • 基本フロー
   • 代替フロー 1
   • 代替フロー 2
3. 特別な要件
4. 事前の状態
5. 事後の状態
6. 拡張ポイント
7. コンテキスト図
8. アクティビティー図

基本フローは、最も一般的なアクション・シーケンス、すなわちすべてが正常な場合に実行されるステップです。代替フローは基本フローのバリエーションを表し、通常とは異なるケースとエラー状態が含まれます。コンテキスト図は、この特定のユースケースからアクターや他のユースケースへの関係を示すユースケース図の一部です。アクティビティー図は、ユースケースを説明するフロー・チャートです。コンテキスト図とアクティビティー図は必要ではありませんが、ユースケースおよびそのプロジェクトでの位置付けをわかりやすく図示するのに役立ちます。

このオンライン書店 (Online Bookstore) プロジェクトでは、ユースケースの基本フローは注文で、次のようになります。

1. B1 ユーザーがブラウザーに Web サイトのアドレスを入力します。

   システムがログイン・ページを表示します。

2. B2 ユーザーは電子メール・アドレスとパスワードを入力します。

   システムは正しいログインを確認し、メイン・ページを表示して、検索文字列の入力を要件します。

3. B3 ユーザーは検索文字列 (書名の一部) を入力します。

   システムは検索条件と一致するすべての本のリストを表示します。

4. B4 ユーザーは本を選択します。

   システムは本の詳細な情報を表示します。

5. B5 ユーザーはその本をショッピング・カートに追加します。

   ショッピング・カートの内容がユーザーに表示されます。

6. B6 ユーザーは「チェックアウト」オプションを選択します。

   システムは配送先住所の確認を要件します。

7. B7 ユーザーは配送先住所を確認します。

   システムは配送オプションを表示します。

8. B8 ユーザーは配送オプションを選択します。

   システムはどのクレジットカードを使用するかをたずねます。

9. B9 ユーザーはシステムに登録されているクレジットカードを確認します。

   システムは注文の最終的な確認を要件します。

10. B10 ユーザーは注文を確定します。

    システムは確認番号を表示します。

この基本フローの他に、多数の代替フローがあります。たとえば、最初の代替フローには、ユーザーが新規ユーザー (オンライン書店に未登録) である場合の動作を記述します。基本フローでは、ユーザーは常にユーザー ID とパスワードを持っています。一方、代替フロー 1 では、初めて利用するユーザーが登録して顧客データを指定する必要がある場合のケースを記述します。代替フローの別の例として、無効なパスワードがあります。無効なパスワードを入力したユーザーには、エラー・メッセージが表示されます。

表 1 は、ユースケース「注文」に含まれる代替フローです。

フローの命名規則は次のとおりです。

基本フロー: B

代替フロー: A1、A2、A3、・・・

基本フローのステップ: B1、B2、B3、・・・

代替フロー 1 のステップ: A1.1、A1.2、A1.3、・・・

代替フロー 2 のステップ: A2.1、A2.2、A2.3、・・・

代替フローを抽出するには、アクティビティー図を使用します。図 5 は、このユースケースを記述するアクティビティー図です。

基本フローは下にまっすぐ進むのに対し、通常、代替フローは上下へのループです。

上に戻る

ユースケースからテストケースを作成する方法

テストケースの作成前に、指定したユースケースに対するすべてのシナリオを確認する必要があります。シナリオはユースケースのインスタンスです。イベント・フローによって 1 つの特定のパスを記述します。図 6 は、基本フロー B と代替フロー A1、A2、A3、および A4 をもつユースケースを表す仮想のグラフです。すべてのシナリオを確認するには、このグラフで考えられるすべての線を引く必要があります。

代替フローごとに 1 つのシナリオがあり、さらに代替フローのそれぞれの組み合わせごとに 1 つのシナリオがあります。A1 に 1 つ、A2 にもう 1 つ、さらにこの 2 つを組み合わせた 1 つのシナリオがあることから、代替フローより明らかに多数のシナリオがあります。

シナリオを記述する最も簡単な方法は、代替フローのシーケンスを指定することです。たとえば、フロー A2 を 2 回実行してからフロー A6 を実行します。

SC16: A2、A2、A6

シナリオを記述するもう 1 つの方法は、シナリオ内のすべてのステップをリストすることです。ただし、この方法の方が難しく、不必要に詳細になります。

無限ループ (後方へのループ) がある場合について考えてみましょう。理論的には、シナリオは無限に生成されます。図 7 は、後方への無限ループです。

妥当な方法は、基本フロー 1 回の実行、ループ 1 回の実行、次に 2 度目のループの実行です。どちらのループのインスタンスでもプログラムが機能すれば、すべてのループで機能すると想定できます。

本の注文の例には、1 つの基本フローと 8 つの代替フローがあります。代替フローのうちの 4 つは後に戻り、他の 4 つは前に進みます。考えられるユースケースの組み合わせをすべて記述しようとすると、4 千を越えるシナリオがあります (8 つの代替フローがあって、そのうち 4 つは後方へのループなので 2 回実行します。このため合わせて、2 の 8+4 乗、つまり 4096 とおり)。明らかに、このすべてを実行する必要はありません。

これらの 4 千とおりのシナリオから妥当なサブセットとなるシナリオを選択してください。通常は、基本フロー、それぞれの代替フローをカバーするシナリオを 1 つ、および代替フローの妥当な組み合わせをいくつか選択します。表 1 の例を使用すると、A1 フローと A7 フローはダイアグラム上で離れていて互いに影響がないため、この両方を含むシナリオはおそらく意味がありません。一方、A1 と A2 はすぐ近くにあって関連している可能性があるため、両方を実行することに意味があります。

表 2 は選択したシナリオです。基本フローを表すシナリオが 1 つ、各代替フローを表すシナリオが 8 つ、フローの組み合わせを反映したシナリオが 6 つ (特に、近くにあって 2 つの後方ループをもつシナリオ) あります。

次の 15 のシナリオがテストの対象となります。

RequisitePro でシナリオを作成する方法

シナリオは RequisitePro の標準要件タイプではないため、新しい要件タイプとして追加する必要があります。追加するには、「Project Properties」で「Requirement Types」タブを選択し、「Add」をクリックします。次に、適切なフィールドに記入し (図 8 参照)、「OK」をクリックします。

要件タイプを作成したら、すべてのシナリオを入力し、ユースケースからこれらのシナリオへの追跡可能性を設定する必要があります (図 9 参照)。

RequisitePro では、ユースケースの名前と代替フローのシーケンスによってシナリオを指定できます (UC1, A6, A7 など)。

すべてのシナリオを準備したら、今度はテストケースを生成する必要があります。そのためには、次の 4 つの段階があります。

1. 各ユースケース・ステップの変数を特定する
2. 変数ごとに大幅に異なるオプションを特定する
3. テストするオプションをテストケースにまとめる
4. 変数に値を代入する

以下のセクションでは、これらの各段階の詳細を説明します。

段階 1: 各ユースケース・ステップの変数を特定する

特定のシナリオの全ステップで入力変数をすべて特定する必要があります。たとえば、ユーザーがユーザー ID とパスワードを入力するステップには 2 つの変数があります。最初の変数はユーザー ID、2 番目の変数はパスワードです。変数は、ユーザーが選択を行う選択肢のこともあります (Save changes、Cancel など)。

本の注文の例で使用するすべての変数は次のとおりです。

ステップ B2 には、電子メールとパスワードという 2 つの変数があります。どちらも文字列です。ステップ B3 の本の検索では、変数は検索文字列なので、これも文字列です。ステップ B4 では、システムによって表示されるリストから本を選択する必要があります。ステップ B8 では、配送オプションを選択する必要があります。Amazon.com には 4 つのオプションが用意されています。

段階 2: 変数ごとに大幅に異なるオプションを特定する

オプションによってシステムの動作が異なる場合、これは「大幅に異なる」オプションです。たとえば、6 ～ 10 文字の長さのユーザー ID を選択する場合、次の入力は大幅に異なります。

• Alex - 短すぎるため、エラー・メッセージが表示される
• Alexandria - 有効なユーザー ID
• Alexandrena - 長すぎるため、システムでユーザー ID を入力できない

ただし、Alexandria と JohnGordon が「大幅に異なる」ことはありません。この 2 つは有効なユーザー ID なので、システムの動作が同じになるためです。

以下のガイドラインは、特定のケースに関する説明です。

オプションが「大幅に異なる」と見なされる状況:

1. そのプロセスの別のフロー (通常は代替フロー) が開始される

   例

   • 無効なパスワードが入力されると、代替フロー 2 が開始されます。

2. 別のエラー・メッセージが表示される

   例

   • 電子メールが長すぎる場合、「電子メールは最大 50 文字までです」というメッセージが表示されます。
   • 電子メールに @ 記号が含まれない場合、「電子メール・アドレスが無効です」というメッセージが表示されます。

3. ユーザー・インターフェースの外観が異なる 例
   • 支払い方法がクレジットカードの場合、クレジットカード番号、有効期限、および所有者名を入力するフィールドが表示されます。
4. ドロップダウンに別の選択肢が表示される

   例

   顧客登録画面に、「国」と「州」のドロップダウンがあるとします。「州」のドロップダウンのデータは、選択した国によって設定されます。米国の場合はすべての州、カナダの場合もすべての州が設定され、他の国の場合は無効になります。これによって 3 つの異なるオプションが生成されます。

   • 米国
   • カナダ
   • その他の国
5. あるビジネス・ルールへの入力になる

   例

   「午後 6 時以降の注文でユーザーが夜間配送を選択した場合、本の到着は翌日以降になることをメッセージで知らせる」というルールがあるとします。これで、2 つの異なるオプションが生成されます。

   • 夜間配送 (午後 6 時前の注文)
   • 夜間配送 (午後 6 時以降の注文)
6. 境界条件になる

   例

   パスワードは 6 文字以上なので、次のテストを行います。

   • 5 文字のパスワード
   • 6 文字のパスワード
7. 何かを変更する場合と、デフォルトを使用する場合がある

   例

   クレジットカード支払い画面で、カード所有者の名前は注文者名が入力されています。これによって 2 つの異なるオプションが発生します。

   • デフォルトのカード所有者名を使用する
   • カード所有者名を別の名前に変更する
8. 入力形式が明確に定義されていないため、ユーザーの解釈が異なる場合がある

   例

   電話番号の記入方法は人によって異なります。

   • (973) 123 4567 のようにカッコを使用
   • 973-123-4567 のようにハイフンを使用
   • 973 123 4567 のようにスペースを使用
9. 通常のケースが国によって異なる

   例

   米国とヨーロッパでは、クレジットカード有効期限の日付書式が異なります。

数値のテストでは、次のオプションを考慮する場合があります。

• アプリケーションの観点からは妥当な通常の数値
• ゼロ
• 負の数値
• 小数点以下 2 桁の数値
• 入力可能な最大数値 (99999999999999 - すべての桁に 9 を入力)

フィールドに入力できる最小および最大の長さを確認するにはどうすればよいでしょうか。この要件の発生元はさまざまです。場合によっては、ビジネス・アナリストや顧客が要求することがあります。たとえば、ある企業を特定する Dun and Bradstreet 番号を入力する場合、この数値は必ず 9 桁です。これはビジネス要件です。

ただし、顧客やユーザーからの要件ではない場合もよくあります。姓の桁数を顧客に質問しても、わからないので適当に決めてほしいと言われる可能性があります。この場合、変数の長さは要件段階ではなく設計段階で決定します。

別の状況で、データ・アナリストやデータベース設計者によって提案される場合もあります。たとえば、社内の他のすべてのアプリケーションで、姓が 30 文字分のフィールドに格納されている場合は、このアプリケーションでもこの標準に従います。

要件元がどこであっても、テストケースを実行する前に、要件は必ず合意の上で文書化しておく必要があります。

上記で説明したような要件をどこへ文書化するかも問題です。このような要件を追加する 1 つの場所は、ユースケース内で特別要件と呼ばれるパラグラフです。または、用語集またはデータ・ディクショナリーに記述できます。さらに、アプリケーション全体のすべての変数を記述する別の種類のドキュメントを指定することもできます。特に同じ変数が、たくさんあるユースケースの中の多くの画面に出てくる場合は、すべての名前が最大 30 文字ですべての住所が最大 100 文字であることを 1 つのドキュメントに記述できるのでこれは便利です。ただし、要件がユースケースに固有である場合は、そのユースケースの特定の要件に追加する方が適切です。

段階 3: テストするオプションをテストケースにまとめる

前の段階ですべてのオプションを確認しました。ここでは、テストケースのステップのシーケンスにオプションを組み込む必要があります。

図 10 は、テストするオプションを図で表したものです。各列はテストする入力変数、各行が 1 つのオプションです。たとえば、R は標準 (Regular)、E は空白 (Empty)、数字は文字数や日数 (1、50、51 など)です。L は非常に長い (very Long)、I は無効 (Illegal) を意味します。

右に縦棒が付いているオプションでは、ユーザーは基本フローから投げ出されます。これらは、代替フローで記述されるエラーを表します。現在設計しているのは最初のシナリオのテストケースのみなので、エラーを除外できます (エラーについては別のシナリオでテストします)。残りのオプションから、すべての条件をカバーする最小限のテストケースを作成する必要があります。

図 11 に示すように、オプションを結び付けてテストケースを作成します。

最初のテストケースを作成するには、任意のオプションを選択して連結します。2 番目のテストケースを作成するには、最初のテストケースで使用しなかったオプションのいずれかを選択します。グラフのすべてのノード (図 11 参照) がカバーされるまでテストケースを追加します。通常は、テストするすべてのオプションをカバーするために 4 ～ 6 のテストケースが必要になります。ただし、特定の状況ではさらに必要になる場合があります。

表 4 に示すように、テストケースの割り当てマトリックスの形式でテストケースの割り当てを表すこともできます。

表 4 は、すべての列に別のテストケースが含まれるマトリックス形式で図 11 のグラフを表したものです。各行は、ユーザーが入力する 1 つの変数に対応します。

段階 4: 変数に値を代入する

この段階では、「非常に長い姓」や「内線付きの長い電話番号」などのプレースホルダをそれぞれ「Georgiamitsopolis」や「011-48 (242) 425-3456 ext. 1234」などの実際の値で置き換えます。

また、表 4 に示したマトリックスからすべてのテストケースを分割して、テストケースごとに別の表を作成します。

本の注文 (Book Order) ユースケースのテストケース 1 の場合、表 5 に示すような表ができあがります。このドキュメントがテスト担当者に渡されます。テスト担当者は、2 ～ 3 列目の指示に従って、結果を 5 ～ 7 列目に記録します。

ここで、RequisitePro を使用すると追跡可能性を実現できることを思い出してください。すべてのテストケースを作成した後、シナリオからテストケースまでの追跡可能性を設定できます。

図 12 はすべてのシナリオ (代替フローのさまざまな組み合わせから作成される 21 のシナリオ) を示しています。

シナリオとテストケース間の追跡可能性を設定したら、ユースケースからテストケースまでの全体の追跡可能性を示す追跡可能性ツリーを作成することができます。

これには 2 つの方法があります。最初の方法ではユースケースから追跡します (図 13 参照)。最上位レベルのユースケースが表示され、シナリオとテストケースを追跡します。

2 番目の方法ではテストケースから追跡します (図 14 参照)。この場合はツリーの表示方法が異なります。テストケースから始めて、元になるシナリオとユースケースを逆向きに追跡します。

この追跡可能性を使用する (そしてわざわざ RequisitePro に組み込まれている) 主な理由の 1 つは、何かを変更したときに何を再テストしなければならないかがわかることです。追跡可能性および疑わしい関係 (図 15 参照) は、前のシナリオとユースケースが変更されたために、変更された可能性があるテストケースを示しています。

上に戻る

IBM Rational Unified Process へのマッピング

これらのアクティビティーは IBM Rational Unified Process (RUP) ではどのように位置づけられるのでしょうか。ほとんどのアクティビティーは、プロセスの非常に初期の方向付け (Inception) フェーズと推敲 (Elaboration) フェーズで行われます。ユースケースの準備ができたら、シナリオとテストケースに取り掛かることができます。図 16 は、アクティビティーが RUP 手法のどこに位置付けられるかを表したものです。

シナリオとテストケースの実行中、ユースケース設計者にフィードバックを伝え、要件を洗練させることができます。これによって一部のタスクがプロセスの初期に移動するため、結果的にチームによるプロジェクトの完成を早めることができます。テストケースは、推敲フェーズ全体、および作成 (Construction) フェーズのほぼ全体で使用されます。

上に戻る

まとめ

この記事では、ユースケースから機能テストケースを生成する方法について説明しました。この方法には次のような利点があります。

• テストケースがより自動的に生成される
• 重複したテストを回避できる
• テスト・カバレッジがより適切になる
• テストの進捗管理が容易になる
• テスト担当者間の負荷の分散が容易になる
• レグレッション・テストが容易になる
• 一部のタスクを構築フェーズから推敲フェーズに移行することで、プロジェクト期間が短縮される
• 要件の不足を初期に検出できる

作成したテストケースは、IBM Rational Robot などのツールを使用した自動テストだけでなく、手動のテストでも使用できます。この方法は複数のプロジェクトで使用され、成功しています。

参考文献

1. Jim Heumann 著、「Using Use Cases to Create Test Cases.」 The Rational Edge 刊、2001年6月。
2. Dean Leffingwell 著、Don Widrig著、『ソフトウェア要求管理―新世代の統一アプローチ』ピアソンエデュケーション、2002年。
3. Dean Leffingwell 著、Don Widrig 著、「The Role of Requirements Traceability in System Development」、The Rational Edge 刊、2002年9月
4. 「Rational Unified Process」、Rational Software Corporation 刊、2001年。

この記事の原典である RUC プレゼンテーションを参照するには、ここをクリックしてください。

著者について

この記事を評価する

コメント

上に戻る

目次

• 要件タイプの概要
• 要件間の追跡可能性
• アクターとユースケース
• ユースケースからテストケースを作成する方法
• IBM Rational Unified Process へのマッピング
• まとめ
• 参考文献
• 著者について
• コメント