「ユースケース」、「ユーザーストーリー」、「使用シナリオ」の区別について、正確でありながらシンプルで理解しやすい定義はありますか？

多くの説明がありますが、今のところ、1つか2つの文の違いを説明している人はいません...

（例：http : //c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparisonは非常に長く取得が難しく、議論に満ちています）

ユーザーストーリーは、より多くの非公式、友好と小型版であるユースケース、マイナスUMLダイアグラム。通常、反復シナリオで使用されます。

使用例は、時々フローチャートを伴ってステップバイステップの手順、に引き出されたユースケースです。

私にとって、ユーザーストーリーとユースケースの最大の違いは次のとおりです。

• ユーザーストーリーは、ある軽量（と、私が欲しい、ために）カードに書き込むことができる文書。ユーザーストーリーはすべての詳細をキャプチャするわけではなく、ディスカッションの非公式なサポートです。
• ユースケースはあるヘビー級ワード文書を必要とする文書。手順および/またはアクションの「通常のフロー」と、詳細な「代替フロー」について説明します。ユースケースはすべての詳細をキャプチャします。これは正式な仕様です。

使用シナリオに関するScott W. Amblerによると、これらのアーティファクトはユースケースのフローのように見えます。

使用シナリオ、またはショートシナリオは、システムと対話する方法を一つ以上の人々や組織の実際の例を説明します。インタラクション中に発生するステップ、イベント、アクションを記述します。使用シナリオは非常に詳細であり、ユーザーインターフェースの操作方法を正確に示したり、重要なビジネスアクションを合理的に高レベルで記述しますが、実行方法を示すことはできません。

正直なところ、この段落を読んだ後でも、ユースケースのフローとの違いは明確ではありません（最後の文がおそらく最も重要です）。

ご想像のとおり、ユースケースとシナリオにはいくつかの違いがあります。まず、ユースケースは通常、Customerなどの一般的なアクターを指しますが、シナリオは通常、John SmithやSally Jonesなどのアクターの例を指します。一般的なシナリオを書くことを妨げるものは何もありませんが、通常、シナリオをパーソナライズして理解しやすくすることをお勧めします。第二に、使用シナリオはロジックの単一のパスを記述しますが、ユースケースは通常、いくつかのパス（基本コースと適切な代替パス）を記述します。第三に、UPベースのプロセスでは、ユースケースは公式ドキュメントとして保持されることが多いのに対し、シナリオは不要になった後に破棄されることがよくあります。

私は間違っているかもしれませんが、使用シナリオは本当にユースケースのフローのように聞こえますが、アジャイルタッチでブランド変更されました。

このようなものの正確な定義はありません。それはすべて、会社ごと、システムごとに少し（または大きく）異なります。

最善の策は、現在のプロジェクト用に既に用意されている例を見つけて、それに従うことです。

新しいシステムを作成している場合は、希望するシステムのさまざまなタイプのユースケースの定義を見つけることができます。意図を最もよく伝えると思われるパターンを選択するだけです。

名前にこだわらないでください。

ユーザーストーリーは常に非公式であり、ユーザーのニーズを説明します。ユースケースは、公式または非公式のいずれかであり、システムの動作を説明します。

「技術的な」ユーザーストーリーを作成することもできますが、ユースケースについても同様ではありません。

通常、ユーザーストーリーは破棄されます。ユースケースは、製品のライフサイクル中に維持される場合があります。

スコープも異なります。通常、ユーザーストーリーは範囲が狭いため、ユースケースは複数のユーザーストーリーで構成されます。既存のシステムの要件の変更は、新しいユーザーストーリー、またはユースケースの更新されたバージョンで説明されています。

ユーザーストーリーとユースケースの類似点は、両方とも計画とスケジューリングに使用されることです。

開発者に個別に割り当て可能なタスクに分解されたユーザーストーリーは、ユースケースシナリオよりもきめ細かく、範囲が制限される場合とされない場合があります。ユーザーストーリーは、ユーザーのニーズに関するものであり、システムを使用することの目標または結果です。

ユーザーストーリーの例：

1. 私は顧客であり、アカウントの残高をオンラインで支払いたいと思っています。
2. 私は顧客であり、保存されているクレジット情報の有効期限を更新したいと考えています。

最高レベルの抽象化では、ユースケースは非常によく似ています（顧客更新カードの有効期限）。ただし、ここでは目標ではなく機能のステートメントを示しています。

ユースケースシナリオの粒度が定義されると、それらは機能と手順の詳細になります。

ユースケースの主なシナリオの事後条件は、ユーザーストーリーで述べた結果と同じである必要があります-お客様のクレジットカードの有効期限が更新されます。

ユースケースシナリオでは、テキストまたはプロセスフローチャートでステップごとに説明します（UMLまたはBPMである必要はありません-ユースケースのトレーニングを受けていない消費者による明確さと使いやすさのために、標準の機能横断フローダイアグラムを使用します。

ボトムラインは、ユーザーストーリーがニーズと結果（システムが提供する必要があるもの）を説明するのに対し、ユースケースは目標を達成するために必要なアクター間の相互作用を説明する-そして何が問題になる可能性があるか（拡張シナリオ、代替シナリオ、エラーシナリオ）（ユーザーとの対話方法システムはその結果を達成します）

このトピックの詳細については、Alistair CockburnのWebサイトでhttp://c2.com/cgi/wiki?UserStoryAndUseCaseComparisonを読むことをお勧めします。彼はアジャイルマニフェストの署名者であり、ユーザーストーリーを生み出し、過去数十年間ユースケースの専門家と考えられてきた人物であるため、彼は詳細情報の優れた情報源だと思います。

_{クイックテンポラリーノート：この投稿は、1）参照から追加の詳細を含めるべきであるなどの質問にもっと答えるために改善が必要です。それに戻ります。自分で改善してください。}

テンプレートを見ると、これらの用語の違いについて貴重な洞察を得ることができます。

使用事例

ユースケースには複数のテンプレートがあります。：私はクイック検索の後に3を発見した1、2、3。彼らが（時には漠然と）共通しているいくつかのポイントは次のとおりです。

1. ユースケース/タイトルの名前
2. 説明 -範囲を説明する短いテキスト。
3. アクター/プライマリアクター -この特定のユースケースと対話する人。
4. 前提条件 -このユースケースがライフサイクルを開始する前に真であると想定できるもの。
5. 成功シナリオ -発生するイベントの正しいフローを説明する一連のステップ。

6. 拡張機能 -成功シナリオのフローから逸脱した場合のアプリケーションのフロー：

   1. 代替フロー -正しいフローの他のオプション
   2. 例外フロー -問題が発生した場合のイベントのフロー

7. 成功の保証（別名、投稿条件）-すべてが完了した後のアプリケーションの状態

含めることができる追加のポイントには、レベル、最小保証、トリガーなどがあります。

上記は完全にドレスアップされたユースケースと呼ばれるものです。最も重要なポイントのみを使用して、カジュアルなユースケースを使用することで、ユースケースの作成を簡素化できます。次に例を示します。

1. タイトル
2. 俳優
3. イベントのシーケンス

ユースケースは、80年代後半から90年代前半にIvar Jacobsonによって作成および普及しました。その後、他の人々も彼の作品に貢献しました（そのような人々の1人は、「効果的なユースケースの作成」の著者であるAlistair Cockburnです）。Martin Fowlerのユースケースを言い換えると、テキストとUMLダイアグラムを使用できますが、その最大の価値はそのテキストにあります。大きくなく読みやすいときに最適です。

ユーザーストーリー _{（別名。機能）}

ユーザーストーリー-特定の機能を説明する小さなストーリー。ユーザーストーリーの書き方には一般的なパターンがあります。

ユーザーの特定のタイプ として、
私 は何らかの理由で何か をしたいです。

さらに、ユーザーストーリーには受け入れ基準を設定できます。

ご覧のとおり、このテンプレートはユースケースのテンプレートよりもはるかに小さくなっています。ユーザーストーリーは通常、ソフトウェア開発のscrum / agile / xp領域に関連付けられています。それらは、ポストイットノートやスクラムボードなど、表面の小さな領域に書き込むことを目的としています。そこでは、（通常）そのユーザーストーリー^refにどれだけの労力を投資する必要があるかを概算するポイント値が与えられます。

ビルウェイクは、優れたユーザーストーリーが持つべき品質を説明するためにINVESTニーモニックを開発しました。MartinFowler の短い要約を彼のWebサイトから借ります。

独立：ストーリーは任意の順序で配信できます。
交渉可能：ストーリーの内容の詳細は、開発中にプログラマーと顧客によって共同作成されます。
貴重：機能は、ソフトウェアの顧客またはユーザーにとって価値があると見なされています。
見積もり可能：プログラマーは、ストーリーを構築するための合理的な見積もりを考え出すことができます。
小規模：ストーリーは、通常は人の日数の問題で、短時間で構築する必要があります。確かに、1回の反復で複数のストーリーを構築できるはずです。
テスト可能：このストーリーのソフトウェアが正しく機能することを検証するテストを作成できる必要があります。

使用シナリオ

使用シナリオは、Give-When-Thenを表すGWTパターンに従います。

シナリオ：タイトル
を考える：特定の事実
そして：別の特定の事実（任意でよい） ：いくつかのイベントが発生した後：他のいくつかのイベントが発生しました

使用シナリオは、行動駆動型開発に関連付けられています。テストに非常によく似ています。マーティン・ファウラーは、彼のブログ投稿で、使用シナリオの背後にある歴史と理由を説明しています。重要な部分は次のとおりです。

与えられたあなたは、このシナリオで指定している行動を開始する前に、一部は世界の状態を説明しています。テストの前提条件と考えることができます。ときセクションは、あなたが指定していること、その動作です。 最後に、その後のセクションでは、指定された動作により予想される変更について説明します。

使用シナリオは、アプリケーションのテストを作成するために使用できます。Martinの投稿の最後の段落を引用するには：

Given-When-ThenスタイルはBDDの徴候ですが、基本的な考え方は、テストや仕様書を例ごとに記述する際に非常に一般的です。Meszarosは、このパターンを4相テストと説明しています。彼の4つのフェーズは、セットアップ（指定）、運動（タイミング）、検証（その後）、および分解です。ビル・ウェイクは、アレンジ、アクト、アサートなどの公式を考案しました。

さらなる研究のための参照：

以下のためのWikipediaのページユースケース、ユーザーストーリー、使用シナリオ
のMartin Fowler氏のブログユースケース、ユーザーストーリー、使用シナリオ

私はユーザーストーリーに精通していませんが、数年前にこれを調べたとき：

ユースケースは主要なタスクです。
ユーザーシナリオは、タスクを実行できるさまざまな方法です。そのため、すべてのユースケースには1つ以上のシナリオがあります。ユースケースはアブストラクトであり、ユーザーシナリオはそのアブストラクトタスクのすべての可能なインスタンスのカタログです。

したがって：
ユースケースA：ユーザーはIDとパスワードで認証します。

シナリオ：
1. IDが認識され、パスワードが正しい。（「晴れた日」シナリオ）
2. IDが認識され、パスワードが正しくありません。
3. IDが認識され、3回目のパスワードが正しくありません。
4. IDが認識されません。

私は常に、ユースケースを、クライアントの用語で物語的な方法で要件を定義する方法と考えてきました。上記の場合、クライアントが「しかし、システムがダウンしているときに深夜から1時の間にログインしようとした場合はどうなりますか？」

ユーザーストーリーは、顧客の観点からのものであり、不正確または不完全な場合があります。パフォーマンス、エラー処理、またはバックエンドに関する考慮事項がない場合があります。

ユースケースは、開発者の観点からです。正確で完全です。顧客からのすべての要件に答える必要があります。

「ユースケース」と「ユーザーストーリー」は、顧客の「要件」を表すという意味で同じです。

ユースケースは、各ケースでのシステムの使用方法であり、通常はアクターとシステムの間、またはシステム間の相互作用として表されます。

ユーザーストーリーは、エンドユーザーが何かを成し遂げることができるコンピューター支援ツールを作成する旅の出発点であり、通常は誰が、何を、なぜを使用して簡単な文から始まります最後の保存以降に変更されたものをすべて保存するように求められ、有用な作業を保存し、誤った作業を破棄できます。」）次に、そのユーザーストーリーを、開発者がアプリケーションの構築に使用するユースケースと、テストを実施するテスターに​​育成する必要があります。

QAテスターの観点から見ると、彼らは「ユーザーストーリー」ではなく、「ユースケース」をテストしています。つまり、ソフトウェアの機能をテストしています。

使用シナリオの目的は、システムアクションまたは実際の設計の詳細に飛び込むことなく、目標を達成するためのシステムとのユーザーインタラクションの本質を把握することです。焦点はシステムではなくユーザーにあります。

...ユースケースには、システムの動作に関する記述も含まれますが、使用シナリオではこの説明を避けます。

実装方法はまだ決定していません。

以下からの製品芸術サイト。