需求分析是开始软件项目开始的第一步，是业务部门和技术部门沟通的起始。这一阶段的效率和有效性对软件开发具有决定性的作用。然而无论在学术界还是工业界，需求分析历来被认为是软件开发过程中最困难的一环。

传统需求分析困境

传统需求分析一般以名为“需求规格说明书”（Requirement Specification）的文档为目标，以固定时长（根据项目规模而定，一般2、3周或者更长）为约束，以完成需求文档为结束。
经历过传统需求分析过程的分析师和开发人员都会有类似的感觉：

1. 无论用多长时间来分析需求，总感觉需求没有完备
2. 无论如何研讨，已有的需求总感觉不能百分之百明确
3. 至项目开发后期，业务部门和技术部门往往就需求产生纠纷，一般有两种形式：
1. 技术部门认为频繁的需求变更不但增加项目压力，更使已有开发工作浪费
2. 业务部门认为软件系统不能跟进，影响业务发展

传统需求困境分析

造成上述传统需求分析方法困境的原因主要有两点：

1. 在项目进行的过程中，业务需求本身也在发展变化，从而引发软件需求变化。
2. 业务人员不可能凭空把所有需求都想清楚，只有看到、用到真实的软件之后，才能逐渐把自己的需求弄清楚。

虽然一次性需求存在诸多问题，但现实中，技术部门和业务部门往往都希望能在这个阶段将所有问题想清楚。促使团队这样做的深层原因在于：

1. 从管理的角度考虑，软件项目需要申请预算
2. 从软件开发的角度考虑，需求的每一次变更都需要长的时间和巨大的成本来应对，这是技术部门和业务部门双方都不愿看到的。为了避免项目中进行可能的风险，双方都宁可在项目初期尽量把需求冻结。

第一个原因与项目计划方式有关；第二个原因与其说是对策，不如说是对传统开发方法缺陷的妥协：对企业级应用系统来说，早期需求冻结不仅是无法做到，而且还会带来一项隐性的浪费——这种项目开发出来后，可能有20~30%的功能从上线开始，已经不在需要；10~20%的功能的生命周期不超过半年，即费用和人力有相当一部分投入到无用的功能开发中。
业务部门和开发团队依赖文档进行沟通的后果往往是理解出现偏差，开发出的系统的不能满足业务部门的真正需求，造成浪费。

敏捷需求解决方案

敏捷需求分析正是针对传统需求分析困境的三个特点展开的：

1. 化“一蹴而就”为“循序渐进”
2. 化“极端的严格文档定义却又不能百分之百明确”为“多样的形式、简洁的文档、频繁的沟通”
3. 以有效的开发实践持续容纳需求变更

通过对以往经验的总结，敏捷方法认为需求不可能一蹴而就完成，试图通过延长时间穷尽需求应被视为一种对时间和人力的浪费。在敏捷过程中，需求的搜集和变更被更合理认为是一个持续的活动，而不仅仅限于一个阶段。
我们的敏捷需求方法包括两部分：QuickStart和项目中持续需求获取。
QuickStart是我们自主知识产权的一种敏捷搜集方法。QuickStart遵循80/20原则，认为初期20%的时间往往就能获取整个项目80%需求的概要，至于余下20%的细节的磋商、需求的变更、剩余需求的捕获则需要项目80%的时间，因而，从“时间/需求获取有效性”角度讲，不适宜在初期大量投入时间和人力。
根据项目的规模，QuickStart时间被控制在短短的2～4周内。在QuickStart期间，我们的业务分析师（Business Analyst, 简称BA）会通过与业务相关人员访谈、模拟身份扮演、业务场景头脑风暴、高/低保真应用页面原型、用户故事制作等等一系列历经验证有效的活动获取需求。整个QuickStart过程中，最突出的两个特点是：

1. 通过与客户进行多样化的交流和互动，从多个角度挖掘需求
2. 以专业BA与客户间高效的交流代替大量的交流效率低下的文档书写

可以总结为“以人为核心、以交流为核心”代替传统的“以文档为核心”。
通过迅速的QuickStart获取初始用户故事列表（Master Story List，简称MSL），进而由业务部门对这些故事进行优先级排序，然后共同制定发布计划。有了初始发布计划，项目立刻就可以启动。随着项目的进行，我们的BA团队会持续和客户进行交流和通过，继续利用QuickStart中的方法获取后继需求和变更。

特别值得一提的是，敏捷方法不是将每个活动（例如需求、计划、设计等）割裂的看待，而是将其视为互相影响的一个整体。敏捷需求方法比较影响项目计划的制定，同时也要求敏捷设计和开发能够有效的支持敏捷需求、不断的拥抱需求变化，此间的相互影响，我们将在后继章节讲述。