ユースケース、ユーザー要件、ユーザーストーリーの違いは何ですか？
違いは何なのか、およびこれらの異なる用語がアジャイル/スクラム方法論の中でどの段階で使用されているのかと思いますか。
use case、user requirements、user stories
use casesがuser requirementsになり、user storiesで使用されるproducts backlogとほとんど同じであるので、要件導出段階でそれらが始まると私は思っていますか？
大学のレポートを書こうとしたが、同じ場所でこれらの用語すべてを定義するものを見つけることができなかったため、違いを理解することが困難になった。
これらの用語の一部は、アジャイルアプローチ内でも必要ですか？
ユースケース-アクターとこのシステム（UMLの一部）の単一の機能要件を実現するシステムとの間の相互作用の正式な仕様。
ユーザーストーリー-システムの機能の非公式な説明（アジャイル用語）。
ユーザー要件-開発プロセスのごく初期の段階で、クライアントと密接に協力してアーキテクトが通常収集/定式化した、システムにユーザーが期待するものの正式な説明。要件には主に2つのタイプがあります。
- Functional-ユースケースまたはユーザーストーリーに変換され、アプリケーションのビジネスロジックに実装される要件。
- 非機能-（ほとんどの場合）システムのアーキテクチャーによって確保されるべき要件。すべての非機能要件が測定可能な方法で策定され、テストできることが非常に重要です。
要件は非常に異なる目的で機能するため、ユーザー要件をユーザーストーリーまたはユースケースと比較しても意味がありません。ユースケースとユーザーストーリーはシステム内の機能の詳細を説明し、ユーザー要件はシステムの機能と非機能プロパティを示します（明確ですが詳細はありません）。
簡単に言えば、user storiesはuse casesではなく、user requirementsは、クライアントによって通常承認（または事前承認）された要件のより詳細なドキュメントです。
ユーザーストーリーは提供しないチームが作業を行うために必要な詳細を提供します。スクラムプロセスでは、主に使用例を記述する必要をなくすことにより、この詳細を有機的に明らかにすることができます。
また、ユースケースとユーザーストーリーには互換性がないというコンセンサスもあります。
- Alistair Cockburn：ガゼルはガゼボに対するものであるので、ユーザーストーリーはユースケースに対するものです
- ExtremeProgramming.org：ユーザーストーリーはユースケースと同じ目的を果たしますが、同じではありません。
- Mike Cohn：ユーザーストーリーはユースケースではありません
また、ユーザーストーリーについて、顧客がWebサイトにアクセスしたとき、またはアプリケーション/ソフトウェアを使用したときに行うことの簡単な説明、彼らがこのことを行うことから得られる価値や結果に焦点を当てています。彼らはあなたのウェブサイトやアプリケーションを使用する人の視点から書かれており、顧客が使用する言語で書かれています。
一方、ユースケースは、システムと1つ以上のアクター（「アクター」は人、またはその他のシステム：たとえば、オンラインの買い物客とPaypalの両方が俳優になることができます）。通常はドキュメントとして作成されます
参照：