Answers:
老实说，在投入了将近两年的时间用于敏捷开发之后，我仍然认为“用户故事”只是“功能需求”的一个花哨术语。
从表面上看，它是不同的，例如，它总是采用某种形式（“作为X，我希望Y以便Z ...”），但是关键元素（确定利益相关者和基本原理）也是固有的-书面功能要求。写一个不好的用户故事和写一个不好的需求一样容易（“因为[我们的公司名称]，我想要[模糊的功能]，这样我就可以[做一些不言而喻的工作，例如'向客户销售更多']“）。
根据我的经验，用户故事几乎从未捕获到非功能性需求，例如性能和安全性。这类要求很难正确编写，并且用户故事的格式根本不能很好地抓住它们，因为它们更多地是关于总体产品质量和减轻（但不能消除）风险，而不是满足特定用户的要求。需要。
因此，我确实将用户故事视为具有特定公式的需求子集，并且仍然可以互换使用这些术语。
用户故事相对于需求确实具有的一个主要优势是，“需求”一词表明在通常只需要某个功能的地方就需要该功能。从理论上讲，可以将用户故事的优先级放到任何发行版中，而对于每个发行版，需求似乎是先决条件。
当然，对于上述区别，您的客户和/或高级管理人员必须接受它。如果您将30个用户案例全部分组到一个“项目”中，并且必须同时完成，那么这对您没有任何好处。在这种情况下，您也可以将它们称为“要求”，因为实际上是必需的。
罗恩·杰弗里斯（Ron Jeffries）很久以前就写过用户故事的3C（http://xprogramming.com/articles/expcardconversationconfirmation/），重点是卡片（简短说明），一旦有用户故事，客户与交付团队之间的对话变得可行，对话后双方同意对故事进行确认。
从本质上讲，在进行对话之前，用户故事只是计划中的范围-有关我们可能会做什么的粗略想法。对话后，您应该有办法确认故事是否完整。因此，根据您在该时间轴上查看故事的时间，故事可能只是关于范围的广泛观念或详细要求。
如今，“用户故事”的含义似乎只限于杰弗里斯3C的“卡片”部分。在这种情况下，用户故事不是必需条件，而是承诺就要求进行对话。
您可以在c2 Wiki（http://xp.c2.com/UserStory.html）上找到大量关于用户故事的智慧金块。
用户故事和要求是完全不同的野兽。
需求假定应用程序的设计是事先完成的，而开发是该设计的实现。因此，需求集中在如何实现功能上。
需求示例：
用户故事专注于什么来实现的，并坚持认为，产品的设计是在最后一分钟完成的，它是一个产品的人，开发商的人之间的合作。细节是在实施过程中根据机会决定的。
一个故事的例子：
如您所见，所提供的详细信息数量肯定有所不同，但也有很多仅在故事中可用的信息，即我们试图通过此功能实现的目的。
尽管目的似乎并不重要，但在敏捷开发中这是一个错误的假设。通常，在两种情况下，了解目标非常重要：减少机会成本并提高敏捷性。
如果需求中存在隐含的假设，则可能很难实现。例如：是否有可用的邮件服务器？如果不是这样，则可能需要更长的时间来开发该需求。在某些其他情况下，由于设计原因，可能会错过实现相同目标的更简单方法。
相反，用户案例是关于用户与我们的支持部门联系的。如果发送邮件不可行或过于昂贵，我们可以当场设计出另一种解决方案：例如，写入数据库，或者通过Google文档使用表格，或者简单地输入电子邮件地址代替表格。这项要求很难做到，但故事和产品人员在场很容易做到。
因此，对于需求，我们通常倾向于事先考虑这些隐藏的假设，并确保没有任何障碍。因此，在这种情况下，可能需要事先安排一个不同的要求，以确保存在邮件服务器。
这导致我们在故事和需求之间的另一个巨大差异是层次结构。正如我上面举例说明的那样，必须按其自身的性质将需求按某种自然的层次结构排序，以便满足依赖性。另一方面，故事只关注目标，没有这种限制。
这是设计使然，因为在敏捷过程中，在项目执行过程中根据需要添加，删除，重新计划和修改故事至关重要。通常可以添加，有时修改或删除需求，但是由于所有依赖关系，移动需求通常非常痛苦。根本不经常这样做。如果您正在处理需求，那么在能够接受变更的意义上，您的敏捷实施会受到影响，或者可能根本不是非常敏捷。
对我而言，用户故事的一个关键要素是它捕获了用户使用系统的原因和方式。它之所以特别有用，是因为它在系统交付所需功能方面没有太多指定。当需要进行UI和可用性测试时，用户故事可能是最重要的文档。
当然，您可以让Selenium验证HTML中是否存在某些节点或进行屏幕截图，或者验证某些像素是否位于您希望的位置。但是，如果存在误导性文字，或者不清楚用户应该如何使用该系统，或者用户很难弄清楚如何实现他们的目标，突然之间您将没有完整的系统。现在需要培训才能使用该系统。根据用户方案审查完整的系统是手动测试的关键组成部分。
用户故事/场景中捕获了一种思维定式，该思维定式应该影响有关实现的许多详细设计决策。除非开发人员直接与用户交谈或观看他们使用系统，否则用户场景可能是使他们了解用户需求的唯一链接。
最后，它们允许业务人员在不需要建议应如何实现的情况下指定所需的内容。描述解决方案比需求要容易得多，并且用户场景提供了无需描述特定解决方案即可描述需求的框架。我听到的最常见的业务需求是：“我希望它像Excel一样，但是在Web上”，这实际上并不是他们真正需要的。
因此，我想说，一个好的故事不应包括有关如何实施该系统的任何具体细节。应该说：“每月一次，系统A需要使用系统B中的任何新数据进行更新。该数据可能需要更正。客户具有输入无效数据的历史，并且有数周没有意识到问题。” 它不应说：“系统必须每月至少接受一次latin1 CSV文件一次，如果第3列不是数字，则抛出NumberFormatException”。你看得到差别吗？该场景描述了需求，而不是任何特定的解决方案。然后，在测试中，您将回到场景中以确保解决方案符合需要。需求可能将一些需求与一些解决方案混合在一起，甚至完全专注于解决方案。
在一次Google搜索中偶然发现了这一点，并认为我会发表自己的看法。
需求和用户故事之间确实没有区别。两者都从用户角度说明了预期的结果或目标。
唯一的区别是业务分析师捕获此目标或结果的方式。在这种情况下，它是措词。
例：
作为团队负责人，我想查看我的哪个团队正在处理抵押贷款案件，以便我可以监视他们的表现。
解决方案应显示处理抵押贷款案件的团队成员。
可以用相同的方式解释以上两种情况，但是两者也有很多歧义。这里的重点是风格上的差异。我认为我们最常看到的问题是，在离开需求领域并进入功能设计领域之前，我们对解决方案的定义有多远。是由业务分析师指出“在主应用程序菜单上按名字和名字列出已登录用户的列表”还是太多的信息？当我们与利益相关者交谈时，我们都知道解决方案并可以解释它的外观，即使它可能基于其可能的代码语言以及其部署方式，我们也确实需要玩“让我们定义目标而不是解决方案”。这是我真正感到困惑的地方。
需求通常会假设我们对解决方案一无所知，只是期望的结果。是的，这使所有解决方案均不可知，但是这真的对我们的开发周期有帮助吗？如果我们可以尽早准确地定义某些内容，那为什么不这样做呢？
总而言之，尽管我不会担心用户案例和需求差异。最终，您想要为某人定义足够的信息来开发解决方案。级别太高的用户故事将被简单地击退，并要求分解为较小的用户故事。与“系统应”样式相同。如果没有足够的细节，需求可能会因为过于含糊而被取消。
最终，您的开发人员和利益相关者希望从中看到并开展工作。
我认为即使在经典教科书中，“要求”一词的含义也有很多不一致之处。同样的不一致也适用于用户故事。不同的组织和教科书对这些术语的处理方式有所不同。例如，Roger Pressman的经典软件工程教科书如何谈论需求与Dean Leffingwell的敏捷软件需求书完全不同。我尊重他们俩，他们俩都是有效的。
需求可以是我们编写的具有非凡特异性的东西，几乎没有想象力。另一方面，可以说需求应该指定什么是业务问题而不是解决方案。我认为这更加细微，答案在每个公司和行业都独有的频谱中（并非所有软件开发都发生在IT中）。
有人告诉我，需求启发会导致分析，导致设计，导致架构，导致需求详细说明或规范，并导致可以进行编码。我不认为这种敏捷性会消失。这些事情发生的时间会改变，这是最重要的区别。在瀑布模型中，启发和精细化是较早发生的。在精益和混乱中，启发和精心设计会在各个阶段进行，随着您在sprint中更接近于实现，将会进行更多的精心设计。紧急设计也一样。
在我们的组织中，我们倾向于史诗，功能和故事的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）在他的《应用用户故事》一书中特别指出，有些事情并不能映射到用户故事，而您不必仅使用它。
在我自己的团队中，我们使用以下内容：
功能要求不能使我们意识到，即使我们的黄瓜测试通过并实现了每个书面单词，我们实现的功能也不能满足用户的需求。故事是讨论，是非正式的。重点是让实施人员了解问题所在。它们不是合同工具。如果您做“ scrum but ... ”，而您的故事只是写软件需求的一种有趣的方式，那么是的，没有区别。
关键不是用户故事，关键是范式在您完成工作的方式上发生了巨大变化。您没有签合同，而是在帮助某些用户解决问题。如果您没有将用户案例视为与真实用户的讨论工具，则说明您没有在使用用户案例，而是在使用时髦的需求语法。
剩下的就是我的观点：用户故事永远不会以单方面的方式成功。您需要您的客户来使用它。注水瀑布注定是一个奇怪的要求，但不是要求的混乱。如果您有固定的投标合同并有特定的要求，请不要使用迭代和用户案例，这是没有意义的。使用其余的敏捷工具包：自动化的单元/功能测试，代码审查，持续集成，重构等。请确保您的软件持续运行，并可以立即发出通知。将其以未完成的形式提供给客户，以便他可以提供尽可能多的反馈。如果您这样做，即使您没有执行“用户故事”和“ Scrum”，您也会比许多所谓的“敏捷”商店更加敏捷。
我相信每个人都将根据过去的经验来实施和标记所有内容，而对于该公司而言，完成工作的任何语言都值得争论。
但是，IMO的“用户故事”遵循敏捷的“建筑物中的客户或客户立即可用”的方法，在该方法中并不需要文档，因为详细信息在客户头中且容易获得，因此正式的SRS可能不需要。现在，“用户故事”的“任务”是开发人员将如何以可消化的方式构建用户故事。
一个示例用户故事可能是：
作为管理员用户，我想查看网格中列出的客户数据
而“任务”可能是：
创建一个网格，列出要显示的数据
在网格上启用排序，这将对所选列进行排序
现在，每个任务都在各自的sprint中进行估算和完成。
从“传统”的角度来看，“客户很难掌握，我们需要将其写下来，以便他们可以在开始计划/编码之前确认我们做对了”，软件需求规范是将成为客户头脑中的想法，然后被提出，写下来，形式化，然后进行基线化和管理。
在这种情况下，“功能需求”是该SRS的实质内容，也是更大的Idea的一部分。因此，我认为，用户故事可以被视为正式的“需求”（的一部分），而该用户故事的任务是一项功能需求（或其中的许多功能需求）。
在示例用户案例中，正式的“需求”将是一份冗长的带有流程图的文档，并且通常将以文档为中心，而不是以客户为中心的“敏捷”方法。
不同之处在于，正式的“需求”将遵循大约10页的文档，其中概述了应用程序的管理部分，指示需要一些列表，某些基于角色的安全性等，然后是一些功能。要求将是“列表网格应启用排序”，“用户信息应在网格中列出”等。
而且我确实相信这些天这些术语是混在一起的..根本没有关系