使用事例

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

Wikiシステム非常に単純な使用例図。

ソフトウェアおよびシステム エンジニアリングでは、ユース ケースというフレーズは2 つの意味を持つ多義体です。

  1. ソフトウェアの使用シナリオ。ソフトウェアの一部が役立つ可能性がある状況を示唆するために複数形で使用されることがよくあります。
  2. システムが外部要求 (ユーザー入力など) を受け取り、それに応答する潜在的なシナリオ。

この記事では、後者の意味について説明します。

ユースケースは、通常、目標を達成するためのロール (統一モデリング言語(UML) ではアクターとして知られている) とシステムの間の相互作用を定義するアクションまたはイベント ステップのリストですアクターは、人間または他の外部システムです。システム エンジニアリングでは、ユース ケースはソフトウェア エンジニアリングよりも高いレベルで使用され、多くの場合、ミッションや利害関係者の目標を表します。詳細な要件は、システム モデリング言語(SysML) または契約書として取り込まれます。

歴史

1987 年、Ivar JacobsonはOOPSLA '87 カンファレンスでユース ケースに関する最初の記事を発表しました。[1]彼は、エリクソンでこの手法を使用して、テキスト、構造、および視覚的なモデリング手法を使用してシステムの要件を把握および指定し、オブジェクト指向の分析と設計を推進する方法について説明しました。[2]当初、彼は使用シナリオ使用ケースという用語(後者は彼のスウェーデン語であるanvändningsfallの直訳) を使用していましたが、これらの用語のどちらも英語では自然に聞こえないことがわかり、最終的に使用ケースに落ち着きました。[3]

1992 年には、オブジェクト指向ソフトウェア エンジニアリング - ユース ケース駆動型アプローチ[4]という本を共著しOOSEシステム エンジニアリング手法の基礎を築き、特にソフトウェア開発において機能要件を把握するためのユース ケースの普及に貢献しました1994 年に、ビジネス モデルビジネス プロセスのリエンジニアリングに適用されるユース ケースとオブジェクト指向技術に関する本を出版しました[5]

同時に、Grady BoochJames Rumbaughは、オブジェクト指向の分析と設計手法であるBooch メソッドオブジェクト モデリング手法 (OMT)の統合に取り組みました。1995 年に Ivar Jacobson が参加し、ユース ケース モデリングを含む統一モデリング言語 (UML)を共同で作成しました。UML は、1997 年にObject Management Group (OMG)によって標準化されました。 [6] Jacobson、Booch、および Rumbaugh も、 Objectoryソフトウェア開発プロセスの改良に取り組みました。その結果、統一プロセスが 1999 年に公開され、ユース ケース主導のアプローチが促進されました。[7]

それ以来、多くの著者がこの手法の開発に貢献してきました。特に: ラリー・コンスタンティンは、1995 年に使用中心設計のコンテキストで開発しました。これは、一連のアクションではなくユーザーの意図を説明することを目的とした、いわゆる「必須のユース ケース」です。または、ユーザー インターフェイスのデザインを制約またはバイアスする可能性のあるシナリオ。[8] Alistair Cockburnは 2000 年に、テキストの説明と表形式の仕様に基づいた目標指向のユース ケース プラクティスを発表しました。[9] Kurt Bittner と Ian Spence は、2002 年にユース ケースを使用して機能要件を分析するための高度な手法を開発しました。[10]Dean Leffingwell と Don Widrig は、ユース ケースを変更管理と利害関係者とのコミュニケーション活動に適用することを提案しました。[11] Gunnar Overgaard は 2004 年に、デザイン パターンの原則をユース ケースに拡張することを提案しました。[12]

2011 年、Jacobson は Ian Spence と Kurt Bittner と共に電子ブックUse Case 2.0を発行して、この手法をアジャイル コンテキストに適応させ、段階的なユース ケースの「スライス」で強化し、開発ライフサイクル全体でその使用を促進しました[ 13]。年次IIBA会議での新たなアプローチ。[14] [15]

一般原則

ユース ケースは、システムの要件をキャプチャ、モデル化、および指定するための手法です。[10]ユースケースは、システムがそのアクターとの相互作用で実行する可能性があり、その目標に貢献する観察可能な結果を​​生成する一連の動作に対応します。アクターは、対話において人間のユーザーまたは他のシステムが持つ役割を表します。

要件分析では、識別時に、ユース ケースは、その主要なアクターに対してそれが表す特定のユーザー目標に従って名前が付けられます。ケースは、テキストによる説明、またはアクティビティとイベントの一般的な順序を説明する追加のグラフィカル モデル、および特殊な条件、例外、エラー状況などのバリアントを使用して、さらに詳しく説明されます。

Software Engineering Body of Knowledge (SWEBOK)によると[16]ユース ケースは、シナリオ ベースの要件抽出手法と、モデル ベースの分析手法に属します。ただし、ユースケースは、説明に基づく要件の収集、段階的な要件の取得、システムのドキュメント、および受け入れテストもサポートしています。[1]

バリエーション

この手法には、さまざまな種類のユース ケースとバリエーションがあります。

  • システム ユース ケースは、開発するシステムの要件を指定します。[2]詳細な説明では、アクターとのやり取りだけでなく、処理に関与するエンティティも特定します。これらは、さらなる解析モデルと設計活動の出発点です。
  • ビジネス ユース ケースは、ソフトウェア システムではなく、ビジネス組織に焦点を当てています。これらは、ビジネス プロセス リエンジニアリング イニシアチブのコンテキストで、ビジネス モデルとビジネス プロセス要件を指定するために使用されます。[5]
  • エッセンシャル ユース ケース (抽象的なユース ケースとも呼ばれます) は、アクターの潜在的な意図と、システムがこれらにどのように対処するかを記述します。シーケンスの定義やシナリオの記述は必要ありません。[8]このプラクティスは、ユーザー中心の設計をサポートし、システム仕様の初期段階でユーザー インターフェイスに関するバイアスを誘発することを回避する目的で開発されました。[7]
  • ユース ケース 2.0 では、この手法をアジャイル開発手法のコンテキストに適合させています。[1]この手法は、ユーザー ストーリーの説明をサポートすることで、要件収集の実践を強化します。また、ユースケースの「スライス」を提供して、要件の漸進的な抽出を容易にし、漸進的な実装を可能にします。

スコープ

ユースケースの範囲は、主題と目標によって定義できます。

  • サブジェクトは、相互作用を提供するシステム、サブシステム、またはコンポーネントを識別します。[17]
  • 目標は、目標に関心のある組織レベル (会社、部門、ユーザーなど) と、ユーザーの目標のサブ目標への分解を考慮して、階層的に構造化できます。[9]目標の分解は、従来の機能分解とは異なり、ユーザーの観点から、システムとは独立して実行されます。[10]  

使い方

ユースケースは、次のコンテキストで適用されることが知られています。

テンプレート

ユース ケースをテキストで記述する方法は多数あります。ユース ケースの概要カジュアルアウトライン完全な服装など、さまざまなテンプレートを使用できます。さまざまなベンダーや専門家によって考案されたテンプレートでユース ケースを記述することは、高品質の機能システム要件を取得するための一般的な業界慣行です。

コックバーン スタイル

Alistair Cockburnが著書「Writing Effective Use Cases 」で定義したテンプレートは、最も広く使用されているユース ケースの記述スタイルの 1 つです。[引用が必要]

設計範囲

Cockburn は、各ユース ケースに記号を付けて「設計範囲」を示すことを提案しています。これは、ブラック ボックス (内部の詳細が非表示) またはホワイト ボックス (内部の詳細が表示されます) である場合があります。5 つのシンボルが利用可能です: [20]

範囲 アイコン
組織(ブラックボックス) 満たされた家 スコープ アイコンいっぱいの家
組織(ホワイトボックス) 満たされない家
スコープ-アイコン-満たされていない家
システム(ブラックボックス) 満たされた箱
スコープ アイコン塗りつぶしボックス
システム(ホワイトボックス) 未充填ボックス
Scope-icons-unfilled-box
成分 ネジまたはボルト
スコープ アイコン スクリュー ボルト

他の著者は、組織レベルのユース ケースを「ビジネス ユース ケース」と呼ぶことがあります。[21]

目標レベル

目標レベルの階層

Cockburn は、「目標レベル」を示す記号を使用して各ユース ケースに注釈を付けることを提案しています。[22]好ましいレベルは「ユーザー目標」(または口語的には「海面」[23] : 101  ) です。

目標レベル アイコン シンボル
非常に高い クラウド ++
目標レベルのアイコン-cloud.png
概要 空飛ぶ凧 +
目標レベルのアイコン-flying-kite.png
ユーザーの目標 海の波 !
目標レベルのアイコン-waves-at-sea.png
サブ機能 -
ゴールレベルアイコンfish.png
低すぎる 海底あさり --
目標レベル アイコン海底クラム シェル.png

テキスト記述では、ユース ケース名の後に代替テキスト記号 (!、+、- など) を付けた方が、レベルを示すためのより簡潔で便利な方法です。ログイン -

完全に着飾った

Cockburn は、ユースケースのより詳細な構造を説明していますが、詳細が必要ない場合は単純化できます。彼の完全なユース ケース テンプレートには、次のフィールドがリストされています。[24]

  • タイトル: 「主要なアクターの目標を示す能動態動詞の目標句」[25]
  • 主役
  • コンテキスト内の目標
  • 範囲
  • レベル
  • 利害関係者と利益
  • 前提条件
  • 最低限の保証
  • 成功保証
  • 引き金
  • 主な成功シナリオ
  • 拡張機能
  • テクノロジー&データ バリエーション一覧

さらに、Cockburn は、各ユース ケースの性質を示すために 2 つのデバイスを使用することを提案しています。それは、設計範囲と目標レベルのアイコンです。

コックバーンのアプローチは他の著者に影響を与えました。たとえば、Alexander と Beus-Dukic は、Cockburn の「完全なユース ケース」テンプレートをソフトウェアからあらゆる種類のシステムに一般化し、以下のフィールドが Cockburn とは異なります: [26]

  • バリエーションシナリオ「(もしかしたら分岐してメインシナリオに戻るかも)」
  • 例外「つまり、例外イベントとその例外処理シナリオ」

カジュアル

コックバーンは、プロジェクトが必ずしも詳細な「完全な」ユースケースを必要としない場合があることを認識しています。彼は、フィールドを使用したカジュアルなユースケースについて説明しています: [24]

  • タイトル(ゴール)
  • 主役
  • 範囲
  • レベル
  • (ストーリー): ユース ケースの本文は、何が起こるかを非公式に説明する 1 つか 2 つの段落のテキストです。

ファウラー スタイル

Martin Fowlerは、「ユース ケースの内容を記述する標準的な方法はなく、さまざまな形式がさまざまなケースで適切に機能する」と述べています。[23] : 100 彼は「一般的な使用スタイル」を次のように説明しています。[23] : 101 

  • タイトル: 「ユースケースが満たそうとする目標」[23] : 101 
  • 主な成功シナリオ: ステップの番号付きリスト[23] : 101 
    • ステップ: 「アクターとシステム間の相互作用の簡単なステートメント」[23] : 101 
  • 拡張子: 個別に番号が付けられたリスト、拡張子ごとに 1 つ[23] : 101 
    • 拡張: 「主要な成功シナリオとは異なる相互作用をもたらす条件」. メインステップ 3 からの延長は 3a などの番号が付けられます。 [23] : 101 

ファウラー スタイルは、Cockburn テンプレートの簡略版と見なすこともできます。このバリアントはユーザー ストーリーと呼ばれます。

アリスター・コックバーンは次のように述べています: [27]

ユーザー ストーリーは、精度 2 ビットのユース ケースと考えてください。精度のビット 1 はユース ケースの目標を示し、ビット 2 はメイン シナリオを追加します。ビット 3 は障害条件を追加し、ビット 4 は障害アクションを追加します。ビット 5 は、in/out データのデータ記述を追加します。メッセージの受信者のモデルも含まれているため、Catalysis を 6 番目の精度で配置します。CrystalMethodology ファミリーでは、さまざまに設立されたプロジェクトが、さまざまなレベルの精度でユース ケースを使用しています。方法論的に軽いプロジェクトはユーザー ストーリーを使用し、方法論的に重いプロジェクトはユース ケースを 4 ビットの精度で使用し、Catalysis は 6 ビットの精度を使用します。

マーティン・ファウラーは次のように述べています: [28]

ユースケースをどのように使用するかがすべてです。多くの人が非常に形式化された方法でユースケースを使用しているのを見てきました。Kent は、はるかに親しみやすい方法で UserStories を作成します。Kent がユーザー ストーリーを作成するのと同じように、ユース ケースを作成します。私はこれらをユースケースと呼び、他の開発者とのコミュニケーションを改善し、より軽量なアプローチを使用するように影響を与えます。

俳優

ユースケースは、目標を達成するために検討中の外部アクターとシステムとの間の相互作用を定義します。アクターは決定を下すことができなければなりませんが、人間である必要はありません。[29]アクターは常に利害関係者ですが、すべての利害関係者がアクターであるとは限りません。なぜなら、彼らは「システムがどのように動作するかを気にする権利を持っているにもかかわらず、システムと直接対話することはない」からです。[29]たとえば、「システムの所有者、会社の取締役会、および内国歳入庁や保険局などの規制機関」はすべて利害関係者になる可能性がありますが、アクターになる可能性は低いです。[29]

同様に、システムを使用する人物は、異なる役割を演じるため、異なるアクターとして表現される場合があります。たとえば、ユーザー「Joe」は、Automated Teller Machine を使用して自分の口座から現金を引き出すときに顧客の役割を果たしたり、システムを使用してキャッシュ ドロワーに補充するときに銀行の出納係の役割を果たしたりする可能性があります。銀行。

アクターは、しばしば他の誰かのために働いています。コックバーンは、「最近では、システムのユーザーが他の誰かのために行動していることを把握するために、『顧客の営業担当者』または『マーケティング部門の事務員』と書いています」と書いています。これにより、「ユーザー インターフェイスとセキュリティ クリアランス」は営業担当者と事務員向けに設計されるべきであるが、顧客とマーケティング部門が結果に関係する役割であることがプロジェクトに伝えられます。[30]

利害関係者は、アクティブな役割と非アクティブな役割の両方を果たします。たとえば、消費者は「大衆市場の購入者」(システムとやり取りしない) とユーザー (購入した製品と積極的にやり取りするアクター) の両方です。[31]同様に、ユーザーは「通常の運用者」(本来の目的のためにシステムを使用するアクター) と「機能的受益者」(システムの使用から利益を得る利害関係者) の両方です。[31]たとえば、ユーザー「ジョー」が自分の口座から現金を引き出すとき、彼は現金自動預け払い機を操作して、自分に代わって結果を取得しています。

コックバーンは、システムの利害関係者、ユースケースの主要およびサポート (二次) アクター、設計中のシステム (SuD) 自体、そして最後に「内部アクター」、つまりシステムのコンポーネントの中からアクターを探すことを勧めています。設計中。[29]

ビジネスユースケース

ユース ケースが一連のイベントと、ユーザー (または他のタイプのアクター) とシステムとの間の対話を説明するのと同じ方法で、価値の結果 (目標) を生成するために、ビジネス ユース ケースはより一般的な対話を説明します。ビジネスシステムとそのシステムのユーザー/アクターとの間で、価値のあるビジネス結果を生み出します。主な違いは、ビジネス ユース ケース モデルで考慮されるシステムには、技術システムに加えて人が含まれる可能性があることです。これらの「システム内の人々」は、ビジネス ワーカーと呼ばれます。レストランの例では、各人をアクター (つまりシステムの外) として扱うか、ビジネス ワーカー (システム内) として扱うかを決定する必要があります。以下の例に示すように、ウェイターが俳優と見なされる場合、レストラン システムにはウェイターは含まれません。モデルは、ウェイターとレストランの間の相互作用を明らかにします。別の方法として、ウェイターをレストラン システムの一部 (ビジネス ワーカー) と見なし、クライアントをシステムの外にいる (アクター) と見なすこともできます。[32]

ビジネスユース ケース図は、レストラン (ビジネス システム) とその主要な利害関係者 (ビジネス アクタービジネス ワーカー) の間の相互作用を表す、いくつかのビジネス ユース ケース(目標)のモデルを表します。

ビジュアルモデリング

ユースケースは、テキストだけでなく、必要に応じて図でもあります。統一モデリング言語では、ユース ケースとアクターの間の関係は、もともとIvar JacobsonObjectory表記法​​に基づいたユース ケース図で表されます。SysMLは、システム ブロック レベルで同じ表記法を使用します。

さらに、アクティビティ図シーケンス図コミュニケーション図ステート マシン図などの他の動作 UML 図を使用して、ユース ケースを適宜視覚化することもできます。具体的には、システム シーケンス図(SSD) は、通常、ユース ケースの特定のシナリオを視覚化するために、外部アクターと設計中のシステム (SuD) の間の相互作用を示すためによく使用されるシーケンス図です。

ユースケース分析は通常、ユースケース図を描くことから始まります。アジャイル開発の場合、ユース ケースを示す多くの UML 図とテキストによる説明、メモ、またはユース ケースの概要を含む要件モデルは非常に軽量であり、小規模または簡単なプロジェクトでの使用には十分です。ユース ケースのテキストを補完するものとして、ユース ケースの視覚的な図による表現は、複雑なシステム動作要件の理解、伝達、および設計を促進する効果的なツールでもあります。

以下は、Cockburn スタイルのテンプレートをわずかに変更したバージョンで作成されたサンプル ユース ケースです。基本的なユース ケースの説明には、ボタン、コントロール、フォーム、またはその他の UI 要素や操作が含まれていないことに注意してください。ユーザーの目標、サブ目標、または意図のみが、基本的なフローまたは拡張機能のすべてのステップで表現されます。このプラクティスにより、要件仕様がより明確になり、設計と実装の柔軟性が最大化されます。

article.svg を編集する

ユースケース: 記事を編集する

主なアクター: メンバー(登録ユーザー)

範囲: Wikiシステム

レベル: ! (ユーザー目標または海面)

Brief : (ユーザー ストーリーまたはエピックに相当)

メンバーは、読んでいる記事の任意の部分 (記事全体またはセクションのみ) を編集します。編集中にプレビューと変更の比較が可能です。

利害関係者

...

事後条件

最低限の保証:
成功保証
  • 記事が保存され、更新されたビューが表示されます。
  • 記事の編集記録がシステムによって作成されるため、後で記事のウォッチャーに更新が通知されます。

前提条件:

編集可能な記事が会員に提示されます。

トリガー:

メンバーは、記事の編集要求 (記事全体または 1 つのセクションのみ) を呼び出します。

基本的な流れ

  1. システムは、メンバーが編集するための有益な編集の概要を含む、記事の関連コンテンツすべてで満たされた新しい編集領域/ボックスを提供します。メンバーが記事のセクションを編集したいだけの場合、セクションの元のコンテンツのみが表示され、セクションのタイトルは編集の概要に自動的に入力されます。
  2. メンバーは、メンバーが満足するまで記事の内容を変更します。
  3. メンバーは編集の概要を入力し、この記事を視聴するかどうかをシステムに伝え、編集を送信します。
  4. システムは記事を保存し、編集イベントをログに記録し、必要な後処理を終了します。
  5. システムは記事の更新されたビューをメンバーに提示します。

拡張機能:

2–3。

を。ショープレビュー:
  1. メンバーは、変更されたコンテンツを送信する [プレビューを表示]を選択します。
  2. システムは、プレビュー用にレンダリングされた更新済みコンテンツを追加してステップ 1 を再実行し、編集内容がまだ保存されていないことをメンバーに通知し、続行します。
b. 変更を表示:
  1. メンバーは、変更されたコンテンツを送信する [変更を表示]を選択します。
  2. システムはステップ 1 を再実行し、メンバーによる現在の編集と記事の最新の保存済みバージョンとの違いを比較した結果を表示して、続行します。
c. 編集をキャンセルします。
  1. メンバーは [キャンセル]を選択します。
  2. メンバーが行った変更は破棄され、ステップ 5 に進みます。

4a. タイムアウト:

...

利点

アジャイル運動の開始以来、エクストリーム プログラミングのユーザー ストーリー手法は非常に人気があり、すべてのプロジェクトのアジャイル要件に対する唯一かつ最良のソリューションであると多くの人が考えています。Alistair Cockburnは、彼がまだアジャイル開発のユース ケースを書いている 5 つの理由を挙げています[33]

  1. 目標名のリストは、システムが提供するものを (ユーザー ストーリーよりも)簡潔にまとめたものです。また、初期の優先順位、見積もり、チームの割り当て、およびタイミングを構築するために使用されるプロジェクト計画の骨組みも提供します。
  2. 各ユース ケースの主な成功シナリオでは、システムが基本的に何を行い、何を行わないかについて、関係者全員が合意します。これは、特定の項目の要件 (例: きめ細かなユーザー ストーリー) ごとにコンテキストを提供します。このコンテキストは、他では取得するのが非常に困難です。
  3. 各ユースケースの拡張条件は、開発時間と予算の 80% を何らかの形で占有するすべての小さな、些細なことを調査するためのフレームワークを提供します。これはルック アヘッド メカニズムを提供するため、利害関係者は回答を得るのに時間がかかりそうな問題を見つけることができます。これらの問題は、開発チームが作業に取りかかったときに答えが準備できるように、スケジュールよりも前倒しすることができ、またそうする必要があります。
  4. ユースケース拡張シナリオの断片は、多くの場合、扱いにくく無視されがちな詳細なビジネス上の質問に対する回答を提供します。「この場合、何をすべきか?」これは、プログラマーが問題を考え抜くのに役立つ if...then...else ステートメントに対応する思考/文書化フレームワークです。ただし、プログラミング時ではなく、調査時に行われます。
  5. 完全なユース ケース セットは、調査員がすべてのユーザーのニーズ、システムに関するすべての目標、および関連するすべてのビジネス バリアントを熟考したことを示しています。

要約すると、ユースケースでシステム要件を指定することには、従来のアプローチや他のアプローチと比較して、次の明らかな利点があります。

ユーザー重視

ユースケースは、ソフトウェア要件仕様プロセスのための強力なユーザー中心のツールを構成します。[34]ユース ケース モデリングは、通常、システムと対話する主要な利害関係者の役割 (アクター) と、システムが満たす必要がある彼らの目標または目的 (外部の視点) を特定することから始まります。これらのユーザーの目標は、システムが提供する望ましい機能やサービスを表すユースケースの名前やタイトルの理想的な候補になります。このユーザー中心のアプローチにより、開発者やシステム (内部) の観点から推測された些細な機能ではなく、真のビジネス価値を持ち、ユーザーが本当に必要としているものが開発されます。

ユースケースのオーサリングは、ユーザー中心設計 (UCD)の分野で何年もの間、重要かつ価値のある分析ツールでした。

より良いコミュニケーション

ユースケースは、構造化されたテンプレートを使用して自然言語で記述されることがよくあります。この物語のテキスト形式 (読みやすい要件ストーリー) は、ほぼすべての人が理解でき、視覚的な UML ダイアグラムによって補完され、顧客、エンドユーザー、開発者、テスター、およびマネージャーを含むすべての利害関係者間のより良い、より深いコミュニケーションを促進します。より良い通信は、品質要件をもたらし、品質の高いシステムを提供します。

構造化探査による品質要件

ユース ケースに関する最も強力な要素の 1 つは、ユース ケーステンプレートの形式、特に主要な成功シナリオ (基本フロー) と拡張シナリオ フラグメント (拡張、例外および/または代替フロー) にあります。前提条件から事後条件までユースケースを段階的に分析し、基本から拡張まで、ユースケースフローのすべてのアクションステップを調査および調査して、通常は隠され、無視され、一見些細に見えるが現実的にはコストのかかる要件を特定します(コックバーンが述べたように)上記)は、明確で安定した品質要件を体系的に取得するための構造化された有益な方法です。

ユーザーの目標を達成するためにユース ケースのアクション ステップを最小化および最適化することは、システムの対話設計ユーザー エクスペリエンスの向上にも貢献します。

テストとユーザー文書化を容易にする

アクションまたはイベント フロー構造に基づいたコンテンツを使用して、適切に記述されたユース ケースのモデルは、システムまたは製品のテスト ケースおよびユーザー マニュアルの設計のための優れた基盤および貴重なガイドラインとしても機能します。これは、努力に値する投資です。前もって。ユース ケースのフロー パスとそのテスト ケースの間には明らかなつながりがあります。ユース ケースからそのシナリオ (ユース ケースの実行中のインスタンス) を通じて機能テスト ケースを導出するのは簡単です。[35]

制限事項

ユースケースの制限は次のとおりです。

  • ユースケースは、システムの非相互作用ベースの要件 (アルゴリズムや数学的要件など) または非機能要件(プラットフォーム、パフォーマンス、タイミング、または安全性が重要な側面など)をキャプチャするのにはあまり適していません。これらは、他の場所で宣言的に指定することをお勧めします。
  • ユースケースの完全に標準的な定義がないため、各プロジェクトは独自の解釈を形成する必要があります。
  • extendsなどの一部のユース ケースの関係は、解釈が曖昧であり、Cockburn によって指摘されているように、利害関係者が理解するのが難しい場合があります (問題 #6) [36] [要出典]
  • ユース ケースの開発者は、ユース ケースに組み込むユーザー インターフェイス(UI) の依存関係のレベルを判断するのが難しいと感じることがよくあります。ユース ケース理論では、UI はユース ケースに反映されないことが示唆されていますが、ユース ケースを視覚化するのが難しくなるため、デザインのこの側面を抽象化するのは難しい場合があります。ソフトウェア エンジニアリングでは、要件のトレーサビリティを適用することでこの問題を解決します。たとえば、トレーサビリティ マトリックスを使用します。UI 要素をユース ケースに関連付けるもう 1 つの方法は、UI デザインをユース ケースの各ステップに関連付けることです。これは、ユース ケース ストーリーボードと呼ばれます。
  • ユースケースは過度に強調される可能性があります。Bertrand Meyerは、システム設計をユース ケースから文字通りに推進しすぎたり、ユース ケースを使用して他の潜在的に価値のある要件分析手法を除外したりするなどの問題について説明します。[37]
  • ユース ケースはテスト設計の出発点ですが[38]、各テストには独自の成功基準が必要なため、パスごとに個別の事後条件を提供するようにユース ケースを変更する必要がある場合があります。[39]
  • ユース ケースには目標とコンテキストが含まれますが、これらの目標と目標の背後にある動機 (利害関係者の懸念と非相互作用を含む評価) が競合するか、他のシステム目標にマイナス/プラスの影響を与えるかは、目標指向の要件モデリング手法 ( BMMなど) の対象となります。 *KAOSおよびArchiMate ARMOR)。

誤解

ユースケースに関する一般的な誤解は次のとおりです。

ユーザー ストーリーはアジャイルです。ユースケースはそうではありません。

アジャイルとスクラムは、要求手法に関して中立です。Scrum Primer [40]が述べているように、

プロダクト バックログの項目は、明確かつ持続可能な方法で明確に表現されます。一般的な誤解に反して、プロダクト バックログには「ユーザー ストーリー」は含まれません。単にアイテムが含まれています。これらの項目は、ユーザー ストーリー、ユース ケース、またはグループが有用であると考えるその他の要件アプローチとして表現できます。しかし、アプローチがどうであれ、ほとんどのアイテムは顧客に価値を提供することに焦点を当てる必要があります。

ユース ケース テクニックは、ユース ケース スライスを使用してユース ケースを段階的に強化することで、アジャイル アプローチを考慮に入れるように進化しました。[13]

ユースケースは主に図です。

Craig Larmanは、「ユース ケースは図ではなく、テキストである」と強調しています。[41]

ユース ケースには、UI 関連のコンテンツが多すぎます。

一部の人が言うように、[誰? ]

ユースケースには多くの場合、詳細レベル (ラベルやボタンの命名など) が含まれるため、新しいシステムの要件を最初から把握するのには適していません。

初心者の誤解。適切に記述されたユースケースの各ステップは、アクターの目標または意図 (機能要件の本質) を提示する必要があり、通常、ラベルやボタンの命名、UI 操作などのユーザー インターフェイスの詳細を含めないでくださいユースケースの作成が不必要に複雑になり、その実装が制限されます。

新しいシステムの要件を最初から把握する場合、ユース ケース図ユース ケース ブリーフは、少なくともユーザー ストーリーと同じくらい軽量な、便利で価値のあるツールとしてよく使用されます。[引用が必要]

大規模システムのユースケースを書くのは面倒で時間の無駄です。

一部の人が言うように、[誰? ]

ユース ケースの形式により、大規模なシステム (CRM システムなど) を数百ページ未満で説明することは困難です。これには時間がかかり、不必要な量のやり直しに時間を費やしていることに気付くでしょう。

[引用が必要]

付加価値がまったくないかほとんどなく、多くのやり直しが必要な退屈なユースケースの作成に多くの時間を費やすことは、ライターが十分なスキルを持っておらず、質の高いユースケースを効率的かつ効果的に記述する方法についてほとんど知識がないことを示す悪臭です。ユースケースは、反復的、漸進的、進化的 (アジャイル) な方法で作成する必要があります。ユース ケース テンプレートを適用することは、ユース ケース テンプレートのすべてのフィールドを最初から、または特別な専用ステージ (従来のウォーターフォール開発モデル の要件フェーズ) で使用して包括的に入力する必要があるという意味ではありません。

実際、 RUP や Cockburn の ( OUM メソッドでも採用されている) などの一般的なテンプレート スタイルによって定式化されたユース ケース フォーマットは、複雑な要件をキャプチャ、分析、文書化するための貴重で役立つツールとして実際に証明されています。大規模なシステム。優れたユース ケース ドキュメント ( model ) の品質は、そのサイズだけで判断するべきではありません。大規模なシステムの高品質で包括的なユース ケース モデルが最終的に数百ページに発展する可能性もあります。これは主に、作成者のライティング スキルが低いためではなく、問題が固有に複雑であるためです。[引用が必要]

ツール

テンプレートをサポートするテキスト エディタやワード プロセッサは、多くの場合、ユース ケースの作成に使用されます。大規模で複雑なシステム要件の場合、専用のユース ケース ツールが役立ちます。

よく知られているユース ケース ツールには次のようなものがあります。

ほとんどのUML ツールは、ユース ケースのテキスト記述とビジュアル モデリングの両方をサポートしています。

も参照

参考文献

  1. ^ a b c d Ivar Jacobson 博士。イアン・スペンス; カート・ビットナー (2011 年 12 月)。「ユースケース 2.0 電子ブック」 . アイバー・ジェイコブソン・インターナショナルp。4 . 2020年8月9日閲覧
  2. ^ a b Jacobson、Ivar (1987 年 12 月 1 日)。「産業環境におけるオブジェクト指向開発」 . ACM SIGPLAN 通知22 (12): 183–191. ドイ: 10.1145/38807.38824
  3. ^ コックバーン、アリステア (2002 年 3 月)。「ユースケース、10年後」 . Alistair.cockburn.us . アリスター・コックバーン。2008 年 9 月 15 日にオリジナルからアーカイブされました2013年4月17日閲覧
  4. ^ a b Jacobson Ivar; クリスソン・マグナス; ジョンソン・パトリック; オーバーガード・グンナー (1992)。オブジェクト指向のソフトウェア エンジニアリング: ユース ケース主導のアプローチACMプレス。ISBN 0-201-54435-0. OCLC  26132801
  5. ^ a b Jacobson, Ivar.; エリクソン、マリア。ジェイコブソン、アグネータ (1995)。オブジェクトの利点: オブジェクト テクノロジによるビジネス プロセスのリエンジニアリングアディソン・ウェズリー。ISBN 0-201-42289-1. OCLC  32276135
  6. ^ 「統一モデリング言語仕様バージョン 2.5.1 について」 . www.omg.org 2020年8月9日閲覧
  7. ^ a b c d 統一されたソフトウェア開発プロセスJacobson、Ivar、Booch、Grady、Rumbaugh、Jim。マサチューセッツ州レディング:アディソン・ウェズリー。1999.ISBN _ 0-201-57169-2. OCLC  636807532{{cite book}}: CS1 maint: others (link)
  8. ^コンスタンティン ラリー L. (1995 年 4 月 1 日)。「エッセンシャル モデリング: ユーザー インターフェイスのユース ケース」 . 相互作用2 (2): 34–46. ドイ: 10.1145/205350.205356 . S2CID 17209049 . 
  9. ^ a b コックバーン、アリステア。(2001)。効果的なユースケースを書くアディソン・ウェズリー。ISBN 0-201-70225-8. OCLC  44046973
  10. ^ a b c Bittner、Kurt (2003). ユース ケース モデリングスペンス、イアン。アディソン・ウェズリー。ISBN 0-201-70913-9. OCLC  50041546
  11. ^ レフィングウェル、ディーン. (2003)。ソフトウェア要件の管理: ユース ケース アプローチウィドリグ、ドン。(第 2 版)。アディソン・ウェズリー。ISBN 0-321-12247-X. OCLC  51653240
  12. ^ オーバーガード、グンナル. (2005)。ユースケース: パターンと設計図Palmkvist、カリン。インディアナポリス、インディアナ州: Addison-Wesley。ISBN 0-13-145134-0. OCLC  59554401
  13. ^ a b Jacobson、Ivar ; スペンス、イアン; Bittner、Kurt (2011 年 12 月)。「ユースケース 2.0: ユースケースで成功するためのガイド」 . アイバー・ジェイコブソン・インターナショナル2014年5 月 5 日閲覧
  14. ^ "Business Analysis Conference Europe 2011 - 2011 年 9 月 26 ~ 28 日、ロンドン、英国" . Irmuk.co.uk. 2013 年 6 月 17 日にオリジナルからアーカイブされました2013年4月17日閲覧
  15. ^ "ユースケース 2.0 プレゼンテーション" . アイバー・ジェイコブソン・インターナショナル2011 年 9 月 27 日2020年8月9日閲覧
  16. ^ IEEE コンピュータ ソサエティ (2014). SWEBOK: ソフトウェア エンジニアリングの知識体系へのガイドBourque、Pierre、Fairley、RE (Richard E.) (バージョン 3.0 ed.)。IEEE コンピュータ ソサイエティ。pp. 1-6 から 1-8。ISBN 978-0-7695-5166-1. OCLC  880350861
  17. ^ a b オブジェクト管理グループ(2017). 「統一モデリング言語仕様バージョン 2.5.1」 . www.omg.org 2020年8月16日閲覧
  18. ^ Wiegers、Karl Eugene (2010). ソフトウェア要件の詳細: 厄介な問題と実用的なアドバイスマイクロソフトプレス. pp. 第 11 章ISBN 978-0-7356-2267-8. OCLC  73814167
  19. ^ アンブラー、スコット(2004). 「システムのユースケース: アジャイルの紹介」 . agilemodeling.com . 2020年8月16日閲覧
  20. ^ コックバーン、2001年。表紙の内側。アイコン「デザインスコープ」。
  21. ^ スザンヌ・ロバートソン. Requirements Discovery のシナリオ第 3 章、アレキサンダーと乙女、2004 年。39 ~ 59 ページ。
  22. ^ コックバーン、2001年。表紙の内側。アイコン「目標レベル」。
  23. ^ a b c d e f g h ファウラー、2004 年。
  24. ^ a b コックバーン、2001 年。120 ページ。
  25. ^ コックバーン、2001年。裏表紙の内側。フィールド「ユースケースのタイトル」。
  26. ^ Alexander と Beus-Dukic、2009 年。 121 ページ
  27. ^ http://wiki.c2.com/?UserStoryAndUseCaseComparison [裸の URL ]
  28. ^ http://wiki.c2.com/?UserStoryAndUseCaseComparison [裸の URL ]
  29. ^ a b c d コックバーン、2001 年。53 ページ。
  30. ^ コックバーン、2001 年。55 ページ。
  31. ^ a b Alexander と Beus-Dukic、2009 年。39 ページ。
  32. ^ エリクソン、ハンス・エリック (2000). UML を使用したビジネス モデリングニューヨーク: Wiley Computer Publishing。52ページ ISBN 0-471-29551-5.
  33. ^ コックバーン、アリステア (2008 年 1 月 9 日)。「私がまだユースケースを使用している理由」 . alistair.cockburn.us .
  34. ^ Karl Wiegers (1997 年 3 月)。「お客様の声を聞く」 . プロセスへの影響ソフトウェア開発。
  35. ^ Peter Zielczynski (2006 年 5 月). 「ユースケースからテストケースへのトレーサビリティ」 . IBM 開発者ワークス。
  36. ^ "Alistair.Cockburn.us - 目標を設定したユース ケースの構築" . alistair.cockburn.us . 2018年3 月 16 日閲覧
  37. ^ Meyer, 2000. (ページが必要)
  38. ^ Armor and Miller, 2000. (ページが必要)
  39. ^ Denney, 2005. (ページが必要)
  40. ^ ピート・ディーマー; ガブリエル・ベネフィールド。クレイグ・ラーマン; Bas Vodde (2012 年 12 月 17 日)。「スクラム入門: スクラムの理論と実践の軽量ガイド (バージョン 2.0)」 . InfoQ.
  41. ^ ラーマン、クレイグ (2005). UML とパターンの適用. プレンティス・ホール。pp.63–64。ISBN 0-13-148906-2.

さらに読む

  • Alexander、Ian、および Beus-Dukic、Ljerka。要件の発見: 製品とサービスの指定方法. ワイリー、2009年。
  • アレクサンダー、イアン、メイデン、ニール。シナリオ、ストーリー、ユースケースワイリー 2004.
  • アーマー、フランク、グランビル・ミラー。高度なユース ケース モデリング: ソフトウェア システムアディソン・ウェズリー、2000年。
  • Kurt Bittner、Ian Spence、Use Case Modeling、Addison-Wesley Professional、2002 年 8 月 20 日。
  • コックバーン、アリステア。効果的なユースケースを書く。アディソン・ウェズリー、2001年。
  • Larry Constantine、Lucy Lockwood、Software for Use: A Practical Guide to the Essential Models and Methods of Usage-Centered Design、Addison-Wesley、1999。
  • デニー、リチャード。ユースケースで成功する: スマートに作業して品質を提供しますアディソン・ウェズリー、2005年。
  • ファウラー、マーティン。UML Distilled (第 3 版) . アディソン・ウェズリー、2004年。
  • Jacobson Ivar、Christerson M.、Jonsson P.、Övergaard G.、Object-Oriented Software Engineering - A Use Case Driven Approach、Addison-Wesley、1992 年。
  • Jacobson Ivar、Spence I.、Bittner K. Use Case 2.0: The Guide to Succeeding with Use Cases、IJI SA、2011 年。
  • Dean Leffingwell、Don Widrig、Managing Software Requirements: A Use Case Approach、Addison-Wesley Professional。2012 年 12 月 7 日。
  • クラック、ダリル、イーモン・ギニー。ユースケース: コンテキスト内の要件。アディソン・ウェズリー、2012年。
  • マイヤー、ベルトラン。オブジェクト指向ソフトウェアの構築。(第 2 版)。プレンティス・ホール、2000年。
  • Schneider、Geri、および Winters、Jason P. Applying Use Cases 2nd Edition: A Practical Guide . アディソン・ウェズリー、2001年。
  • Wazlawick、Raul S. 情報システムのオブジェクト指向分析と設計: UML、OCL、および IFML によるモデリングモーガン・カウフマン、2014年。

外部リンク