「シナリオ」と「ユースケース」を1つとして使用しますか、それとも個別に使用しますか？
シナリオとユースケースの違いについては多くの議論と情報がありますが、私は知りたいです彼らがどのように-またはしないのか-一緒に働く？
高いレベルでは、シナリオとユースケースの主な違いは、シナリオにはテクノロジーやシステムの相互作用が含まれておらず、ユーザー（ペルソナ）が行っていることに焦点を当てているだけであることです。
それで、シナリオとユースケースの両方が作成されますか、それを1つに組み合わせても問題ありませんか？
私はそれらが両方に入る貴重な情報を構築する際にお互いを助けることができると思いますが、最終的には次のように異なる目的で使用されます：
シナリオは、設計の決定を通知し、設計および開発サイクル中にユーザーの世界をより鮮明に視覚化するのに役立ち、全員がユーザー向けの製品の構築に集中できるようにします。
ユースケースは、開発サイクル中に検討する必要がある論理的な手順についてビジネスアナリストと開発者に通知するために使用されます。
シナリオウィキペディアから
...主要な利害関係者グループを主人公とする「の日常」または一連のイベントに関する架空の物語。通常、以前に作成されたペルソナがこのストーリーの主人公として使用されます。ストーリーは、主要な利害関係者グループの問題に関連して発生するイベントの具体的なものである必要があり、通常、設計プロセスが構築される主な研究の質問です。これらは、個人の日常生活についての単純な物語であることが判明するかもしれませんが、イベントからの小さな詳細は、ユーザーに関する詳細を暗示するはずであり、感情的または身体的特徴を含む可能性があります...使用例Wikipediaから
...個人と他の世界との間の相互作用を説明します。各ユースケースは、実際の生活の中で短期間発生する可能性があるイベントを説明しますが、俳優と世界の間の複雑な詳細と相互作用で構成される場合があります。
UPDATE：Aadaamからの回答に基づいて、私が探しているものを明確にするために質問の周りに詳細を追加する必要があると思いました。
シナリオとユースケースには明らかな違いがあることを理解していますが、同様の明確な点もあります。両方を使用するプロジェクトがある場合、これらの類似点により混乱が生じます。
私が言及しているプロジェクトには、uxデザイナーとビジネスアナリストがいます。 uxデザイナーは、ユーザーのストーリーを伝えるためにシナリオに依存しています。ビジネスアナリストは、ユースケースに依存して、ビジネス、ユーザー、システムの全体的な要件と機能を伝えます。
それを念頭に置いて-プロジェクト中に両方をどのようにそしてなぜ使用するのですか？または、1つを構築してもう1つに給餌することで合理化できる方法はありますか？
私はこれについて私自身の意見を持っていますが、まず客観的な答えを得るために私の偏見を排除したいと思います。
明確にするための追加情報、このトピックに関する洞察に満ちた回答を提供してくれたAadaamに感謝します。
以下の情報は、UX研究分野におけるユーザー中心の分析について最近行ったコースからのものです
シナリオとユースケースの区別
そしてそれらが組織化にどのように適合するか
シナリオは完全にユーザーストーリーです
- システムのアクティビティを反映していません（ユーザーによる経験を除く）
- シナリオは技術にとらわれないものである必要があります（可能な限り）
- たとえば、「ジムは現在の旅行計画を表示しています...」
ユースケースは、ユーザーとテクノロジーについて同じである傾向があります
- たとえば、「ジムはホームページを表示し、ユーザーIDとパスワードでログオンし、システムは現在の旅行計画を取得します...」
このトピックについてさらに調査を行ったところ、ユーザーストーリー、ユースケース、シナリオに関するこの記事を見つけました。
この記事では3つの項目を定義していますが、さらに重要なのは、記事の最後でかなりうまくまとめていると思います。
以下の情報はNadine Schaefferによって作成されました。
シナリオ
シナリオから始めましょう。彼らは通常、ペルソナに関連付けられており、特定のテクノロジーのユーザーが誰であるか、彼らが何を望んでいるか、彼らが何を知っているかについてのストーリーを作成することの一部です。したがって、シナリオは通常、絵やイラストも含めて、ナラティブ形式で記述されます。シナリオは、通常、プロジェクトの最初のディスカバリーおよび要件収集フェーズで作成されます。
使用例：
最後に、ユースケースについて説明しましょう。ユースケースは通常、詳細な製品要件ドキュメントの一部として書かれています。アクションの目標、つまりプロセスを開始するトリガーイベントをキャプチャし、入力、出力、エラー、例外など、プロセスの各ステップを記述します。ユースケースは多くの場合、アクションを実行するアクターまたはユーザーの形式で記述され、その後に予期されるシステム応答と代替の結果が続きます。それらは、テクノロジーがどのように使用されるかについて具体的な顔、名前、およびストーリーを提供することにより、設計と開発を導く人間中心のアンカーを提供します。
要約：
ユースケース、ストーリー、シナリオは交換可能な用語ではありません。それぞれが特定のプロセスと成果物のセット。とはいえ、厳格なルールはありません。プロジェクトのニーズ、現在の開発段階、チームのスキルと親しみやすさのレベルを確認し、最適なユーザーとタスクの定義プロセスを選択することは理にかなっています。
更新：
私がこの質問で彼女の意見や考えを得ることに関して、この回答で参照する記事を書いたナディーン・シェファーに連絡を取りました。
メールでの返信であるフィードバックをこちらで共有できるかどうか尋ねました。
シナリオとユースケースを、プロジェクトのさまざまな目的と段階で使用しています。
ペルソナとシナリオでプロジェクトを始めるのが好きです。私の考えでは、これら2つの成果物は密接に結びついています。ペルソナはユーザータイプの信頼できるアーキタイプを作成し、シナリオはこれらのペルソナが何をするかについてもっともらしいストーリーを伝えます。ユーザーエクスペリエンスデザイナーとして、私はペルソナとシナリオの作成を行う傾向があります。
ただし、ユースケースは、人やペルソナではなく、製品でユーザーが実行できるようにするために必要なものについてです。これらは、製品の機能と要件を定義するユーザー中心の方法です。したがって、それらは多くの場合、製品マネージャーによって作成されます。
Nadine Schaeffer- Cloudforest Design のプリンシパル、およびユーザーエクスペリエンスコンサルタントのプロフェッショナル
彼女の答えは私に明快さを与え、しばらくの間私を悩ませてきたこの質問の周りに私の心を落ち着かせました。
使用例は、システムが使用されるものです。つまり、ユースケースは、goalまたはmethod（GOMS用語）のソリューションのプレースホルダーです。
同様に、ワイヤーフレームをある種のプレゼンテーションツールに組み込んでクリック可能な領域にナビゲーションを追加することにより、ワイヤーフレームを「インタラクティブ」にしたい場合、ユースケースは次の両方です。
- ユーザーはモックアップからインタラクティブなプレゼンテーションを作成して、それを顧客に提示したり、ユーザー調査を行ったりします（通常はに短縮されます）user create interactive presentation）
- ユーザーは、ホットスポットを単一画面のモックアップに追加して、他の画面モックアップへのナビゲーションを有効にします（通常はに短縮されます）ユーザーはホットスポットを単一のモックアップに追加します）
ご覧のとおり、そのうちの1つはgoal（達成するとタスクが完了する）です。もう1つは、その目標に到達するための意味のあるサブプロセスです。つまり、-のプレースホルダーです。 方法その目標を達成するため。
どちらもユースケースと呼ばれ、UML用語（「ソフトウェアエンジニアにとってのUX」）を使用する場合、通常 "includes"関係にあります。
scenarioは、可能な一連のステップであり、特定のユースケースを満たします。要件（ユースケース）をできるだけ早く伝えられない決定から解放することを望んでいますが、通常は、ある種のストーリーを作成せずにユースケースをどのように満たすことができるかを伝えることは不可能です。実行。
Example Scenario of UC1: create interactive presentation
Persona: User
Preconditions: the screen mockups are done for each key screen
Postconditions: there's a clickable interactive mockup
Steps:
1. User adds a single key screen
1.1 Alternative flow: user tries to add keyscreens in batch
Condition: [User has the keyscreens named in alphanumerical order in a directory]
1.1.1 User selects batch upload
1.1.2 Presents directory selection dialog
1.1.3 User selects directory
1.1.4 Opens all the recognizable files in the directory, processes them
in alphanumerical order
1.1.5 Continue from 1.2
1.2 User selects first keyscreen to work with
blablabla
Alistair Cockburnのスタイルに基づいた、上記のユースケースの迅速に記述されたシナリオ
主な違いは、ユースケースが一定であるということです。これは、機能的なニーズの表現です。システムについて理解を深めると、シナリオが変わる可能性があります。 シナリオは、想像上のソリューションの例を表すにすぎません。
初期要件に対する不要な制約が少ない（たとえば、データフローダイアグラムにシーケンス要件がない）表現方法がありますが、ユースケースの方が効果的です。
推奨読書：Allistair Cockburn：Writing Effective Use Cases。トピックの定番とその一部を含むコックバーンのブログ。
興味深い質問です。同じ気持ちで苦労してきましたが、振り返ってみると、シナリオとユースケースが絡み合っていることがわかります。私のシナリオがシステムとの基本的な（必要な）相互作用の全体のストーリーを説明している場合、ユースケースはそのストーリーをさらに詳しく説明しています。
したがって、シナリオとユースケースが連携して機能することを確認する方法は、ストーリーテリングプロセス内でさまざまなレベルの詳細として機能することです。シナリオを読むとき、該当するユースケースを表示することで、特定の側面を「拡大」できます。
この本 Storytelling for UX は、これら2つの方法の主な違いを明確にするのに役立ちました。本のさまざまな例は、洞察に満ちた優れた読書を提供します。
ここでの問題は、単純な定義や用語についての議論を超えていると思います。 UMLコンポーネントは、特定の戦略、方法、ツールを使用して計画、分析、設計、開発、実装する必要がある健全な成果物です。
ユースケースの分解私は通常、ユーザー要件だけでなく、所定のシナリオに関与するすべてのアクターのナラティブの開発から始めます。また、基になる関係、イベントのフローとシーケンス、境界、制約、事前条件と事後条件、例外条件の処理などにも注意を払います。
ユースケースの説明の作成ナラティブの外私は、上記の基準に関連する一連のフィールドを使用して、正式なユースケースの説明を入力し始めます。ユースケースの説明は、私が使用しているユースケースと、その内外で役割を果たすすべての内部および外部要素をよりよく理解するために非常に必要なオントロジーを提供します。私が開発する必要があるユースケースシナリオの必要な数を決定するのは、ユースケースの説明です。各シナリオでは、1つ以上のユースケース図が生成される場合があります。
ユースケースシナリオ名前が示すように、シナリオは、ユースケース開発フェーズでより高いレベルの抽象化を使用して伝えようとしている全体的なストーリーの一部である特定の状況を表します。この段階では、疑似コードまたは疑似コードの観点からシナリオを開発するか、シナリオを段階的に説明する順序付きリストを作成するのが最善です。 1つのユースケースの説明が多くのユースケースシナリオを生成することは、決してあり得ないことではありません。
ユースケース図ユースケースの説明に基づいて考えられるすべてのシナリオを作成したので、ユースケース図を作成することははるかに簡単な作業です。ただし、メインアクターとユースケースのアクティビティ、システムの境界と関係に焦点を当てるために、最初はある程度の抽象化を維持する必要がある場合があります。その後、詳細が利用可能になったときに、関係を一般化して（一般化、組み込み、拡張）空白を埋める問題になります。
ユースケースの再構築ユースケースナラティブ（ストーリー）から始めて、必要なすべての説明、シナリオ、およびダイアグラムでそれを分解（分解）したとき、実際に再構築または再構成する必要があります。すべての要素をパッケージ化し、それを1つのまとまりのあるパッケージとしてカプセル化して提示することにより、ユースケース。パッケージは、一意の識別子でタグ付けされ、システムディクショナリまたはUMLコンポーネントを格納するために使用しているリポジトリに追加されます。
シナリオを使用して目的を決定します。のように-「訪問者は予約を予約する」
ユースケースにはインタラクションが含まれます-「訪問者が詳細を確認し、支払い情報を提供します。システムは支払い情報を検証し、BookingIdで応答します。このIDを使用して、顧客は予約ステータスを確認できます。システムは確認を送信しますSMS =訪問者に」
行動を収集し、利害関係者や製品やサービスが具体的にどのように使用されるかについて共感を示すために、「シナリオ」を使用します。
研究の詳細の背後にあるUXのコアを分析して抽出するとき、および開発プロセスを通じて設計をマーシャリングするときにも、「ユースケース」またはより一般的には「ユーザーストーリー」を使用します。
だからはい、それらは結合します。特に、ユースケースに説得力のあるシナリオがない場合は、構築しないでください。
私はそうは思いません、用語は幾分交換可能です。ユースケースモデリングを発明したIvar Jacobsonは、最初はそれらを使用シナリオと呼び、次にユースケースを決定しました。ユースケースモデリングについて広範囲に記述したコックバーンとファウラーは、ユースケースがメインシナリオと代替シナリオで構成されていることを示す以外は、用語を区別しません。