不幸的是，我见过许多项目和人都低估了需求定义以及大创意的短期和长期范围管理的重要性，尽管这些是软件开发中最重要的阶段。有许多系统可以执行需求的定义，有些比较简单，比如用户故事，还有一些带有Gherkin 语法的验收标准，可能更完整，但最重要的是，任何像这样的敏捷框架都能促进团队的共同理解，是质量控制的核心。在本文中，我将解释它们是什么，以及哪种技术可以有效地使用 MoSCoW 方法控制项目的用户故事范围。
Agile 如何定义需求？
在进入正题之前，我需要解释一些基本的敏捷概念。
产品待办事项
产品待办事项列表是一个核心工件， 斯里兰卡号码数据 它整合了与产品相关的所有信息，例如需求、估计、沟通、进度状态等。在瀑布管理中，它被称为票证、问题或任务。产品待办事项列表由四层层次组成：主题、史诗、用户故事和任务。
主题代表了跨越数月或数年的长期产品战略。
Epic 具有巨大的价值，影响商业投资，并且需要几个月的冲刺才能完成。
用户故事是每个 Sprint 中必须交付的小价值。
任务是可以在几天内完成的用户故事的细分。
用户故事
用户故事应该包含三个基本元素来阐明需求：用户故事（句子）、验收标准和视觉图像。用户故事（短语）描述了用户希望通过产品实现什么目标，包括谁、什么和为什么。下面是一个示例。
作为用户（谁），我希望通过邮箱地址和密码（什么）登录平台，以便可以安全地使用平台（为什么）。
视觉图像可以是草图、原型或支持共同理解和激发对话的复杂设计。由于用户故事和验收标准是基于文本的表达，视觉图像可以帮助人们想象软件应该如何运行。
接受标准是什么？
验收标准是敏捷实践之一，用于有效地编写完成之前必须满足的需求，简而言之，它就是定义需求和功能的用户故事。
由于需求定义是软件开发中最困难和最耗时的过程，因此 Agile 创建了一种有效且高效的编写需求的方法。验收标准不仅用于需求，也用于验收测试，因此开发团队不必分别编写两者。
虽然编写验收标准有多种格式，但由 Cucumber 创始人 Aslak Hellesøy 创建的 Gherkin Syntax 可能是理想的选择之一，因为它是最全面的格式之一。 Gherkin 的语法由四个简单元素组成：场景、给定、何时和然后，它们描述了软件应如何运行。该框架全面涵盖了软件行为的所有必要方面，适合定义详细需求。您可以在下面看到每个元素的解释和示例。