敏捷开发需求收集与文档记录的新方法
1. 传统需求收集方式
瀑布模型和敏捷开发在需求收集和共享方式上存在显著差异。在瀑布模型中，所有需求必须在完整收集后才能传递给 IT 部门进行评估。瀑布模型是线性流程，一个阶段结束后才能开始下一个阶段，因此所有需求必须提前完全明确并记录下来。
然而，由于市场动态变化，事物不断发展，这种方式几乎不可能实现。这导致产品人员和开发人员之间产生挫败感，开发人员觉得没有得到所需的全部信息，产品人员则无法考虑到所有可能的细节。
此外，旧的需求交换方法缺乏对话。产品人员花费数月时间收集和记录需求，然后几乎不沟通、不协作地将其发送给 IT 部门。IT 部门没有机会就需求提问或提供建议，也就无法利用自身专业知识提高需求质量。最后，瀑布模型难以跟上业务需求的变化，而敏捷框架则是为适应变化而构建的。
2. Scrum 中的敏捷需求
与瀑布模型相比，敏捷开发以一种完全不同且创新的方式运作。它不需要详细记录复杂系统的所有细节，而是针对简单功能提供简单说明，并在讨论过程中逐步添加细节。需求聚焦于满足用户/客户需求、提供切实的商业价值以及促进协作。
在 Scrum 中，需求被称为用户故事。用户故事必须足够小，以便能够在一个冲刺或迭代周期内完成设计、编码和测试。由于冲刺周期较短（通常为两到四周），这就要求用户故事简洁明了。
2.1 用户故事的定义
- 什么（What）：用户故事是对所请求功能（或功能组件）的简短描述。
- 谁（Who）：用户故事融入了使用或受益于
