敏捷开发过程中的需求分析

《程序员》2009年2月刊，第70页有一篇如题的文章，比较清晰的阐明了敏捷与传统方法在分析时机、划分单位、细化过程、文档要求和应对变更五个方面的差异。摘抄要点如下：

	传统需求分析	敏捷需求分析
需求分析时机	更多地集中在项目早期	近乎均匀地贯穿于项目的整个生命周期
需求划分单位	基于功能分解，划分模块或子系统，一个模块或子系统的颗粒度通常较大	基于能否独立业务价值，切割成一个个用户故事，一个故事有时会跨越传统的模块或子系统边界；故事的颗粒度较小
需求细化过程	一步到位，可供开发人员设计开发	逐步细化，仅就下一个迭代需要实现的部分进行详细分析
需求文档要求	正式文档，往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约，也作为向客户提交的必备产出物之一。难维护，难验证（跟踪）	非正式文档。仅仅是辅助开发团队与客户沟通，不作为规约，也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求
应对需求变更	有严格的控制流程，视变更为风险	视变更为必然或预期中的事情

敏捷方法中需求文档的作用和传统方法不同：
需求文档不是需要严格评审的项目产出物

不用担心需求文档过时或已经与系统不符

文档没有固定的格式，视沟通的需要而定

鼓励非文档方式的沟通

选择敏捷或传统过程与方法的考虑因素

需求易变	需求稳定
客户或业务人员随时可找到并与之沟通	客户或业务人员较难接触到
客户更在意产品投入市场或系统投入运营所需的时间	客户更在意产品或系统是否覆盖了制定的需求或功能范围
团队（包括交付团队和客户团队）成员分布在同一地域	团队成员分布在不同地域
交付团队拥有更多的开发过程自动化技能及工作环境，诸如自动化测试、持续集成等	交付团队拥有较少的开发过程自动化技能及工作环境