回答:
正直に言うと、アジャイル開発に2年近く没頭した後でも、「ユーザーストーリー」は「機能要件」の単なる凝った用語だと思います。
表面的なレベルでは異なります。たとえば、常に特定の形式を取ります（「Xとして、Yが欲しいのでZ ...」）が、重要な要素-利害関係者と理論的根拠を特定することも-書かれた機能要件。悪い要件を書くのと同じくらい簡単に悪いユーザーストーリーを書くのは簡単です（「[会社名]のように、[曖昧な機能]が欲しいので、自分の仕事の一部として自明なことをすることができます。 「顧客により多く販売する」] "）。
私の経験では、ユーザーストーリーがほとんど捉えないのは、パフォーマンスやセキュリティなどの非機能要件です。これらの種類の要件を適切に記述することは非常に難しく、ユーザーストーリーの形式は、特定のユーザーの要件を満たすのではなく、一般的な製品品質とリスクの軽減（排除ではない）に関するものであるため、それらをキャプチャするのにはあまり適していません必要。
したがって、ユーザーストーリーは特定の式を使用した要件のサブセットであると本当に考えていますが、依然として用語はほぼ同じ意味で使用しています。
ユーザーストーリーが要件をオーバーしていない一つの大きな利点は、単語「要件」は機能がされることを示唆しているということです必要なことが多いだけされている希望します。理論上、ユーザーストーリーはどのリリースでも優先順位を付けてスロットに入れることができますが、要件はすべてのリリースの前提条件のようです。
もちろん、前述の区別が重要であるため、顧客や上級管理職はそれを受け入れる必要があります。30のユーザーストーリーがすべて同時に完了する必要がある「プロジェクト」にグループ化されている場合は、何の役にも立ちません。実際には必要なので、その場合は「要件」と呼ぶこともできます。
Ron Jeffriesはずっと前に、ユーザーストーリーの3C（http://xprogramming.com/articles/expcardconversationconfirmation/）について、カード（簡単な説明）に重点を置いて書き、ユーザーストーリー後の顧客と配信チームとの会話実行可能になり、その会話の後、ストーリーの合意された確認。
基本的に、会話の前に、ユーザーストーリーは計画された範囲にすぎません。会話の後、ストーリーが完了したことを確認する方法が必要です。そのため、このタイムラインでストーリーを見る時間に応じて、ストーリーは範囲についての幅広いアイデア、または詳細な要件になる場合があります。
最近では、「ユーザーストーリー」の意味は、ジェフリーズの3Cの「カード」部分に狭められているようです。その場合、ユーザーストーリーは必須ではなく、要件についての会話を約束するものです。
c2 wiki（http://xp.c2.com/UserStory.html）でユーザーストーリーに関する知恵のゴールドナゲットを見つけることができます。
ユーザーのストーリーと要件は非常に異なっています。
要件は、アプリケーションの設計が事前に行われ、開発がその設計の実装であることを前提としています。したがって、要件は機能の実装方法に焦点を当てています。
要件の例：
ユーザーストーリーは何を達成するかに焦点を当て、製品の設計は最後の最後で行われ、それは製品担当者と開発者の間のコラボレーションであることを主張します。詳細は、機会に基づいて実装中に決定されます。
ストーリーの例：
ご覧のとおり、提供される詳細の量には確かに違いがありますが、ストーリーでのみ利用できる情報、つまりこの機能で達成しようとしている目的もたくさんあります。
目的は比較的重要ではないと思われるかもしれませんが、これはアジャイル開発では間違った仮定です。通常、目的を知ることが非常に重要な2つのケースがあります。機会のコストを削減し、俊敏性を有効にすることです。
要件に隠れた前提がある場合、達成するのは非常に困難です。例：利用可能なメールサーバーはありますか？そうでない場合、要件の開発に非常に長い時間がかかる可能性があります。他の場合には、同じ目標を達成するためのより単純な方法が設計のために見落とされる場合があります。
対照的に、ユーザーストーリーは、サポート部門に連絡するユーザーに関するものです。メールの送信が実行不可能または高すぎる場合は、その場で別のソリューションを考案できます。たとえば、データベースへの書き込み、Googleドキュメント経由でのフォームの使用、フォームの代わりにメールアドレスの入力などです。これを要件で簡単に行うことはできませんが、ストーリーと製品担当者が簡単に行うことができます。
このため、要件については、一般にこれらの隠された仮定を事前に考え、問題がないことを確認する傾向があります。したがって、この場合、事前にスケジュールされた別の要件があり、メールサーバーが存在することを確認します。
これはストーリーと要件の間にある階層である別の大きな違いにつながります。上記で例示したように、要件は、依存関係が満たされるように、本来の性質により、何らかの自然な階層で順序付けする必要があります。一方、ストーリーは目的に焦点を当てており、そのような制約はありません。
これは設計によるもので、アジャイルでは、プロジェクトの実行中に必要に応じてストーリーを追加、削除、再スケジュール、および変更することが基本的に重要です。通常、要件は追加、変更、または削除できますが、依存関係がすべてあるため、要件を移動するのは一般的に非常に苦痛です。単に頻繁に行われるわけではありません。要件を使用している場合、変更を受け入れることができるという意味で、アジャイル実装は苦しむか、おそらく非常にアジャイルではありません。
私にとって、ユーザーストーリーの重要な要素は、ユーザーがシステムを使用する理由と方法を把握することです。システムが必要な機能を提供する方法をあまり指定していないため、特に便利です。UIとユーザビリティのテストが必要な場合、ユーザーストーリーが最も重要なドキュメントになる可能性があります。
確かに、特定のノードがHTMLに存在することを確認したり、スクリーンショットを撮ったり、特定のピクセルが希望する場所にあることを確認したりすることができます。しかし、誤解を招くようなテキストがある場合、またはユーザーがシステムをどのように使用すべきかが明らかでない場合、またはユーザーが目標を達成する方法を理解するのが難しい場合、突然完全なシステムがなくなります。システムを使用するには、トレーニングが必要です。完成したシステムをユーザーシナリオに照らしてレビューすることは、手動テストの重要な要素です。
実装に関する多くの詳細な設計決定に影響を与えるはずのユーザーストーリー/シナリオに記録されたマインドセットがあります。開発者がユーザーに直接話しかけたり、システムを使用するのを見たりしない限り、ユーザーシナリオは、ユーザーのニーズを理解するための唯一のリンクである可能性があります。
最後に、彼らはそれを達成する方法を示唆することなく、ビジネスマンが必要なものを指定できるようにします。ニーズよりもソリューションを記述する方がはるかに簡単であり、ユーザーシナリオは、特定のソリューションを提案せずにニーズを記述するためのフレームワークを提供します。私が聞いた最も一般的なビジネス要件は、「Excelと同じようにWeb上に配置したい」というもので、実際に必要なものではありませんでした。
したがって、良いストーリーには、システムの実装方法に関する具体的な詳細を含めないでください。「1か月に1回、システムAはシステムBからの新しいデータで更新する必要があります。そのデータは修正が必要な場合があります。「システムは、少なくとも1か月に1回latin1 CSVファイルを受け入れ、列3が数値でない場合はNumberFormatExceptionをスローする必要があります」と言ってはなりません。違いがわかりますか？このシナリオでは、特定のソリューションではなく、ニーズを説明しています。次に、テストでシナリオに戻り、ソリューションがニーズに合っていることを確認します。要件によっては、一部のニーズと一部のソリューションが混在したり、ソリューションのみに焦点が当てられたりする場合があります。
グーグル検索中にこれにつまずいて、私は私の意見を投げると思いました。
要件とユーザーストーリーの間に実際の違いはありません。両方とも、ユーザーの観点から望ましい結果または目標を述べています。
唯一の違いは、ビジネスアナリストがこの目標または結果を取得する方法です。この場合、それは文言にあります。
例：
チームリーダーとして、自分のチームの誰が住宅ローンのケースに取り組んでいるかを確認して、パフォーマンスを監視できるようにします。
ソリューションは、住宅ローンのケースに取り組んでいるチームメンバーを表示するものとします。
上記の両方は同じように解釈できますが、両方とも多くのあいまいさがあります。ここでの主なポイントは、スタイルの違いです。私たちが最も見ている問題は、要件の世界から機能設計の世界に移行する前に、ソリューションをどの程度定義するかです。「ログインしているユーザーをメインアプリケーションメニューのファーストネームとセカンドネームでリストする」と言うのはビジネスアナリストの責任ですか？それとも情報が多すぎますか？利害関係者と話をし、全員が解決策を知っており、それがどのように見えるか、それが構築される可能性のあるコード言語とそれが展開される方法を解釈できるとき、私たちは本当に純粋なゲームをプレイする必要がありますソリューションではなく目標を定義しましょう」。これは私が混乱を本当に感じているところです。
多くの場合、要件は、ちょうど望ましい結果をもたらすソリューションについては何も知らないという仮定を立てます。はい、これはすべてのソリューションを不可知論的にしますが、それは本当に開発サイクルで私たちを助けますか？何かを早期に正確に定義できたら、それをしないのはなぜですか？
全体として、ユーザーストーリーと要件の違いについては心配しません。最終的には、誰かがソリューションを開発するための十分な情報を定義する必要があります。レベルが高すぎるユーザーストーリーは単純にノックバックされ、小さなユーザーストーリーに分解するよう要求されます。「システムがしなければならない」style.requirementと同じことは、おそらく、十分な詳細がなければ曖昧すぎると思われます。
最終的には、開発者と利害関係者がそれを見て、そこから仕事をしたいものに行きます。
古典的な教科書の中でも、単語の要件が意味するものには多くの矛盾があると思います。同じ矛盾がユーザーストーリーにも当てはまります。さまざまな組織や教科書では、これらの用語の扱いが異なります。たとえば、Roger Pressmanの古典的なソフトウェアエンジニアリングの教科書が要件について語る方法は、Dean LeffingwellのAgile Software Requirementsブックとはまったく異なります。私はそれらの両方を尊重し、それらは両方とも有効です。
要件は、想像力にほとんど左右されない、並外れた特異性を備えたコーディング対象となる場合があります。一方、要件はビジネス上の問題を特定し、ソリューションを特定するものではないと主張することができます。ただし、より微妙であり、答えは各企業および業界に固有のスペクトル上のどこかにあると思います（すべてのソフトウェア開発がITで行われるわけではありません）。
要件の抽出は分析につながり、設計につながり、アーキテクチャは要件の詳細化や仕様につながり、コード化できるものにつながると教えられました。これがアジャイルでなくなるとは思わない。これらのことが起こるタイミングは変わりますが、それが最も重要な違いです。ウォーターフォールモデルでは、誘発と精緻化が早期に行われます。リーンおよびスクラムでは、スプリントの実装に近づくにつれて、さまざまな段階で誘発と精緻化が行われ、さらに精緻化が行われます。緊急設計作業も同様です。
私たちの組織では、要件としてではなく、作業の内訳と優先順位付けとして、Epics、Features、StoriesのLeffingwellモデルに傾注しています。要件は別のものです。要件は、規制当局のために個別に管理する必要があるため、個別に管理されます。それでも、一部のチームは、プログラムの増分およびスプリントの計画中に、ユーザーストーリー内で要件を確実に開発しています。
機能要件は通常、ソフトウェアが機能するかどうかを正確に知ることができる正式な仕様です。通常、ユーザーストーリーは、ユーザーストーリーの必要性を説明するためのはるかに非公式な方法です。ソフトウェアが「有効」か「無効」かを判断する厳密な仕様は指定していません。一部をテストすることはできますが、ユーザーストーリーの実際の完成（正しい操作を行った場合）は、ユーザーが「はい、私の問題を解決しました！」と言うときです。アジャイルマニフェストを思い出してください：
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Mike Cohnは、著書「User Story Applied」で、ユーザーストーリーにマッピングされないものがあり、それだけを使用する必要がないと具体的に述べています。
私のチームでは、次のものを使用します。
キュウリのテストに合格し、書かれたすべての単語を実装しても、機能要件により、実装した機能ではユーザーのニーズが解決しないことを認識できません。ストーリーは議論であり、非公式です。ポイントは、実装担当者が問題の原因を理解することです。それらは契約ツールではありません。"scrum but ... "を実行し、あなたのストーリーがソフトウェアの要件を記述するおもしろい方法である場合、違いはありません。
ポイントはユーザーストーリーではなく、あなたが行うべき仕事にアプローチする方法のパラダイムの大きな変化です。契約を結んでいるのではなく、ユーザーの一部が問題を解決するのを手伝っています。ユーザーストーリーが実際のユーザーとのディスカッションツールとして表示されない場合は、ユーザーストーリーを使用しておらず、ファンキーな要件構文を使用しています。
ここでの残りは私の意見です：ユーザーストーリーは一方的に成功することはありません。顧客はそれを使用する必要があります。Water-scrum-fallは奇妙な要件であるが、要件ではない混乱であると運命づけられています。あなたは、反復し、ユーザーストーリーを使用していない特定の要件に固定入札契約を、持っている場合は、存在しないない点。アジャイルツールキットの残りの部分を使用します。自動化されたユニット/機能テスト、コードレビュー、継続的インテグレーション、リファクタリングなど。ソフトウェアが継続的に動作し、すぐに出荷できることを確認します。顧客ができるだけ多くのフィードバックを提供できるように、未完成の形で顧客に提供します。もしあなたがそれをするなら、たとえあなたが「ユーザーストーリー」や「スクラム」をしなくても、あなたは多くのいわゆる「アジャイル」ショップよりもアジャイルだったでしょう。
過去の経験に応じて、誰もがすべてを異なる方法で実装およびラベル付けし、仕事を遂行するその会社で機能する言語は議論する価値がないと思います。
ただし、IMO、ユーザーストーリーは、アジャイルの「建物内の顧客または顧客がすぐに利用可能」アプローチのアプローチに従います。必須ではありません。「ユーザーストーリー」の「タスク」は、開発者がユーザーストーリーを消化可能な方法で構築する方法です。
ユーザーストーリーの例は次のとおりです。
管理者ユーザーとして、グリッドにリストされたクライアントデータを表示したい
「タスク」は次のようになります。
表示するデータをリストするグリッドを作成します
選択した列を並べ替えるグリッドで並べ替えを有効にします
これで、各タスクが推定され、それぞれのスプリントで完了しました。
「顧客が把握するのが難しい、「従来の」観点から、計画/コーディングを開始する直前にそれを確認できるようにこれを書き留める必要があります。ソフトウェア要件仕様は顧客の頭の中にあり、それを引き出して書き留め、形式化し、ベースライン化して管理したアイデアになります。
この場合、「機能要件」とは、そのSRSの本質的な詳細であり、より大きなアイデアの一部です。したがって、私の意見では、ユーザーストーリーは（一部の）正式な「要件」と見なすことができ、そのユーザーストーリーのタスクは（または多くの機能要件の）1つです。
ユーザーストーリーの例では、正式な「要件」はフローチャートを含む長いドキュメントになり、一般的には顧客中心の「アジャイル」アプローチとは対照的に、ドキュメント中心になります。
違いは、正式な「要件」は、一部のリストが必要であること、ロールベースのセキュリティなどを示すアプリの管理セクションの概要を示す10ページのドキュメントの行に沿っていることです。要件は、「リスティンググリッドが並べ替えを可能にする」、「ユーザー情報がグリッドにリストされる」などです。
そして、私は最近、用語がすべて混ざり合っていて信じていると思います。