Loading article…
ソフトウェアおよびシステム エンジニアリングにおいて、 「ユース ケース」という語句は 2 つの意味を持つ多義語です。
- ソフトウェアの使用シナリオ。ソフトウェアが役立つ可能性がある状況を示すために複数形で使用されることが多い。
- システムが外部要求 (ユーザー入力など) を受信し、それに応答する潜在的なシナリオ。
この記事では後者の意味について説明します。(他の意味の詳細については、たとえばユーザー ペルソナを参照してください。)
ユースケースは、通常、ロール (統一モデリング言語(UML)ではアクターと呼ばれる) とシステム間の相互作用を定義して目標を達成するアクションまたはイベント ステップのリストです。アクターは、人間または別の外部システムです。システム エンジニアリングでは、ユースケースはソフトウェア エンジニアリングよりも高いレベルで使用され、多くの場合、ミッションまたは利害関係者の目標を表します。詳細な要件は、システム モデリング言語(SysML) または契約ステートメントとして取り込まれます。
歴史
1987 年、Ivar Jacobson はOOPSLA '87 カンファレンスでユースケースに関する最初の論文を発表しました。 [1]彼は、この手法がEricssonでどのように使用されており、テキスト、構造、および視覚的なモデリング手法を使用してシステムの要件を捕捉および指定し、オブジェクト指向の分析と設計を推進しているかを説明しました。[2]当初、彼は使用シナリオと使用ケースという用語を使用していましたが(後者は彼のスウェーデン語の用語användningsfallの直訳です)、どちらの用語も英語では自然に聞こえないことがわかり、最終的にuse caseに落ち着きました。[3]
1992年に彼は『オブジェクト指向ソフトウェア工学 - ユースケース駆動型アプローチ』 [4]の共著者となり、OOSEシステムエンジニアリング手法の基礎を築き、特にソフトウェア開発において機能要件を捉えるユースケースの普及に貢献した。1994年には、ビジネスモデルとビジネスプロセスリエンジニアリングに適用されるユースケースとオブジェクト指向技術に関する本を出版した。[5]
同じ頃、Grady BoochとJames Rumbaugh は、それぞれBooch 法とObject Modeling Technique (OMT) というオブジェクト指向分析設計手法の統合に取り組みました。1995 年に Ivar Jacobson が加わり、ユースケース モデリングを含むUnified Modelling Language (UML) を共同で作成しました。UML は1997 年にObject Management Group (OMG)によって標準化されました。 [6] Jacobson、Booch、Rumbaugh はObjectoryソフトウェア開発プロセスの改良にも取り組みました。その結果生まれたUnified Process は1999 年に公開され、ユースケース駆動アプローチを推進しました。[7]
それ以来、多くの著者がこの技術の開発に貢献してきました。特に、 1995 年にLarry Constantine が使用中心設計の文脈で開発した「必須ユースケース」は、ユーザー インターフェイスの設計を制約したり偏らせたりする可能性のある一連のアクションやシナリオではなく、ユーザーの意図を記述することを目的としています。[8] Alistair Cockburn は、 2000 年にテキスト ナラティブと表形式の仕様に基づく目標指向のユースケース プラクティスを発表しました。[9] Kurt Bittner と Ian Spence は、2002 年にユースケースを使用して機能要件を分析するための高度なプラクティスを開発しました。[10] Dean Leffingwell と Don Widrig は、変更管理と利害関係者とのコミュニケーション活動にユースケースを適用することを提案しました。[11] Gunnar Overgaard は、2004 年にデザイン パターンの原則をユースケースに拡張することを提案しました。[12]
2011年、ジェイコブソンはイアン・スペンスとカート・ビットナーと共に、この手法をアジャイルなコンテキストに適応させ、段階的なユースケース「スライス」で強化し、開発ライフサイクル全体にわたってその使用を促進するための電子書籍「ユースケース2.0」を出版しました。 [13]その後、IIBAの年次会議でこの新しいアプローチを発表しました。[14] [15]
一般原則
ユースケースは、システムの要件を捕捉、モデル化、および指定するための手法です。[10]ユースケースは、システムがアクターとの相互作用で実行する可能性のある一連の動作に対応し、システムの目標に貢献する観察可能な結果を生成します。アクターは、人間のユーザーまたは他のシステムが相互作用で果たす役割を表します。
要件分析では、ユースケースが識別されると、そのユースケースは、その主要なアクターを表す特定のユーザー目標に従って命名されます。ケースは、テキストによる説明や、アクティビティとイベントの一般的なシーケンス、および特別な条件、例外、エラー状況などのバリエーションを説明する追加のグラフィカル モデルによってさらに詳細化されます。
ソフトウェアエンジニアリング知識体系（SWEBOK）[16]によれば、ユースケースはシナリオベースの要件抽出技術とモデルベースの分析技術に属します。しかし、ユースケースは物語ベースの要件収集、増分要件取得、システムドキュメント、受け入れテストもサポートしています。[1]
バリエーション
この技術にはさまざまな使用例とバリエーションがあります。
- システムユースケースは、開発されるシステムの要件を指定します。[2]システムユースケースの詳細な説明では、アクターとのやり取りだけでなく、処理に関与するエンティティも特定されます。システムユースケースは、さらなる分析モデルと設計活動の出発点となります。
- ビジネスユースケースは、ソフトウェアシステムではなくビジネス組織に焦点を当てています。ビジネスユースケースは、ビジネスプロセスリエンジニアリングイニシアチブのコンテキストでビジネスモデルとビジネスプロセス要件を指定するために使用されます。[5]
- 本質的なユースケースは抽象ユースケースとも呼ばれ、シーケンスを定義したりシナリオを記述したりすることなく、アクターの潜在的な意図とシステムがそれらに対処する方法を記述します。[8]このプラクティスは、ユーザー中心の設計をサポートし、システム仕様の初期段階でユーザーインターフェイスに関する偏見を誘発しないようにすることを目的として開発されました。[7]
- ユースケース 2.0 は、アジャイル開発手法のコンテキストにこの手法を適応させるために使用されます。[1]この手法は、ユーザー ストーリー ナラティブをサポートすることで、要件収集の実践を強化します。また、ユースケースの「スライス」も提供し、要件の段階的な抽出を容易にし、段階的な実装を可能にします。
範囲
ユースケースの範囲は、主題と目標によって定義できます。
- 主題は、相互作用を提供するシステム、サブシステム、またはコンポーネントを識別します。[17]
- 目標は、目標に関心のある組織レベル（会社、部門、ユーザーなど）とユーザーの目標のサブ目標への分解を考慮して、階層的に構造化することができます。[9]目標の分解は、ユーザーの観点から、システムとは独立して実行されます。これは、従来の機能分解とは異なります。[10]
使用法
ユースケースは、次のコンテキストで適用されることが知られています。
- オブジェクト指向ソフトウェアエンジニアリング（OOSE）を駆動要素として[4]
- 統一モデリング言語（UML）は、行動モデリングツールとして使用されます。[17]
- 統一ソフトウェア開発プロセス（UP）とその前身であるIBM ラショナル統一プロセス（RUP） [ 7]
- 機能要件の代替構造としてのソフトウェア要件仕様（SRS）の事前文書化[18]
- エンティティ・コントロール・境界アプローチを用いて要件から設計を導き出すこと。[7]
- アジャイル開発[1] [19 ]
テンプレート
ユースケースをテキストで記述する方法は、ユースケース概要、カジュアル、アウトライン、フルドレスなど、さまざまなテンプレートを使用して多数あります。さまざまなベンダーや専門家が考案したテンプレートでユースケースを記述することは、高品質の機能システム要件を取得するための一般的な業界の慣行です。
コックバーンスタイル
Alistair Cockburnが著書「Writing Effective Use Cases」で定義したテンプレートは、ユースケースの記述スタイルとして最も広く使用されているものの 1 つです。[引用が必要]
設計範囲
コックバーンは、各ユースケースに「設計範囲」を示すシンボルを付けることを提案している。シンボルはブラックボックス（内部の詳細が隠されている）またはホワイトボックス（内部の詳細が示されている）である。5つのシンボルが利用可能である：[20]
他の著者は組織レベルのユースケースを「ビジネスユースケース」と呼ぶこともあります。[21]
目標レベル
コックバーンは、各ユースケースに「目標レベル」を示す記号を付けることを提案している。[22]推奨されるレベルは「ユーザー目標」（または口語的には「海面」[23] ：101 ）である。
テキストの記述では、ユースケース名の後に代替テキスト記号 (! +、- など) を続けると、レベルを示すより簡潔で便利な方法になることがあります (例: place an order!、login- ) 。
完全に服を着た
コックバーンはユースケースのより詳細な構造を説明していますが、詳細が必要ない場合は簡略化することを許可しています。彼の完全なユースケーステンプレートには、次のフィールドがリストされています。[24]
- タイトル: 「主たる行為者の目標を名付ける能動態動詞目標句」[25]
- 主演俳優
- 文脈における目標
- 範囲
- レベル
- 利害関係者と利害関係者
- 前提条件
- 最低限の保証
- 成功の保証
- トリガー
- 主な成功シナリオ
- 拡張機能
- テクノロジーとデータのバリエーションリスト
さらに、コックバーンは、各ユースケースの性質を示すために、設計範囲と目標レベルのアイコンという 2 つの手段を使用することを提案しています。
コックバーンのアプローチは他の著者にも影響を与えている。例えば、アレクサンダーとベウス・デュキッチはコックバーンの「完全なユースケース」テンプレートをソフトウェアからあらゆる種類のシステムに一般化しているが、以下の分野はコックバーンと異なる。[26]
- バリエーションシナリオ「（メインシナリオから分岐したり、メインシナリオに戻ったりすることもある）」
- 例外「つまり例外イベントとその例外処理シナリオ」
カジュアル
コックバーンは、プロジェクトが必ずしも詳細な「完全な」ユースケースを必要としないことを認識している。彼は、フィールドを使用したカジュアルユースケースを次のように説明している。[24]
- タイトル（目標）
- 主演俳優
- 範囲
- レベル
- (ストーリー): ユースケースの本文は、何が起こるかを非公式に説明する 1 ～ 2 段落のテキストです。
ファウラースタイル
マーティン・ファウラーは「ユースケースの内容を書く標準的な方法は存在せず、さまざまなケースで異なる形式がうまく機能する」と述べています。[23] : 100 彼は「使用する共通のスタイル」を次のように説明しています。[23] : 101
- タイトル: 「ユースケースが満たそうとしている目標」[23] : 101
- 主な成功シナリオ：ステップの番号付きリスト[23] ： 101
- ステップ：「行為者とシステムの間の相互作用の簡単な記述」[23] ：101
- 拡張機能：拡張機能ごとに1つの番号付きリスト[23] ：101
- 拡張: 「主な成功シナリオとは異なる相互作用をもたらす条件」。メインステップ3からの拡張は3aなどと番号が付けられます。[23] : 101
Fowler スタイルは、Cockburn テンプレートの簡略化されたバリエーションとして見ることもできます。このバリエーションは、ユーザー ストーリーと呼ばれます。
アリスター・コックバーンは次のように述べている。[27]
ユーザー ストーリーを 2 ビットの精度のユース ケースとして考えてみましょう。精度のビット 1 はユース ケースの目標を指定し、ビット 2 はメイン シナリオを追加します。ビット 3 は失敗条件を追加し、ビット 4 は失敗アクションを追加します。ビット 5 は入出力データのデータ記述を追加します。メッセージの受信者のモデルも含まれている Catalysis は、精度の 6 ビット目に位置づけます。Catalysis ファミリーでは、異なる基盤を持つプロジェクトが、異なる精度レベルでケースを使用します。方法論的に軽いプロジェクトはユーザー ストーリーを使用し、方法論的に重いプロジェクトは 4 ビットの精度でユース ケースを使用し、Catalysis は 6 ビットの精度を使用します。
マーティン・ファウラーは次のように述べている。[27]
重要なのは、人々がケースをどのように使用するかです。私は、多くの人が非常に形式化された方法でケースを使用しているのを見てきました。Kent は、はるかにわかりやすい方法で UserStories を作成しています。私は、Kent が UserStories を作成するのと同じようにケースを使用しています。他の開発者とよりよくコミュニケーションをとり、より軽量なアプローチを使用するように影響を与えるために、ケースを使用するように呼びかけています。
俳優
ユースケースは、外部のアクターと検討中のシステムとの間の、目標を達成するための相互作用を定義します。アクターは意思決定を行う能力が必要ですが、人間である必要はありません。「アクターは、人、会社または組織、コンピュータ プログラム、またはコンピュータ システム (ハードウェア、ソフトウェア、またはその両方) である可能性があります。」[28]アクターは常に利害関係者ですが、すべての利害関係者がアクターであるわけではありません。なぜなら、利害関係者は「システムの動作を気にする権利があるにもかかわらず、システムと直接やり取りしない可能性がある」ためです。[28]たとえば、「システムの所有者、会社の取締役会、および国税庁や保険局などの規制機関」はすべて利害関係者である可能性がありますが、アクターである可能性は低いです。[28]
同様に、システムを使用する人物は、異なる役割を演じているため、異なるアクターとして表されることがあります。たとえば、ユーザー「ジョー」は、ATM を使用して自分の口座から現金を引き出すときは顧客の役割を果たし、システムを使用して銀行に代わって現金引き出し口に現金を補充するときは銀行出納係の役割を果たします。
俳優はしばしば他の誰かのために働きます。コックバーンは「最近はシステムのユーザーが他の誰かのために行動していることを示すために『顧客のための営業担当者』や『マーケティング部門の事務員』と書いています」と書いています。これはプロジェクトに「ユーザーインターフェイスとセキュリティクリアランス」は営業担当者と事務員のために設計されるべきであり、顧客とマーケティング部門は結果に関係する役割であることを示しています。[29]
ステークホルダーは、能動的な役割と非能動的な役割の両方を担うことができます。たとえば、消費者は「マスマーケットの購入者」（システムとやり取りしない）であると同時にユーザー（購入した製品と積極的にやり取りするアクター）でもあります。[30]一方、ユーザーは「通常のオペレーター」（システムを本来の目的のために使用するアクター）であると同時に「機能的受益者」（システムの使用から利益を得るステークホルダー）でもあります。[30]たとえば、ユーザー「ジョー」が自分の口座から現金を引き出すとき、彼はATMを操作し、自分のために結果を得ています。
コックバーンは、システムの利害関係者、ユースケースの主要および補助的（二次的）アクター、設計対象システム（SuD）自体、そして最後に「内部アクター」、つまり設計対象システムのコンポーネントの中からアクターを探すことを勧めている。[28]
ビジネスユースケース
ユースケースが、価値ある結果 (目標) を生み出すために、ユーザー (または他のタイプのアクター) とシステムの間の一連のイベントとインタラクションを記述するのと同じように、ビジネスユースケースは、ビジネスシステムとそのシステムのユーザー/アクターの間の、価値あるビジネス結果を生み出すためのより一般的なインタラクションを記述します。主な違いは、ビジネスユースケースモデルで考慮されるシステムには、技術システムに加えて人が含まれる場合があることです。これらの「システム内の人」は、ビジネスワーカーと呼ばれます。レストランの例では、各人をアクター (つまりシステム外) として扱うか、ビジネスワーカー (システム内) として扱うかを決定する必要があります。以下の例に示すように、ウェイターがアクターと見なされる場合、レストランシステムにはウェイターは含まれず、モデルはウェイターとレストランのインタラクションを公開します。別の方法としては、ウェイターをレストランシステムの一部 (ビジネスワーカー) と見なし、クライアントをシステム外 (アクター) と見なす方法があります。[31]
ビジュアルモデリング
ユースケースはテキストだけでなく、必要に応じてダイアグラムにもなります。統一モデリング言語では、ユースケースとアクターの関係は、もともとIvar JacobsonのObjectory表記法に基づいたユースケース ダイアグラムで表現されます。SysMLは、システム ブロック レベルで同じ表記法を使用します。
さらに、アクティビティ図、シーケンス図、コミュニケーション図、ステートマシン図などの他の動作 UML 図も、ユースケースを視覚化するために使用できます。具体的には、システム シーケンス図(SSD) は、外部アクターと設計対象システム (SuD) 間の相互作用を示すためによく使用されるシーケンス図で、通常はユースケースの特定のシナリオを視覚化するために使用されます。
ユースケース分析は通常、ユースケース図を描くことから始まります。アジャイル開発の場合、ユースケースを表す多数の UML 図と、いくつかのテキストによる説明、メモ、またはユースケース概要からなる要件モデルは非常に軽量で、小規模または簡単なプロジェクトで使用するには十分です。ユースケースのテキストをうまく補完するものとして、ユースケースの視覚的な図表現は、複雑なシステムの動作要件をよりよく理解し、伝達し、設計するための効果的な促進ツールでもあります。
例
以下は、Cockburn スタイルのテンプレートを少し変更したバージョンで記述されたサンプル ユース ケースです。基本的なユース ケースの説明には、ボタン、コントロール、フォーム、その他の UI 要素や操作はなく、基本フローまたは拡張機能の各ステップでユーザーの目標、サブ目標、または意図のみが表現されていることに注意してください。この方法により、要件仕様がより明確になり、設計と実装の柔軟性が最大限に高まります。
使用例: 記事を編集する
主な出演者：会員（登録ユーザー）
対象範囲: Wikiシステム
レベル: ! (ユーザーの目標または海抜)
概要: (ユーザーストーリーまたはエピックに相当)
- メンバーは読んでいる記事の任意の部分（記事全体または一部）を編集します。編集中はプレビューと変更の比較が可能です。
ステークホルダー
...
事後条件
- 最低限の保証:
- 成功保証:
- 記事が保存され、更新されたビューが表示されます。
- 記事の編集記録はシステムによって作成されるため、記事のウォッチャーは後で更新について通知を受けることができます。
前提条件:
- 編集が有効になっている記事がメンバーに表示されます。
トリガー:
- メンバーは記事に対して編集リクエスト（記事全体または 1 つのセクションのみ）を呼び出します。
基本的な流れ：
- システムでは、メンバーが編集するための有益な編集概要とともに、記事の関連コンテンツがすべて入力された新しいエディター領域/ボックスが提供されます。メンバーがレポートのセクションのみを編集したい場合は、セクションの元のコンテンツのみが表示され、セクションのタイトルは編集概要に自動的に入力されます。
- メンバーは満足するまで記事の内容を修正します。
- メンバーは編集概要を記入し、この記事を監視するかどうかをシステムに伝え、編集を送信します。
- システムは記事を保存し、編集イベントをログに記録し、必要な後処理を完了します。
- システムは、記事の更新されたビューをメンバーに提示します。
拡張機能:
2～3.
- a. プレビューを表示:
- メンバーは「プレビューを表示」を選択して、変更されたコンテンツを送信します。
- システムは、プレビュー用にレンダリングされた更新されたコンテンツを追加して手順 1 を再実行し、メンバーに編集内容がまだ保存されていないことを通知してから続行します。
- b. 変更を表示:
- メンバーは「変更を表示」を選択し、変更されたコンテンツを送信します。
- システムは、メンバーによる現在の編集と記事の最新の保存バージョンとの相違点を比較した結果を表示してステップ 1 を再実行し、続行します。
- c. 編集をキャンセルします。
- メンバーは「キャンセル」を選択します。
- システムはメンバーが行った変更をすべて破棄し、ステップ 5 に進みます。
4a. タイムアウト:
...
利点
アジャイル運動が始まって以来、エクストリームプログラミングのユーザーストーリー手法は非常に人気があり、多くの人がそれがすべてのプロジェクトのアジャイル要件に対する唯一かつ最良のソリューションだと考えています。アリスター・コックバーンは、アジャイル開発でユースケースを今でも書く理由を5つ挙げています。[32]
- 目標名のリストは、システムが提供する内容 (ユーザー ストーリーも含む) の最も短い概要を提供します。また、初期の優先順位、見積もり、チームの割り当て、タイミングを作成するために使用されるプロジェクト計画の骨組みも提供します。
- 各ユースケースの主な成功シナリオは、システムが基本的に何を実行し、何を実行しないかについて関係者全員に合意をもたらします。また、特定の項目の要件ごとにコンテキスト (詳細なユーザー ストーリーなど) を提供しますが、これは他では非常に入手が難しいコンテキストです。
- 各ユースケースの拡張条件は、開発時間と予算の 80% を占める、些細で厄介な問題をすべて調査するためのフレームワークを提供します。これは先読みメカニズムを提供するため、関係者は回答を得るのに長い時間がかかりそうな問題を特定できます。これらの問題はスケジュールより前倒しにすることができ、そうすべきです。そうすれば、開発チームが作業に取り掛かるときには回答が準備できます。
- ユース ケース拡張シナリオ フラグメントは、多くの詳細で、しばしば扱いにくく、無視されているビジネス上の質問、「この場合、何をすべきか?」に対する回答を提供します。これは、プログラマーが問題をじっくり考えるのに役立つ if...then...else ステートメントに一致する思考/ドキュメント フレームワークです。ただし、これはプログラミング時ではなく調査時に行われます。
- 完全なユースケース セットは、調査員がすべてのユーザーのニーズ、システムに関するすべての目標、および関連するすべてのビジネス バリアントについて検討したことを示しています。
要約すると、ユースケースでシステム要件を指定すると、従来のアプローチや他のアプローチと比較して、次のような明らかな利点があります。
ユーザー重視
ユースケースは、ソフトウェア要件定義プロセスのための強力でユーザー中心のツールです。[33]ユースケースモデリングは通常、システムとやりとりする主要な利害関係者の役割 (アクター) と、システムが満たさなければならない彼らの目標または目的 (外部の視点) を特定することから始まります。これらのユーザーの目標は、システムによって提供される望ましい機能的特徴またはサービスを表すユースケースの名前またはタイトルの理想的な候補になります。このユーザー中心のアプローチにより、開発者またはシステム (内部) の観点から推測された些細な機能ではなく、実際のビジネス価値がありユーザーが本当に望んでいるものが開発されます。
ユースケースの作成は、長年にわたり、 ユーザー中心設計 (UCD)の分野において重要かつ価値のある分析ツールとなっています。
より良いコミュニケーション
ユースケースは、多くの場合、構造化されたテンプレートを使用して自然言語で記述されます。この物語形式のテキスト形式 (読みやすい要件ストーリー) は、ほぼすべての人が理解でき、視覚的な UML 図で補完されているため、顧客、エンドユーザー、開発者、テスト担当者、管理者など、すべての関係者間のコミュニケーションがより良く、より深くなります。コミュニケーションが改善されると、品質要件が実現され、品質の高いシステムが提供されます。
構造化された探索による品質要件
ユースケースの最も強力な点の 1 つは、ユースケース テンプレートの形式、特にメインの成功シナリオ (基本フロー) と拡張シナリオ フラグメント (拡張、例外、代替フロー) にあります。前提条件から事後条件までユースケースを段階的に分析し、基本から拡張までユースケース フローのすべてのアクション ステップを調査および調査して、扱いにくく、通常は隠れて無視され、一見些細なようで実際にはコストがかかることが多い要件 (Cockburn が上で述べたように) を特定することは、明確で安定した品質の要件を体系的に得るための構造化された有益な方法です。
ユーザーの目標を達成するためにユースケースのアクション ステップを最小限に抑えて最適化することは、システムの インタラクション デザインとユーザー エクスペリエンスの向上にも貢献します。
テストとユーザードキュメントの作成を容易にする
アクションまたはイベントのフロー構造に基づいたコンテンツを備えた、よく書かれたユースケースのモデルは、システムまたは製品のテストケースとユーザーマニュアルの設計のための優れた基礎と貴重なガイドラインとしても機能し、事前の投資に見合う価値があります。ユースケースのフローパスとテストケースの間には明らかなつながりがあります。ユースケースのシナリオ（ユースケースのインスタンスの実行）を通じてユースケースから機能テストケースを導き出すのは簡単です。[34]
制限事項
使用例の制限は次のとおりです。
- ユースケースは、システムの非相互作用ベースの要件 (アルゴリズムや数学的要件など) や非機能要件(プラットフォーム、パフォーマンス、タイミング、安全性が重要な側面など) を捕捉するのにはあまり適していません。これらは、他の場所で宣言的に指定する方が適切です。
- ユースケースの完全に標準的な定義は存在しないため、各プロジェクトは独自の解釈を形成する必要があります。
- extendsなどのユースケース関係は解釈が曖昧で、Cockburnが指摘したように利害関係者が理解するのが難しい場合があります（問題＃6）[35] [引用が必要]
- ユースケース開発者は、ユースケースに組み込むユーザー インターフェイス(UI) の依存関係のレベルを判断するのが難しいと感じることがよくあります。ユースケース理論では、UI をユースケースに反映しないことが推奨されていますが、設計のこの側面を抽象化すると、ユースケースを視覚化するのが難しくなるため、扱いにくい場合があります。ソフトウェア エンジニアリングでは、この困難は、要件のトレーサビリティ(たとえば、トレーサビリティ マトリックス)を適用することで解決されます。UI 要素をユースケースに関連付ける別の方法は、ユースケースの各ステップに UI デザインを添付することです。これは、ユースケース ストーリーボードと呼ばれます。
- ユースケースは過度に強調されることがあります。Bertrand Meyerは、システム設計をユースケースからあまりにも文字通りに推進することや、ユースケースを他の潜在的に価値のある要件分析手法を排除して使用することなどの問題について論じています。[36]
- ユースケースはテスト設計の出発点であるが[37]、各テストには独自の成功基準が必要であるため、各パスに個別の事後条件を提供するようにユースケースを変更する必要があるかもしれない。[38]
- ユースケースには目標とコンテキストが含まれますが、これらの目標と目標の背後にある動機 (利害関係者の懸念と非相互作用を含む評価) が他のシステム目標と競合するか、または悪影響または好影響を与えるかどうかは、目標指向の要件モデリング手法 ( BMM、I*、KAOS、ArchiMate ARMOR など) の対象となります。
誤解
ユースケースに関するよくある誤解は次のとおりです。
ユーザーストーリーはアジャイルですが、ユースケースはアジャイルではありません。
アジャイルとスクラムは要件定義手法に関しては中立である。スクラム入門書[39]には次のように記されている。
製品バックログ項目は、明確かつ持続可能な方法で表現されます。一般的な誤解とは異なり、製品バックログには「ユーザー ストーリー」は含まれません。含まれるのは項目だけです。これらの項目は、ユーザー ストーリー、ユース ケース、またはグループが有用と考えるその他の要件アプローチとして表現できます。ただし、アプローチが何であれ、ほとんどの項目は顧客に価値を提供することに重点を置く必要があります。
ユースケース技術は、ユースケーススライスを使用してユースケースを段階的に強化することで、アジャイルアプローチを考慮に入れるように進化してきました。[13]
ユースケースは主に図表です。
クレイグ・ラーマンは「ユースケースは図ではなくテキストである」と強調している。[40]
ユースケースには UI 関連のコンテンツが多すぎます。
ある人が言うように、[誰？ ]
ユースケースには、多くの場合、あるレベルの詳細 (ラベルやボタンの命名など) が含まれるため、新しいシステムの要件を最初から把握するのにはあまり適していません。
初心者の誤解。適切に記述されたユースケースの各ステップでは、アクターの目標または意図 (機能要件の本質) を示す必要があり、通常、ラベルやボタンの名前、UI 操作などのユーザー インターフェイスの詳細を含めるべきではありません。これは悪い習慣であり、ユースケースの記述を不必要に複雑にし、実装を制限することになります。
新しいシステムの要件を最初から把握する場合、ユースケース図とユースケース概要は、少なくともユーザーストーリーと同じくらい軽量な便利で価値のあるツールとしてよく使用されます。[引用が必要]
大規模システムのユースケースを書くのは面倒で時間の無駄です。
ある人が言うように、[誰？ ]
ユースケースの形式により、数百ページ未満で大規模なシステム (CRM システムなど) を説明することが困難になります。時間がかかり、不必要な量のやり直しに時間を費やすことになります。
[要出典]
価値をほとんど追加しない、または追加しない、そして多くのやり直しにつながる退屈なユースケースの作成に多くの時間を費やすことは、作成者のスキルが十分でなく、質の高いユースケースを効率的かつ効果的に作成する方法に関する知識がほとんどないことを示す悪臭です。ユースケースは、反復的、増分的、進化的 (アジャイル) な方法で作成する必要があります。ユースケース テンプレートを適用するということは、ユースケース テンプレートのすべてのフィールドを最初から、または特別な専用ステージ (従来のウォーターフォール開発モデルの要件フェーズなど) で包括的に使用して入力する必要があるということではありません。
実際、RUP や Cockburn ( OUM メソッドでも採用) などの一般的なテンプレート スタイルで作成されたユース ケース フォーマットは、大規模システムの複雑な要件を捕捉、分析、文書化するための価値ある便利なツールであることが実証されています。優れたユース ケース ドキュメント (モデル)の品質は、そのサイズだけで判断すべきではありません。大規模システムの高品質で包括的なユース ケース モデルが、作成者の文章作成スキルの低さではなく、主に問題の複雑さが原因で、最終的に数百ページに及ぶ可能性もあります。 [要出典]
ツール
ユースケースの作成には、テンプレートをサポートする テキスト エディターやワード プロセッサがよく使用されます。大規模で複雑なシステム要件の場合は、専用のユースケース ツールが役立ちます。
よく知られているユースケース ツールには次のようなものがあります。
- ケース完了
- エンタープライズアーキテクト
- マジックドロー
- Rational Softwareの RequisitePro は、1990 年代の初期のよく知られたユース ケースおよび要件管理ツールの 1 つです。
- ソフトウェアアイデアモデラー
- Wiki ソフトウェア- チームが共同でユースケースを作成および管理するための優れたツール。
ほとんどのUML ツールは、ユースケースのテキスト記述と視覚的なモデリングの両方をサポートしています。
参照
参考文献
- ^ abcd Dr. Ivar Jacobson、Ian Spence、Kurt Bittner (2011 年 12 月)。「Use-Case 2.0 ebook」。Ivar Jacobson International。p . 4。2020年8 月 9 日閲覧。
- ^ ab Jacobson, Ivar (1987 年 12 月 1 日). 「産業環境におけるオブジェクト指向開発」. ACM SIGPLAN Notices . 22 (12): 183–191. doi :10.1145/38807.38824.
- ^ Cockburn, Alistair (2002 年 3 月). 「ユースケース、10 年後」. Alistair.cockburn.us . Alistair Cockburn. 2008 年 9 月 15 日時点のオリジナルよりアーカイブ。2013年4 月 17 日閲覧。
- ^ アブ ・ヤコブソン・イーヴァル;クリスターソン・マグナス。ヨンソン・パトリック;エバーガード・グンナール (1992)。オブジェクト指向ソフトウェア エンジニアリング: ユースケース主導のアプローチ。 ACMプレス。ISBN 0-201-54435-0. OCLC 26132801.
- ^ ab Jacobson, Ivar.; Ericsson, Maria; Jacobson, Agneta (1995).オブジェクトアドバンテージ: オブジェクトテクノロジーによるビジネスプロセスリエンジニアリング。Addison -Wesley。ISBN 0-201-42289-1. OCLC 32276135.
- ^ 「統一モデリング言語仕様バージョン2.5.1について」www.omg.org 。 2020年8月9日閲覧。
- ^ abcd Jacobson, Ivar; Booch, Grady; Rumbaugh, Jim (1999).統合ソフトウェア開発プロセスマサチューセッツ州レディング: Addison-Wesley. ISBN 0-201-57169-2. OCLC 636807532.
- ^ ab Constantine, Larry L. (1995 年 4 月 1 日). 「エッセンシャルモデリング: ユーザーインターフェイスのユースケース」. Interactions . 2 (2): 34–46. doi :10.1145/205350.205356. S2CID 17209049.
- ^ ab コックバーン、アリスター。(2001) 効果的なユースケースの書き方。Addison- Wesley。ISBN 0-201-70225-8. OCLC 44046973.
- ^ abc Bittner, Kurt (2003).ユースケースモデリング. Spence, Ian. Addison Wesley. ISBN 0-201-70913-9. OCLC 50041546.
- ^ Leffingwell, Dean. (2003).ソフトウェア要件の管理: ユースケースアプローチ. Widrig, Don. (第2版). Addison-Wesley. ISBN 0-321-12247-X. OCLC 51653240.
- ^ オーヴァーガード、グンナール;パルムクヴィスト、カリン (2005)。ユースケース: パターンとブループリント。インディアナ州インディアナポリス：アディソン・ウェスリー。ISBN 0-13-145134-0. OCLC 59554401.
- ^ ab Jacobson, Ivar ; Spence, Ian; Bittner, Kurt (2011 年 12 月)。「ユース ケース 2.0: ユース ケースで成功するためのガイド」Ivar Jacobson International。2014年5 月 5 日閲覧。
- ^ 「Business Analysis Conference Europe 2011 - 2011年9月26日～28日、ロンドン、英国」Irmuk.co.uk。2013年6月17日時点のオリジナルよりアーカイブ。2013年4月17日閲覧。
- ^ 「Use-Case 2.0 プレゼンテーション」。Ivar Jacobson International。2011年9月27日。 2020年8月9日閲覧。
- ^ Bourque, Pierre; Fairley, RE (Richard E.) (2014). SWEBOK: ソフトウェア エンジニアリング知識体系ガイド(バージョン 3.0 版). IEEE Computer Society. pp. 1-6 から 1-8. ISBN 978-0-7695-5166-1. OCLC 880350861.
- ^ ab Object Management Group (2017). 「Unified Modeling Language 仕様バージョン 2.5.1」www.omg.org . 2020 年8 月 16 日閲覧。
- ^ Wiegers, Karl Eugene (2010)。ソフトウェア要件の詳細: 厄介な問題と実践的なアドバイス。Microsoft Press。第 11 章。ISBN 978-0-7356-2267-8. OCLC 73814167.
- ^ Ambler, Scott (2004). 「システムユースケース: アジャイル入門」. agilemodeling.com . 2020年8月16日閲覧。
- ^ Cockburn、2001年。表紙内側。アイコン「デザインの範囲」。
- ^ スザンヌ・ロバートソン。要件発見のシナリオ。Alexander and Maiden、2004年、第3章。39-59ページ。
- ^ Cockburn、2001年。表紙の内側。アイコン「目標レベル」。
- ^ abcdefgh ファウラー、2004年。
- ^ コックバーン、2001年、120ページ。
- ^ Cockburn、2001 年。裏表紙の内側。フィールド「ユース ケース タイトル」。
- ^ Alexander と Beus-Dukic、2009。121 ページ
- ^ ab 「ユーザーストーリーとユースケースの比較」。2024年1月19日閲覧。
- ^ abcd Cockburn、2001年、53ページ。
- ^ コックバーン、2001年、55ページ。
- ^ ab Alexander と Beus-Dukic、2009。39 ページ。
- ^ Eriksson, Hans-Erik (2000). UML によるビジネスモデリング. ニューヨーク: Wiley Computer Publishing. pp. 52. ISBN 0-471-29551-5。
- ^ コックバーン、アリスター (2008 年 1 月 9 日)。「なぜ私はまだケースを使用するのか」。alistair.cockburn.us。
- ^ Karl Wiegers (1997 年 3 月)。「顧客の声を聞く」。プロセスの影響。ソフトウェア開発。
- ^ Peter Zielczynski (2006 年 5 月)。「ユース ケースからテスト ケースへのトレーサビリティ」IBM developerWorks。
- ^ 「Alistair.Cockburn.us - 目標を設定したユースケースの構造化」。alistair.cockburn.us 。 2018年3月16日閲覧。
- ^ マイヤー、2000年。（ページが必要）
- ^ Armour and Miller、2000年。（ページが必要）
- ^ Denney、2005年（ページが必要）
- ^ ピート・ディーマー;ガブリエル・ベネフィールド;クレイグ・ラーマン。 Bas Vodde (2012 年 12 月 17 日)。 「スクラム入門: スクラムの理論と実践への軽量ガイド (バージョン 2.0)」。情報Q.
- ^ Larman, Craig (2005). UML とパターンの適用. Prentice Hall. pp. 63–64. ISBN 0-13-148906-2。
さらに読む
- Alexander, Ian、および Beus-Dukic, Ljerka。要件の発見: 製品とサービスの仕様決定方法。Wiley、2009 年。
- Alexander, Ian、Maiden, Neil.シナリオ、ストーリー、ユースケース。Wiley 2004 年。
- Armour、Frank、Granville Miller 共著。『高度なユースケースモデリング: ソフトウェア システム』Addison-Wesley、2000 年。
- Kurt Bittner、Ian Spence、「ユースケースモデリング」、Addison-Wesley Professional、2002 年 8 月 20 日。
- コックバーン、アリスター。効果的なユースケースの書き方。Addison -Wesley、2001 年。
- Larry Constantine、Lucy Lockwood、『Software for Use: 使用中心設計の基本モデルと方法の実践ガイド』、Addison-Wesley、1999 年。
- Denney, Richard.ユースケースで成功する: スマートに作業して品質を実現する. Addison-Wesley、2005 年。
- ファウラー、マーティン。UML Distilled (第 3 版)。Addison-Wesley、2004 年。
- Jacobson Ivar、Christerson M.、Jonsson P.、Övergaard G.、「オブジェクト指向ソフトウェア エンジニアリング - ユース ケース主導のアプローチ」、Addison-Wesley、1992 年。
- Jacobson Ivar、Spence I.、Bittner K. 『ユースケース 2.0: ユースケースで成功するためのガイド』、IJI SA、2011 年。
- Dean Leffingwell、Don Widrig、「ソフトウェア要件の管理: ユースケースアプローチ」、Addison-Wesley Professional。2012 年 12 月 7 日。
- Kulak、Daryl、Eamonn Guiney。ユースケース: コンテキスト内の要件。Addison -Wesley、2012 年。
- マイヤー、ベルトラン。オブジェクト指向ソフトウェア構築（第 2 版）。Prentice Hall、2000 年。
- Schneider, Geri および Winters, Jason P. 『ユースケースの適用 2 版: 実践ガイド』Addison-Wesley、2001 年。
- Wazlawick, Raul S. 情報システムのためのオブジェクト指向分析と設計: UML、OCL、IFML によるモデリング. Morgan Kaufmann、2014 年。
外部リンク
- Alistair Cockburnによるユースケース コラムと基本ユースケース テンプレート
- GSAの Usability.govでのユースケース
- Academia.eduにおけるステークホルダー分析のユースケースの適用「Project Icarus」
- IBM Developer で「ユースケース」を検索