敏捷过程中的需求分析

瀑布和RUP 强调结构化方法与重型的管理策略，往往在内心中拒绝变更，把变更作为被管理甚至被“管制”的对象；而为了尽可能避免变更，常常要求开发之前的需求获取、分析与定义要完整无误且精确。

这是一种理论上的理想状态，尽管我们可以采取诸如CMMI的一些理念及过程改进模板对其管理，但实际上往往会出现与用户商业价值要求的脱节；而为达成此目标，使得前期的需求开发工作变得小心翼翼，最终有可能在压力与时间约束下难免简单化而草草了事，在后期又不能得到及时的修正，从而形成一个隐患。

软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求（ business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（s c e n a r i o）说明中予以说明。

功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature )是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

3.1需求的参与者

敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business Analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。

在《敏捷宣言》（Manifesto for Agile Software Development）中，强调了客户一起现场工作的重要性。

而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。但应该清楚，这种纳入并不能真正代替真实的客户参与。

对于客户无法全程现场参与的情况，BA的出现是一种弥补。BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（userstory）并将需求传递给开发人员。

同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptance test）。而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。当然，这项工作可以分解为另外的角色来进行。

开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。一个完整描述的用例可以很方便地导出测例（test case）。而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。

从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。

对于角色及其参与方式，我们可以比较如下：

3.2需求的划分

开发人员总是希望能明确地知道系统分几个模板，功能是什么，但这些信息并不是需求的本身。基于模块和功能分解，专门的需求分析人员会使之流于粗放——这种情况是最多见的，功能划分使需求单位粒度较大，不足以描述其特征；而传统由开发人员来做的分析，往往会越过业务价值层面而转入底层的设计。

敏捷需求分析中的划分，将以独立业务价值为基础，划分为一个个用户故事（可以去类比理解UP意义上的use case），它可以是很小颗粒的业务与特征集，也可能会跨越传统的子模块边界。用户故事以参与者为中心，描述了参与者“作为（系统的一个涉众），想要（做一件事），从而（达到一个业务价值）”的集合。用户故事是可见的业务价值，而不是功能描述。每个用户故事的粒度和开发工作量都相差不多，这是其与用例的区别。以此构建的测例，将指导测试与需求验证。

3.3需求分析时机

传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。

敏捷需求分析对这种惯例做出调整，源于其认为：需求的逐步细化过程中，变更是不可避免的；同时，为了快速的商业响应，保证能产出可见、可执行的结果也是必要的。后续的迭代和持续集成保证了需求的演进路线，简言之，需求分析贯穿于项目的整个生命周期。

3.4 文档

传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。

敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” ，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。

3.5 综合以上的陈述，对敏捷需求分析归纳如下表

（角色职责的变化也是一种重要的对比，请参见表1，此处不赘言）

参考

http://www.uml.org.cn/SoftWareProcess/201111101.asp

https://blog.csdn.net/weixin_33894640/article/details/90503514