需求与用户故事：哪个更好？

作为一名从事业务分析师多年（我承认这一点），我最常被问到的问题之一是： “需求和用户故事哪个更好？”如果答案真的这么简单就好了！事实是，没有明显的赢家，因为它们有不同的用途，并且以对成功项目至关重要的方式相互补充。

我见过一些团队只尝试使用其中一种，结果却错过了项目的关键方面。我也见过一些项目同时使用这两种方法，从而实现了顺畅的沟通、一致的期望以及让用户和利益相关者都满意的最终产品。让我来告诉你为什么需求和用户故事都是我们作为业务分析师的重要工具——以及为什么作为从业者，我们不应该只局限于其中一种。

蓝图与房间描述
我喜欢把这想象成我们正在建造一栋房子。想象一下你有两个工具：蓝图和房间描述。

蓝图就像您的需求：详细、全面，并且绝对必要，以确保房屋不会倒塌或违反建筑规范。它定义了结构、每个电源插座的位置以及管道的安装方式。它是技术基础，是一切应如何运作的真相来源。在我们的世界中，这就是系统的需求：功能性和非功能性。它使系统保持稳定、安全和可扩展。

房间描述就像用户故事。它们关注的是房主（我们的用户）想要如何体验这个空间。“这个房间应该感觉开阔宽敞”，或者“我需要一个厨房岛来准备饭菜”。重点是最终用户的需求以及这个空间将如何为他们的日常生活增添价值。在我们的世界中，用户故事从用户的角度捕捉需要构建哪些功能，指导开发团队逐步交付价值。

现在，如果你只使用蓝图来建造房屋，那么最终你建造的房屋在技术上是完备的，但没有人愿意住进去。当然，墙壁的位置正确，管道也完好无损，但厨房可能感觉拥挤，或者卧室没有自然光。同样，如果你只使用房间描述，房子一开始可能看起来不错，但可能不符合安全规定或没有正确的布线，从而导致以后出现问题。

您需要两者——蓝图以确保结构坚固，房间描述以确保空间适合居住并满足用户的需求。

何时使用要求
根据我的经验，当你处理复杂性、法规或必须精确的系统时，需求就会发挥作用。一些例子包括：

受监管行业：想想医疗保健或金融，这些行业的系统必须遵守严格的法律和监管标准。这些要求就是您的蓝图 — 每一个细节都很重要，几乎没有模棱两可的余地。

大型企业系统：如果您正在开发具有多个集成的企业级系统，那么需求至关重要。它们有助于确保所有移动部件协同工作，并且不会忽略任何关键部分。这是为了确保稳定性、性能和可扩展性。

非功能性需求：安全性、性能和可靠性——这些在用户故事中不容易捕捉到。系统的这些方面通常通过需求详细记录，以确保它们符合行业标准或内部基准。

何时使用用户故事
现在，说到用户故事，我极力提倡在敏捷项目以及任何了解用户需求至关重要的项目中使用它。用户故事大放异彩的情况包括：

敏捷开发环境：在快速迭代的快速发展项目中，用户故事非常宝贵。它们轻量、灵活，专注于以小增量交付价值。它们为开发团队提供了足够的细节来构建某些东西，同时为协作和对话留出了空间。

以用户为中心的项目：如果您的项目专注于构建直接影响最终用户的东西，比如移动应用程序或面向客户的网站，那么用户故事会让团队专注于体验以及用户将从每个功能中获得什么。

优先级和灵活性：用户故事可帮助您根据用户价值管理优先级。您可以轻松调整、重新确定优先级和调整方向，这在快速变化的环境中工作时非常重要。

需求和用户故事之间有什么区别
尽管需求和用户故事都旨在定义需要构建的内容，但它们实现的方式却大不相同。了解这些差异对于了解何时使用每种工具至关重要。让我来分解一下：

目的：

• 需求的主要目的是充当一份正式文件，确保系统根据特定需求构建，通常作为开发人员、测试人员甚至合规审计员的合同或指南。需求帮助团队准确了解必须交付哪些内容才能满足技术、法律或业务目标。
• 用户故事的目的是推动团队成员之间的对话，激发协作，并确保每个人都了解每个功能背后的价值。它们在敏捷环境中特别有用，因为灵活性和优先级是关键。

受众：

• 需求通常是为开发人员、测试人员和其他技术利益相关者编写的，他们需要关于构建什么以及如何构建的精确、可操作的详细信息。在某些情况下，它们还可以作为受监管行业的法律或合同文件。
• 用户故事面向更广泛的受众，包括技术团队和非技术利益相关者，如企业主或最终用户。它们旨在让参与项目的任何人都能轻松理解，确保用户需求清晰易懂。

角度：

• 需求通常是从系统的角度编写的，并且通常具有技术性质。它们描述系统的行为、性能和限制 — 通常从开发人员和测试人员实施和验证系统所需了解的内容的角度出发。
• 用户故事是从用户的角度编写的。它们关注用户的目标、愿望和痛点，捕捉为他们带来价值的功能。这种格式鼓励团队将最终用户的体验放在首位。

格式：

• 需求可以采用多种形式 - 长文档、详细电子表格甚至图表 - 通常包含功能性和非功能性需求、用例和验收标准部分。它们非常全面，对于复杂的项目来说，可能长达数百页。
• 用户故事遵循简单的格式：“作为 [用户]，我想要 [功能] 以便 [受益]。” 它们通常附带验收标准，但省略技术细节。 用户故事通常很短，作为进一步讨论的占位符，而不是完整的规范。

细节：

• 通常，需求会更加详细和具体。它们会准确概述系统应如何运行，通常会深入探讨技术方面、约束和整体系统架构。需求可能会指定数据验证规则、性能基准、安全协议或集成点等内容。
• 用户故事有意被设计为高级内容。它们旨在用简单、通俗的语言描述用户的需求，而无需深入探讨系统如何从技术上实现这些需求。其理念是开启对话，并通过业务团队和技术团队之间的协作来揭示细节。

示例：用户故事与需求
为了更好地说明上述差异，让我举一个用户故事和一组相应的详细需求的例子。

用户故事
作为用户，我希望在我的支票账户和储蓄账户之间转账，以便轻松管理我的资金。
验收标准：

• 用户可以选择源账户（支票/储蓄）。
• 用户可以选择目标账户（支票/储蓄）。
• 用户可以输入要转账的金额。
• 转账成功后，用户会收到确认信息。

功能要求

• FR1该系统将允许用户在同一家银行的支票账户和储蓄账户之间转账。
• FR2系统应在发起转账之前验证用户在源账户中是否有足够的资金。
• FR3系统应为用户提供一个选项，以便安排未来日期的转账并允许重复转账（例如每周、每月）。
• FR4转账成功后，系统应向用户显示确认信息。
• FR5该系统应允许用户查看过去汇款的清单，包括日期、金额和涉及的账户。
• FR6系统应允许用户按日期范围和账户类型过滤转账历史记录。

• NFR1系统将在用户确认后5秒内处理转账。
• NFR2系统应支持最多 100,000 个并发用户，且性能不会下降。
• NFR3系统应记录所有资金转账活动以供审计，并安全保存日志至少 7 年。
• NFR4系统应确保所有预定的转账在预定时间的 1 分钟内完成。

为什么你应该同时学习两者
事实是这样的：作为业务分析师，我们是沟通者和推动者。我们的工作是确保利益相关者（业务或用户）和开发团队意见一致。你拥有的工具越多，你就越能将业务需求转化为可操作的技术工作。如果你把自己限制在只处理用户故事或只写详细需求上，你就无法做好这件事。

每个项目都是不同的，而您的专业知识的一部分就是知道何时应用每个工具。

• 如果您身处受监管的行业或从事复杂的多系统项目，您将需要确保不会忽视任何关键事项。
• 如果您所在的敏捷团队正在为最终用户构建产品，那么您将严重依赖用户故事来确保在正确的时间提供正确的功能和价值。