数据结构
网络
关系型数据库管理系统 (RDBMS)
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法律研究敏捷开发中的用户需求和用户故事
需求指的是你想要从产品中获得什么，而用户故事则指的是产品将如何帮助你。换句话说，需求指的是产品应该做什么，而用户故事指的是用户如何从产品中获得他/她想要的东西。
即使需求和用户故事听起来很相似，并且在没有区别的情况下似乎令人困惑，但根据它们的视角，两者仍然是不同的。在本文中，我们将详细解释用户故事和需求。让我们开始吧。
什么是用户故事？
用户故事用于描述项目如何为最终用户创造价值。目前，编写满足用户故事需求的代码的责任在于开发团队。在理想情况下，开发人员会与业务所有者和利益相关者密切合作，以解决代码创建的细节。
用例和技术需求文档不能替代用户故事。相反，产品开发人员可以创建用户故事来帮助组织将在项目时间线上部署的功能。用户故事可以被认为是对话的开始，该对话定义了对产品的真正需求。
什么是需求？
软件需求解释了程序应该具有的行为。它们包括对目标系统功能和能力的描述。业务分析师、产品经理或产品负责人编写需求。技术负责人和将在功能或升级上工作的工程师也经常参与其中。
需求示例
您可以使用字段名称、姓氏、电子邮件、自由文本和提交按钮来创建用户联系表单。单击提交按钮时，客户服务团队会收到一封电子邮件。
软件组件定义了应用程序必须具有的功能。它们包含对目标平台的功能和能力的描述。需求由产品经理、产品负责人或业务分析师准备。首席技术官和从事功能或更新工作的工程师也经常参与其中。
与经典的瀑布方法中的需求文档相比，用户故事通常在敏捷技术中更频繁地使用。
用户旅程（使用产品的人想要能够做什么）是用户故事的主要焦点。功能性（或产品应该能够完成什么）是需求的传统焦点。
用户故事和需求之间的主要区别
用户故事通常在敏捷技术中更频繁地使用，而需求文档通常与传统方法相关联。
由于用户故事的轻量级，因此它们鼓励比需求文档更多的对话和参与。
根据正式的需求规范实施软件时，实际需求可能已经发生变化。在使用用户故事时，任何人都可以在任何时候对用户故事积压工作做出贡献。这可能是开发人员提出有关技术债务的问题，客户要求新功能，或测试人员发现用户体验问题。由于积压工作是共同努力的结果，因此它确保正在完成的工作符合客户的需求。
需求到用户故事
如果需求包含未说明的假设，则可能难以实现。例如，邮件服务器是否可用？如果不是，开发需求可能需要更长的时间。其他时候，设计可能会阻止找到更简单的解决方案来做同样的事情。
另一方面，用户故事描述了用户联系我们的支持团队的情况。如果发送邮件不切实际或成本过高，我们可以立即提出替代解决方案。例如，我们可以写入数据库，通过 Google Docs 使用表单，或者只使用电子邮件地址而不是表单。对于需求来说，这很难实现，但是对于故事和在场的营销专家来说，这很容易。
敏捷性
因此，每当我们有需求时，我们通常会尝试预测这些需求，表达我们的信念，并确保一切顺利进行。因此，在这种情况下，可能存在预先计划以确保邮件服务器存在的其他需求。
这使我们想到了需求和故事之间的另一个重要区别，即层次结构。正如我在上面演示的那样，需求本质上必须以某种自然层次结构排列，以便满足依赖关系。另一方面，故事是目标驱动的，没有这些限制。
这似乎是故意的，因为在敏捷中，在项目过程中根据需要添加、删除、推迟和更改故事至关重要。虽然有时可以更改或删除需求，但由于所有依赖关系，移动它们通常非常困难。简而言之，它并不经常发生。如果您使用规范工作，那么您的快速部署将受到影响，或者它在能够接受更改的意义上不会非常敏捷。
结论
总之，从最终用户的角度编写的软件功能的非结构化一般解释称为用户故事。其目的是解释软件功能对用户如何有用。人们很容易认为用户故事只是软件系统的规范。用户需求阶段侧重于识别用户目标和需求，以便技术能够轻松满足这些需求。
251 次浏览
