3.1 需求的参与者
敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中，强调了客户一起现场工作的重要性。而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。但应该清楚，这种纳入并不能真正代替真实的客户参与。
对于客户无法全程现场参与的情况，BA的出现是一种弥补。BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptance test）。而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。当然，这项工作可以分解为另外的角色来进行。
开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。一个完整描述的用例可以很方便地导出测例（test case）。而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。
对于角色及其参与方式，我们可以比较如下：
| 角色及职责 | 传统的需求参与 | 敏捷的需求参与 |
| 用户/客户 | 需求的提供者 | 需求演进的参与者 |
| 用户的主要参与方式 | 陈述 | 遵循游戏规则的积极的交互参与 |
| BA | 需求的定义者 | 需求的组织者 |
| BA的主要参与方式 | 前期的调查获取和整理成文档 | 参与全周期的迭代与演进 |
| 开发 | 需求的接受者和实现者 | 场景拟合者与改进者 |
| 开发的主要参与方式 | 被传导需求并使之功能化 | 完成完整的业务场景实现 |
| 测试 | 功能测试者 | 场景测试者（需求测试者） |
| 测试的主要参与方式 | 找出软件的显性的bug | 找出不满足需求逻辑和不能拟合场景的缺陷 |
表1：需求的主要参与者
（其他的stakeholders并未全部列出，比如PM、QA等）
这些参与者如何工作的呢？我们引入到需求分析的工作形式。
