Loading article…
ソフトウェアエンジニアリングとシステムエンジニアリングの両方において、ユースケースとは、特定の目標を達成するために外部アクターからの要求に応答する際のシステムの動作を構造的に記述したものです。この用語は、ソフトウェア/システムエンジニアリング以外でも、何かがどのように使用できるかを説明するために使用されます。[ 1 ]
ソフトウェア（およびソフトウェアベースのシステム）エンジニアリングでは、機能要件の定義と検証に使用されます。[ 2 ]ユースケースは、通常、目標を達成するために役割（統一モデリング言語（UML）ではアクターとして知られています）とシステム間の相互作用を定義するアクションまたはイベントステップのリストです。アクターは、人間または他の外部システムである可能性があります。システムエンジニアリングでは、ユースケースはソフトウェアエンジニアリングよりも高いレベルで使用され、多くの場合、ミッションまたは利害関係者の目標を表します。詳細な要件は、システムモデリング言語（SysML）または契約ステートメントとして記述される場合があります。
ソフトウェアエンジニアリングにおいて、ユースケースは、外部からの要求（ユーザー入力など）に対するソフトウェアの潜在的な動作シナリオを定義します。システムエンジニアリングにおいては、ユースケースは、技術的要素と人的要素の両方における高レベルの機能的動作をモデル化します。
ソフトウェアおよびシステムエンジニアリングにおいて、「ユースケース」という用語は2つの意味を持つ多義語である。
この記事では後者の意味について論じます。（もう一方の意味については、「ペルソナ（ユーザーエクスペリエンス）」を参照してください。）
1987年、イヴァル・ヤコブソンはOOPSLA '87会議でユースケースに関する最初の論文を発表しました。[ 3 ]彼は、この手法がエリクソンでどのように使われ、テキスト、構造、視覚モデリング技術を用いてシステムの要件を捉え、特定し、オブジェクト指向分析と設計を推進したかを説明しました。[ 4 ]当初、彼は「使用シナリオ」と「使用ケース」という用語を使用していましたが（後者は彼のスウェーデン語のanvändningsfallの直訳）、どちらの用語も英語では自然に聞こえないことに気づき、最終的に「ユースケース」に落ち着きました。[ 5 ]
1992年、彼は『オブジェクト指向ソフトウェアエンジニアリング - ユースケース駆動型アプローチ』 [ 6 ]を共著し、 OOSEシステムエンジニアリング手法の基礎を築き、特にソフトウェア開発において機能要件を捉えるためのユースケースの普及に貢献した。1994年には、ビジネスモデルとビジネスプロセス再設計に適用されるユースケースとオブジェクト指向技術に関する書籍を出版した。[ 7 ]
同時に、Grady BoochとJames Rumbaugh は、それぞれBooch メソッドとObject Modeling Technique (OMT) というオブジェクト指向分析および設計手法を統合する作業に取り組んでいました。1995 年に Ivar Jacobson が加わり、彼らはユースケース モデリングを含むUnified Modelling Language (UML)を作成しました。UML は1997 年にObject Management Group (OMG)によって標準化されました。 [ 8 ] Jacobson、Booch、Rumbaugh はObjectoryソフトウェア開発プロセスの改良にも取り組みました。その結果として生まれたUnified Processは 1999 年に公開され、ユースケース駆動型アプローチを推進しました。[ 9 ]
それ以来、多くの著者がこの技術の開発に貢献しており、特に次のようなものがあります。ラリー・コンスタンティンは、1995 年に使用中心設計の文脈で、ユーザーインターフェイスの設計を制約または偏らせる可能性のある一連のアクションやシナリオではなく、ユーザーの意図を記述することを目的とした、いわゆる「必須ユースケース」を開発しました。[ 10 ]アリスター・コックバーンは、2000 年にテキストナラティブと表形式の仕様に基づく目標指向のユースケースプラクティスを発表しました。[ 11 ]カート・ビットナーとイアン・スペンスは、2002 年にユースケースを使用して機能要件を分析するための高度なプラクティスを開発しました。[ 12 ]ディーン・レフィングウェルとドン・ウィドリグは、ユースケースをチェンジマネジメントとステークホルダーコミュニケーション活動に適用することを提案しました。[ 13 ]グンナー・オーバーガードは、2004 年にデザインパターンの原則をユースケースに拡張することを提案しました。[ 14 ]
2011年、ジェイコブソンはイアン・スペンスとカート・ビットナーと共に、アジャイルなコンテキストにこの手法を適用し、段階的なユースケース「スライス」でそれを充実させ、 IIBA年次会議でこの新しいアプローチを発表した後、開発ライフサイクル全体でその使用を促進する電子書籍Use Case 2.0を出版した[ 15 ]。[ 16 ] [ 17 ]
ユースケースは、システムの要件を捉え、モデル化し、仕様化するための手法です。[ 12 ]ユースケースは、システムがアクターとの相互作用において実行する可能性のある一連の動作に対応し、その目標に貢献する観測可能な結果を生み出します。アクターは、相互作用において人間ユーザーや他のシステムが果たす役割を表します。
要件分析において、ユースケースは特定された時点で、その主要なアクターにとっての具体的なユーザー目標に基づいて命名されます。ユースケースは、活動やイベントの一般的な流れ、および特別な条件、例外、エラー状況などのバリエーションを説明するテキストによる説明、または追加の図解モデルによってさらに詳細化されます。
ソフトウェアエンジニアリング知識体系（SWEBOK）[ 18 ]によると、ユースケースはシナリオベースの要件抽出手法とモデルベースの分析手法に属します。しかし、ユースケースは物語ベースの要件収集、増分的な要件取得、システムドキュメント作成、および受け入れテストもサポートします。[ 3 ]
この技術には、さまざまな使用例とバリエーションが存在する。
ユースケースの範囲は、主題と目標によって定義できます。
ユースケースは、以下の状況で適用されることが知られています。
ユースケースを記述する方法は、簡潔なユースケース、カジュアルなユースケース、アウトライン、詳細なユースケースなど、さまざまな形式があり、テンプレートも多岐にわたります。さまざまなベンダーや専門家が考案したテンプレートを使用してユースケースを記述することは、高品質な機能システム要件を得るための一般的な業界慣行です。
アリスター・コックバーンが著書『効果的なユースケースの書き方』で定義したテンプレートは、ユースケースの記述スタイルの中で最も広く使われているものの1つである。
コックバーンは、各ユースケースに「設計範囲」を示すシンボルを注釈として付けることを提案している。設計範囲は、ブラックボックス（内部の詳細が隠されている）またはホワイトボックス（内部の詳細が表示されている）のいずれかである。5つのシンボルが利用可能である：[ 22 ]
他の著者は、組織レベルのユースケースを「ビジネスユースケース」と呼ぶことがある。[ 23 ]
コックバーンは、各ユースケースに「目標レベル」を示すシンボルを注釈として付けることを提案している。[ 24 ]推奨レベルは「ユーザー目標」（または口語的には「海面レベル」[ 25 ] : 101）である。
テキスト作成では、ユースケース名の後に代替テキスト記号 (! +、- など) を付けることで、レベルをより簡潔かつ便利に表現できる場合があります。例:注文する!、ログイン-。
コックバーンはユースケースのより詳細な構造を説明していますが、詳細度が低い場合は簡略化することも許可しています。彼の完全なユースケーステンプレートには次のフィールドがリストされています。[ 26 ]
さらに、コックバーンは、各ユースケースの性質を示すために、設計範囲と目標レベルを表すアイコンという2つの手段を用いることを提案している。
コックバーンのアプローチは他の著者にも影響を与えており、例えばアレクサンダーとベウス＝ドゥキッチはコックバーンの「完全なユースケース」テンプレートをソフトウェアからあらゆる種類のシステムに一般化しているが、コックバーンと異なる点は以下の通りである。[ 28 ]
コックバーンは、プロジェクトでは必ずしも詳細な「完全な」ユースケースが必要ではないことを認識しています。彼は、次のようなフィールドを持つカジュアルなユースケースについて説明します。[ 26 ]
マーティン・ファウラーは、「ユースケースの内容を記述する標準的な方法はなく、さまざまなケースで異なる形式がうまく機能する」と述べている。[ 25 ]： 100彼は「共通のスタイル」を次のように説明している。[ 25 ]： 101
ファウラー・スタイルは、コックバーン・テンプレートの簡略化されたバリエーションと見なすこともできます。このバリエーションはユーザー・ストーリーと呼ばれます。
アリスター・コックバーンは次のように述べた。[ 29 ]
ユーザー ストーリーは、2 ビットの精度を持つユース ケースと考えてください。精度の 1 ビット目はユース ケースの目標を示し、2 ビット目はメイン シナリオを追加します。3 ビット目は失敗条件を追加し、4 ビット目は失敗時のアクションを追加します。5 ビット目は入出力データのデータ記述を追加します。Catalysis はメッセージの受信者のモデルも含むため、精度 6 ビット目に位置付けます。CrystalMethodology ファミリーでは、異なる基盤を持つプロジェクトは、異なるレベルの精度でユース ケースを使用します。方法論的に軽いプロジェクトはユーザー ストーリーを使用し、方法論的に重いプロジェクトは 4 ビットの精度でユース ケースを使用し、Catalysis は 6 ビットの精度を使用します。
マーティン・ファウラーは次のように述べた。[ 29 ]
すべては、人々がケースをどのように活用するかにかかっています。私は、ケースを非常に形式的な方法で活用する人をたくさん見てきました。ケントは、ユーザーストーリーをはるかに親しみやすい方法で活用しています。私は、ケントがユーザーストーリーで行っているのと同じようにケースを活用しています。私は、他の開発者とのコミュニケーションを円滑にし、より軽量なアプローチを採用するよう促すために、ケースをユースケースと呼んでいます。
ユースケースは、目的を達成するために、外部アクターと検討対象のシステムとの間の相互作用を定義します。アクターは意思決定を行うことができなければなりませんが、人間である必要はありません。「アクターは、人、企業または組織、コンピュータ プログラム、またはコンピュータ システム (ハードウェア、ソフトウェア、またはその両方) である可能性があります。」[ 30 ]アクターは常にステークホルダーですが、すべてのステークホルダーがアクターであるとは限りません。ステークホルダーは、「システムがどのように動作するかに関心を持つ権利があっても、システムと直接やり取りすることはない」場合があるためです。[ 30 ]例えば、「システムの所有者、会社の取締役会、内国歳入庁や保険局などの規制機関」はすべてステークホルダーである可能性がありますが、アクターである可能性は低いでしょう。[ 30 ]
同様に、システムを利用する人物は、異なる役割を担っているため、異なるアクターとして表現される場合がある。例えば、ユーザー「ジョー」は、ATMを使って自分の口座から現金を引き出すときは顧客の役割を担い、銀行に代わってシステムを使ってレジに現金を補充するときは銀行員の役割を担うことになる。
俳優はしばしば他人のために働いている。コックバーンは、「最近では、システムのユーザーが他人のために行動していることを捉えるために、『顧客のための営業担当者』や『マーケティング部門の事務員』と書くようにしている」と書いている。これは、プロジェクトに対して、「ユーザーインターフェースとセキュリティクリアランス」は営業担当者と事務員向けに設計されるべきだが、結果に関心を持つのは顧客とマーケティング部門の役割であることを示している。[ 31 ]
利害関係者は、能動的な役割と非能動的な役割の両方を担う可能性があります。たとえば、消費者は「マスマーケットの購入者」（システムとやり取りしない）であると同時に、ユーザー（購入した製品と能動的にやり取りする行為者）でもあります。[ 32 ]また、ユーザーは「通常の操作者」（システムを本来の目的で使用する行為者）であると同時に、「機能的受益者」（システムの使用から利益を得る利害関係者）でもあります。[ 32 ]たとえば、ユーザー「ジョー」が自分の口座から現金を引き出す場合、彼は自動預け払い機を操作し、自分のために結果を得ています。
コックバーンは、システムの利害関係者、ユースケースの主要および補助（二次）アクター、設計対象システム（SuD）自体、そして最後に「内部アクター」、すなわち設計対象システムのコンポーネントの中からアクターを探すことを推奨している。[ 30 ]
ユースケースが、価値ある結果（目標）を生み出すために、ユーザー（またはその他のタイプのアクター）とシステムとの間の一連のイベントと相互作用を記述するのと同様に、ビジネスユースケースは、価値あるビジネス結果を生み出すために、ビジネスシステムとそのシステムのユーザー/アクターとの間のより一般的な相互作用を記述します。主な違いは、ビジネスユースケースモデルで考慮されるシステムには、技術システムに加えて人が含まれる場合があることです。これらの「システム内の人」は、ビジネスワーカーと呼ばれます。レストランの例では、各人をアクター（つまりシステムの外）として扱うか、ビジネスワーカー（システム内）として扱うかを決定する必要があります。以下の例に示すように、ウェイターをアクターとみなすと、レストランシステムにはウェイターは含まれず、モデルはウェイターとレストラン間の相互作用を明らかにします。別の方法としては、ウェイターをレストランシステムの一部（ビジネスワーカー）とみなし、顧客をシステムの外（アクター）とみなす方法があります。[ 33 ]
ユースケースはテキストだけでなく、必要に応じて図表でも表現されます。統一モデリング言語（ UML）では、ユースケースとアクターの関係は、イヴァル・ヤコブソンのオブジェクト表記法を基にしたユースケース図で表されます。SysMLでは、システムブロックレベルで同じ表記法が用いられます。
さらに、アクティビティ図、シーケンス図、コミュニケーション図、ステートマシン図などの他の振る舞いを表すUML図も、ユースケースを視覚化するために使用できます。具体的には、システムシーケンス図（SSD）は、外部アクターと設計対象システム（SuD）間の相互作用を示すためによく使用されるシーケンス図であり、通常はユースケースの特定のシナリオを視覚化するために用いられます。
ユースケース分析は通常、ユースケース図の作成から始まります。アジャイル開発においては、ユースケースを図示した多数のUML図と、テキストによる説明、注釈、またはユースケース概要を組み合わせた要件モデルが非常に軽量で、小規模または簡単なプロジェクトでの使用に十分です。ユースケースのテキストを補完するものとして、ユースケースの視覚的な図解表現は、複雑なシステム動作要件の理解、伝達、および設計を促進する効果的なツールにもなります。
以下は、コックバーン式テンプレートを若干修正したサンプルユースケースです。基本的なユースケース記述には、ボタン、コントロール、フォーム、その他のUI要素や操作は一切含まれておらず、基本フローや拡張機能の各ステップにおいて、ユーザーの目標、サブ目標、または意図のみが表現されている点にご注意ください。この手法により、要件仕様がより明確になり、設計と実装の柔軟性が最大限に高まります。
使用例：記事の編集
主要アクター：メンバー（登録ユーザー）
対象範囲：Wikiシステム
レベル： ！（ユーザーの目標値または海抜）
概要：（ユーザーストーリーまたはエピックに相当）
関係者
...
事後条件
前提条件：
トリガー：
基本的な流れ：
拡張機能：
2-3。
4a. タイムアウト:
...
アジャイルムーブメントの始まり以来、エクストリームプログラミングのユーザーストーリー手法は、ユースケースに代わる人気のツールとなっています。しかし、ユースケース記述の支持者は、ユースケース記述にはユーザーストーリーや他の記述よりも優れている点があると主張しています。[ 34 ]
ユーザー中心
ユースケースは、ソフトウェア要件仕様策定プロセスにおいてユーザー中心のツールとして機能し、開発者がユーザーの潜在的なニーズを検討するのに役立ちます。[ 35 ]ユースケースモデリングは通常、システムとやり取りする主要なステークホルダー（アクター）と、システムを使用することで達成したい目標や目的を特定することから始まります。これらのユーザー目標は、システムが満たすべきユースケースの構築に役立ちます。このユーザー中心のアプローチは、開発者の内部的な視点に合わせて調整するのではなく、価値がありユーザーのニーズに合致した方法でシステムが開発されることを決定することを目的としています。
ユースケース作成は、ユーザー中心設計（UCD）の分野における分析ツールです。
より良いコミュニケーション
ユースケースは、構造化されたテンプレートを用いて自然言語で記述できます。視覚的なUML図で補完された記述形式のテキストは、専門用語を最小限に抑えることで、システムの技術的な側面に関する知識レベルが異なる関係者間のコミュニケーションを改善します。
構造化された探索による品質要件
ユースケーステンプレートのフォーマットは、システム設計者がユーザーフローを段階的に追跡することで、設計を構造的に分析するのに役立ちます。これにより、設計者が見落としていた可能性のある、些細ながらもコストのかかる設計上の欠陥やシステム要件が明らかになる場合があります。ユースケースのアクションステップを最小限に抑え、最適化してユーザーの目標を達成することは、システムのインタラクションデザインとユーザーエクスペリエンスの向上にも貢献します。
テストとユーザー向けドキュメントの作成を支援する
アクションまたはイベントの流れ構造に基づいたコンテンツを持つ、適切に記述されたユースケースのモデルは、システムまたは製品のテストケースとユーザーマニュアルの設計の基礎およびガイドラインとしても機能します。ユースケースの流れのパスとテストケースの間には関連性があります。ユースケースのシナリオ（ユースケースのインスタンスの実行）を通じてユースケースから機能テストケースを導出することは簡単です。[ 36 ]
ユースケースの制限事項は以下のとおりです。
ユースケースに関するよくある誤解は以下のとおりです。
ユーザーストーリーはアジャイルだが、ユースケースはそうではない。
アジャイルとスクラムは、要求技術に関して中立です。スクラム入門書[ 41 ]にもあるように、
プロダクトバックログの項目は、明確かつ持続可能な方法であればどのような方法でも表現できます。よくある誤解とは異なり、プロダクトバックログには「ユーザーストーリー」は含まれません。単に項目が含まれているだけです。これらの項目は、ユーザーストーリー、ユースケース、またはグループが有用と考えるその他の要件定義手法で表現できます。ただし、どのような手法を用いるにせよ、ほとんどの項目は顧客への価値提供に焦点を当てるべきです。
ユースケース技術は、ユースケーススライスを使用してユースケースを段階的に充実させることで、アジャイルアプローチを考慮に入れるように進化しました。[ 15 ]
ユースケースは主に図解で表されます。
クレイグ・ラーマンは「ユースケースは図ではなく、テキストである」と強調している。[ 42 ]
ユースケースにはUI関連のコンテンツが多すぎる。
ある人たちはこう言った。
ユースケースには、ラベルやボタンの名前など、詳細な情報が含まれていることが多く、そのため、新しいシステムの要件をゼロから把握するには適していません。
初心者によくある誤解です。適切に記述されたユースケースの各ステップでは、アクターの目標や意図（機能要件の本質）を示すべきであり、通常はラベルやボタンの名前、UI操作など、ユーザーインターフェースの詳細を含めるべきではありません。これは悪い習慣であり、ユースケースの記述を不必要に複雑にし、実装を制限することになります。
新しいシステムの要件をゼロから把握する場合、ユースケース図とユースケース概要は、少なくともユーザーストーリーと同程度に軽量で、便利で価値のあるツールとしてよく使用されます。
大規模システムのユースケースを作成するのは面倒で時間の無駄だ。
ある人たちはこう言った。
ユースケースの形式では、大規模なシステム（例えばCRMシステム）を数百ページ未満で説明するのは困難です。時間がかかり、不必要な手戻り作業に時間を費やすことになるでしょう。
価値がほとんどなく、多くの手戻りが発生するような退屈なユースケースの作成に多くの時間を費やすことは、作成者のスキルが低く、効率的かつ効果的に質の高いユースケースを作成する方法についての知識が乏しいことを示す悪い兆候です。ユースケースは、反復的、漸進的、かつ進化的（アジャイル）な方法で作成する必要があります。ユースケーステンプレートを適用するということは、ユースケーステンプレートのすべてのフィールドを最初から、または特別な専用ステージ（従来のウォーターフォール開発モデルの要件定義フェーズなど）で包括的に使用して記入する必要があるという意味ではありません。
実際、RUPやCockburn（OUMメソッドでも採用されている）などの一般的なテンプレートスタイルで作成されたユースケース形式は、大規模システムの複雑な要件を捉え、分析し、文書化するための有用なツールとして、実際にその有効性が証明されています。優れたユースケースドキュメント（モデル）の品質は、そのサイズだけで判断されるべきではありません。大規模システムの質の高い包括的なユースケースモデルが数百ページにも及ぶのは、作成者の文章力の不足ではなく、対象となる問題自体の複雑さが主な原因である場合もあります。
テンプレート機能を備えたテキストエディタやワープロソフトは、ユースケースの作成によく使用されます。大規模で複雑なシステム要件の場合は、専用のユースケース作成ツールが役立ちます。
よく知られているユースケースツールには以下のようなものがあります。
ほとんどのUMLツールは、ユースケースのテキスト記述とビジュアルモデリングの両方をサポートしています。