敏捷过程中的需求分析
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论，它强调团队合作、快速响应变化和持续交付价值。
在敏捷开发过程中，有以下8个主要步骤。
1. 需求收集与分析在敏捷开发中，需求是一个动态的过程，不断地收集、分析和细化。
团队与客户紧密合作，明确项目的愿景和目标，并将其转化为用户故事或需求项。
通过不断的讨论和反馈，团队可以更好地理解客户需求，并将其转化为可执行的任务。
2. 规划与估算在敏捷开发中，规划是一个迭代的过程。
团队根据客户需求和项目目标，制定短期的开发计划，确定每个迭代的工作范围和目标。
同时，团队也需要对工作量进行估算，以便更好地安排资源和时间。
3. 设计与开发在敏捷开发中，设计和开发是并行进行的。
团队利用迭代周期进行软件设计和编码，采用简单而优雅的解决方案。
团队成员经常进行代码审查和知识分享，以确保代码的质量和可维护性。
4. 测试与验证在敏捷开发中，测试是一个持续且重要的过程。
团队进行单元测试、集成测试和系统测试，以确保软件的质量和功能完整性。
同时，团队也需要与客户进行验证，确保软件满足客户的需求和预期。
5. 交付与部署在敏捷开发中，交付和部署是一个可重复且自动化的过程。
团队使用持续集成和持续交付的工具和方法，将软件快速交付给客户。
同时，团队也需要确保软件能够顺利地部署和运行。
6. 反馈与优化敏捷开发强调不断地学习和改进。
团队与客户保持密切的沟通，收集用户反馈和需求变更。
团队通过迭代回顾和持续改进的方式，优化软件的功能和性能。
7. 沟通与协作在敏捷开发中，沟通和协作是非常重要的。
团队成员之间需要密切合作，共同解决问题和完成任务。
团队与客户之间也需要建立良好的沟通渠道，保持及时的反馈和信息共享。
8. 迭代与持续交付敏捷开发是一个持续迭代的过程。
团队通过多次迭代的方式，逐步完善软件，持续交付价值。
团队通过反馈和学习，不断优化和改进软件的质量和功能。
总结敏捷开发是一种灵活、高效的软件开发方法论。
解读敏捷需求分析五大关键因素
代逐步精化；
・ 整 个 过 程 中 以 分 析 为 支 撑 ， 做
需 求 同 时 也 在 做 分 析 ，分 析 模 型 的 输 出结 果 应 跟 需 求 分 开 ；
需 求 文 化 与敏 捷 的 衡 点 Ｉ ￡
至于 用例 和用户 故事 。按 照敏捷 大 ９Ｍａｔ 博客 中的说法 ，两者都是组 ￣ ｒｎ ｆ ｉ
织 需 求 的 方 式 ， 只 是 目的 不 同而 已 ， 用 例 的 目 的是 为 了 把 需 求 描 述 清 楚 ， 而 用 户 故 事 的 目 的 是 把 需 求 分 解 成 可 用 于 迭 代 计 划 的 单 元 。 对 应 到 产 品级
瀑 布 式 开 发 中 ， 更 多 的是 合 同 式 验 证 的 情 形 ， 大 多 数 客 户 的思 想 基 础 都 是 基 于 需 求 最 初 就 能 确 定 下 来 的 。但 事 实 上 ，这 在 当 前 阶 段 基 本 属 于 “ 可 不 能 完 成 的 任 务 ” ，不 符 合 软 件 开 发 本 质 。 在 敏 捷 需 求 分 析 中 ， 需 求 应 是 贯
虑 如 何 实 现 如 何 合 理 调 整 工 作 量 提 高 效 率 ， 这 些 都 是 找 （ 户 ） 故 事 的 过 用
程 ，也 是 一 个 白盒 的过 程 。
・ 迭 代 ， 即 需 求 不 是 一 次 最 终 确 定 ， 而 是 先 完 成 主 要 框 架 ， 再 通 过 迭
些核心 功 能是 不 改变 的，这 些都 是产
常见的需求分析方法
常见的需求分析方法1. 简述需求分析的重要性需求分析是软件开发过程中的关键步骤之一。
它对于确定项目的目标和范围，并建立起与客户和用户之间的沟通桥梁起着关键作用。
通过需求分析，我们能够准确地理解客户的需求，明确项目的目标，并为后续的设计和开发工作提供指导。
因此，合理有效的需求分析对于项目的成功至关重要。
2. 传统需求分析方法2.1 用户访谈用户访谈是一种常见的需求获取方法，通过与客户或用户面对面交谈，收集和分析他们的需求和期望。
在访谈过程中，需求分析师可以通过提问了解用户的工作流程、问题和需求。
2.2 需求文档需求文档是一个详细描述项目需求的文件。
它包括需求的功能描述、性能要求、界面设计和其他相关信息。
这个文档是团队与客户和用户之间的合作工具，确保大家对需求有一个共同的理解。
2.3 原型设计原型设计通过创建交互式的设计模型来验证和确认需求。
它可以帮助客户和用户更好地理解软件系统的用户界面和功能。
原型设计阶段往往是一个迭代的过程，通过不断修改和优化原型来最终确定需求。
3. 敏捷需求分析方法敏捷需求分析方法是一种在敏捷软件开发中常用的需求分析方法。
与传统的瀑布模型相比，敏捷方法注重快速迭代和持续交付，以更好地满足用户需求的变化。
3.1 用户故事用户故事是一种简洁、可理解的需求描述方法。
它通常由用户角度的一句话表述，描述用户所期望的一个功能或需求。
用户故事侧重于用户的体验和期望，而不是技术细节。
3.2 燃尽图燃尽图是敏捷项目管理中的一种工具，用于展示项目的进展情况和剩余工作量。
它通过图表形式显示出已完成和未完成的工作，以及项目的剩余时间。
通过观察燃尽图，团队可以及时调整和优化开发进程。
3.3 规划会议规划会议是敏捷开发中的一种重要活动，参与者包括产品负责人、开发团队和其他相关人员。
在规划会议中，团队会对项目需求进行讨论和评估，并制定一个可行的开发计划。
规划会议是一个协作的过程，可以帮助团队更好地理解需求，并调整开发计划。
敏捷开发中的需求管理与变更控制
敏捷开发中的需求管理与变更控制在敏捷开发中，需求管理与变更控制是关键的环节之一。
敏捷方法注重在项目开发过程中不断适应变化，并通过紧密的协作与沟通来满足客户需求。
因此，高效的需求管理和变更控制是确保项目顺利进行的重要因素。
一、需求管理需求管理是敏捷开发过程中的基础，它包括需求的发布、收集、分析、优先级排序和需求的可追踪性。
以下是一些需要注意的关键点：1. 需求发布：需求发布应该由产品负责人负责，并确保清晰准确地传达给开发团队。
同时，需求的发布应该具备详细、一致、可理解和可执行的特点。
2. 需求收集：在敏捷开发中，需求收集过程是一个不断迭代、逐步细化的过程。
与传统开发不同，敏捷方法更注重与客户的紧密合作，通过不断的交流和反馈，来获取准确的需求信息。
3. 需求分析：需求分析是将收集到的需求进行整理、细化和加工的过程。
开发团队需要与客户充分沟通，搞清楚需求的背景、目标和具体要求，并将其转化为可执行的任务。
4. 需求优先级排序：在敏捷开发中，需求的优先级排序是非常重要的。
通过与客户协商，将需求进行分类，确定优先级，以便在资源有限的情况下实现更好的需求满足。
5. 需求的可追踪性：需求的可追踪性是指能够追溯需求背后的业务目标和价值。
在敏捷开发中，通过追踪需求的来源和变化，可以更好地控制项目的进度和质量。
二、变更控制变更控制是敏捷开发过程中不可或缺的一环。
在敏捷开发中，变更是常态，项目团队需要及时响应和适应变化。
以下是一些变更控制的关键点：1. 变更识别与评估：项目团队需要识别出变更请求，并对其进行评估。
评估的依据包括影响范围、变更的紧急程度和资源情况等，以便确定是否接受该变更。
2. 变更决策：变更决策需要由团队与客户共同参与，了解变更对项目目标、进度和质量的影响。
在决策过程中，需要充分沟通，权衡利弊，以确保变更的合理性和可行性。
3. 变更实施：一旦变更被接受并决策成立，项目团队需要及时执行变更，并将其融入到开发过程中。
敏捷开发中的需求分析与用户故事编写
敏捷开发中的需求分析与用户故事编写在敏捷开发过程中，需求分析是一个至关重要的环节。
它起到桥梁作用，连接着产品所有者与开发团队。
需求分析的目标是准确理解用户的需求，并将之转化为可执行的任务。
而用户故事，则是一种常用的需求表达方式，能够以简洁、直观的方式描述用户需求。
本文将详细介绍敏捷开发中的需求分析和用户故事编写。
一、需求分析需求分析是敏捷开发中的重要一环，其目的是明确产品的功能、性能、界面等方面的要求，以满足用户需求。
下面将介绍敏捷开发中的需求分析过程。
1.需求收集需求收集是指通过与用户交流、研究市场、分析竞争对手等方式，获取用户需求的过程。
在敏捷开发中，要与产品所有者密切合作，与他们进行面对面的交流，倾听他们对产品的期望和要求。
2.需求分解需求分解是将整体需求分解为更小、更具体的需求的过程。
这样做的好处是可以更好地管理和控制需求，将其分配给不同的团队成员，提高开发效率。
3.需求验证需求验证是确认需求的正确性和可实现性。
在敏捷开发中，可以通过原型展示、用户评估等方式进行需求验证，确保产品与用户需求保持一致。
二、用户故事编写用户故事是一种简洁、直观的需求表达方式，在敏捷开发中被广泛采用。
用户故事以用户的角度描述功能，通常包括角色、行为和目的。
下面将介绍如何编写用户故事。
1.角色用户故事中的角色是指使用产品的人，可以是真实的用户，也可以是其他系统。
角色应该尽可能具体明确，以确保故事描述的准确性。
2.行为行为描述了用户要完成的具体操作或动作。
它应该具备可测量性和可验证性，以方便开发团队明确开发目标，并进行必要的测试。
3.目的目的是描述用户进行某个行为的目标和需求。
它可以帮助开发团队更好地理解用户需求，并为用户提供更好的体验。
三、需求分析与用户故事编写的关系需求分析和用户故事编写是相互依赖、相互补充的过程。
需求分析是基础，是用户故事编写的前提。
通过需求分析，我们可以确定用户的真正需求，并将其转化为可执行的用户故事。
敏捷开发测试流程
敏捷开发测试流程
敏捷开发测试流程主要包括以下几个步骤：
1.需求分析：在敏捷开发中，需求分析是一个持续不断的过程，需要敏捷团队的产品经理或业务代表不断跟进需求，细化、补充、修正需求快速反应用户需求变化。
2.测试计划：在敏捷开发中，测试计划是一个重要的步骤，需要测试团队在产品未开发之前就开始规划测试任务、测试用例以及测试方法等，在后续的开发过程中进行完善和调整。
3.测试设计：根据测试计划中的测试需求，测试团队需要进行测试用例设计，确保详尽覆盖产品需求与功能，同时也可提出测试建议及测试环境需求。
4.测试执行：在敏捷开发中，测试是需要持续进行，所以测试团队需要紧密跟进产品的开发进度，及时对开发的产品进行测试，并向研发团队反馈产品的bug。
5.缺陷管理：测试团队在测试产品时，需要记录和管理测试过程中发现的问题或缺陷，包括对问题或缺陷的详细描述、优先级等信息，及时告知产品研发团队进行修改。
6.测试报告：测试团队会对测试结果进行分析和总结，并撰写测试报告，向项目
组、研发团队、产品经理等汇报产品的测试结果，反馈问题和瓶颈，以及产生的风险，方便及时调整。
7.迭代测试：根据敏捷开发的特点，测试团队需要持续地进行迭代测试，及时发现和解决问题，确保产品质量达到最优状态。
敏捷开发中的需求变更与变更管理
敏捷开发中的需求变更与变更管理敏捷开发方法论在软件开发领域逐渐流行起来，其核心思想是通过迭代、协作和快速响应变化来提高开发效率和质量。
在敏捷开发过程中，需求变更是不可避免的，因为客户需求经常会发生变化。
然而，如何有效管理和处理这些需求变更是一个关键挑战。
本文将探讨敏捷开发中的需求变更与变更管理，以及解决这一挑战的方法。
一、需求变更的原因及影响1. 需求变更的原因需求变更的原因主要包括客户需求的变化、市场竞争的变化、技术的进步等。
客户需求的变化可能是由于客户市场的变动、用户反馈、竞争压力等因素引起的。
市场竞争的变化可能导致原有的需求不再适应市场需求，需要进行调整。
技术的进步可能带来新的功能或者解决方案，需要对原有需求进行修改。
2. 需求变更的影响需求变更会对软件开发过程产生各种影响。
首先，需求变更会引起开发进度的延误。
原计划好的开发任务可能需要被修改或者重新安排。
其次，需求变更还会导致软件开发成本的增加。
如果需求变更频繁且不受限制，开发团队不得不不断地修改代码，增加了开发和测试的工作量。
此外，需求变更还可能导致软件质量下降。
频繁的需求变更意味着开发团队可能没能充分理解需求，容易出现功能缺陷或者逻辑错误。
二、敏捷开发中的需求变更管理1. 灵活的需求管理在敏捷开发中，需求管理要求具备高度的灵活性。
首先，开发团队应该与客户保持紧密的沟通与合作，及时了解到客户的新需求和变更需求。
其次，开发团队需要保持良好的开放心态，对变更需求给予积极的回应和支持。
最后，开发团队应该采用敏捷方法中的用户故事（User Story）或者规范化需求描述（Normalized Requirement Description）等技术手段来管理需求，确保需求的准确性和可追溯性。
2. 变更管理的实施变更管理是一种管理变更的流程，旨在保证变更的有序，减少变更可能带来的风险。
在敏捷开发中，变更管理不应该成为一个繁重的过程，而是应该是一个简洁高效的流程。
敏捷开发中的测试流程
敏捷开发中的测试流程敏捷开发是一种迭代式的开发方法，通过不断的迭代和反馈来快速交付高质量的软件。
测试在敏捷开发过程中起着至关重要的作用，它是保证软件质量的关键环节。
在本文中，将介绍敏捷开发中常用的测试流程，并探讨如何将测试融入到敏捷开发的每个阶段。
一、需求分析阶段中的测试在敏捷开发中，需求分析是非常关键的一步。
测试团队需要参与进来，与开发人员和产品负责人一同讨论和明确需求。
测试团队可以通过提出一些测试相关的问题，帮助完善需求，并确保需求的准确性和一致性。
二、计划阶段中的测试计划阶段是敏捷开发的第一个迭代周期，也是测试团队准备测试工作的时候。
在这个阶段，测试团队需要与开发团队一起制定测试计划，明确测试的范围、目标和策略。
测试团队还需要评估测试资源的需求，并与项目管理团队协商，确保能够及时获得所需资源。
三、设计阶段中的测试设计阶段是敏捷开发的第二个迭代周期，也是测试团队进行测试设计的时候。
在这个阶段，测试团队需要根据需求和开发人员提供的设计文档，编写测试用例和测试脚本。
测试用例应该覆盖所有的功能和边界条件，以确保软件的完整性和稳定性。
四、开发阶段中的测试开发阶段是敏捷开发的第三个迭代周期，也是测试团队进行测试执行的时候。
在这个阶段，测试团队需要执行之前设计好的测试用例和脚本，并记录测试结果。
测试人员还可以根据需要进行一些手工测试，以发现潜在的问题和漏洞。
与开发人员密切合作，并及时反馈测试结果和问题，以便他们及时修复bug。
五、部署阶段中的测试部署阶段是敏捷开发的最后一个迭代周期，也是软件发布前的最后一次测试。
在这个阶段，测试团队需要执行各种类型的测试，包括性能测试、安全测试、兼容性测试等，以确保软件可以在不同的环境和配置下正常工作。
测试团队还需要与运维团队一起制定软件的部署计划，并在部署过程中监控和验证软件的稳定性。
六、迭代和持续集成中的测试在敏捷开发中，软件的迭代是一个不断循环的过程，每个迭代周期都要进行测试。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
【摘要】在日趋激烈的电信业竞争态势下，持续而快速地发掘和响应商机成为新的课题。
作为响应机制中的关键环节，需求工程应用敏捷过程方法，以关注商业价值、快速响应、持续迭代的特征来应对变化和难测的未来，是尝试提高组织敏捷能力的核心。
在这其中，作为沟通桥梁的需求分析同样可以应用敏捷的过程方法参与到生命周期的演进。
敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面展现其不同传统的特性。
本文将结合电信业背景及企业实际情况，对敏捷需求分析作出初步的探索。
1、敏捷需求分析：电信行业背景与敏捷过程的需要从中国电信行业ITSP战略推出至今，数年中我们已经看到了明显的变化，作为其信息化体系落地的C TG-MBOSS，也已初具规模和成效。
大规模实施的下一个阶段，将是在商业价值引领下的重构竞争模式、市场细分，以及作为支撑的需求深入研究。
在项目实施过程中，各种挑战和困难纷至沓来，项目管理者不管是做时间、成本、质量的三角平衡，还是人与技术的双向选择，始终无法绕开的一个问题跟源是：如何快速响应环境的变化，使客户在优化的体验过程中满足其商业目标，从而实现企业本身的价值？用失控的过程膨胀来形容近10年的许多软件公司的情形是很合适的。
虽然有很多团队在工作中没有使用过程的方法，但是采用庞大、重型的过程方法的趋势却在快速增长，在大公司中尤为如此。
但现实的发展确与此不相同步，竞争态势造成了更多的不确定性和快速调整的机会。
从近年ERP上线的平均速度来看，项目的交付时间都比较长，这让用户产生了顾虑。
但实际上软件上线仅仅是一个软件生命周期早期的阶段，软件的价值是在使用中体现出来的，其投资回报也只能在后期的运营得到完成。
未来的变化如同纳西姆？塔勒布的黑天鹅一般不可预测且重要，已知和过去琐碎的重复并不足以预测未来的重大影响。
以预测性度量为控制基础的过程模型，只能以经验涵盖一般性事件，所以与此同时，随机应变，保持快速集成和持续改进以应对商业环境的不确定性，延长软件的生命周期提高它的最大价值，从而为获取更多投资回报提供保障，也成为软件工程发展的必然。
敏捷过程（Agile Process）的主要优势是能够适应系统需求的不确定性，将客户作为需求团队中密不可分的成员，而在实现过程中尽量在最短时间内实现对用户来说业务价值最大的需求；同时，敏捷开发（A gile Development）是一种面临迅速变化的需求快速开发软件的能力，它帮助处理了未来不确定性的问题；但是对于过去，应该没有不确定的事。
而敏捷需求分析，是面对迅速变化的商业状况，提高其响应和组织成可理解和接受的需求说明并对敏捷开发作出能力保证的方法论。
2、敏捷与过程改进和度量模型从软件工程发展起，过程改进在全球日益得到重视，ISO 9000/SW-CMM/CMMI各级的评估也在业界得以推展，这种氛围下，以RUP等为代表的过程模型也得到了广泛的应用。
但与此同时，敏捷的论调却异军突起，方兴未艾。
软件过程的多样性，源于过程环境和层次的不同；而过程选择的多样性和CMMI目标的通用性决定了过程改进途径的多样化。
运用一系列重方法，将在应对商机方面造成挑战；尤其是在企业的管理考核和过程模板仍更多的是一种瀑布式体系下，软件的实现过程将在不同模型下摇摆却显得不那么灵活。
一个合适的生命周期模型选择是重要的，由于惯性的教育，瀑布在我们的工作环境中随处可见。
但如果不去分析CMMI等的实质，将无助于改进这一点而提高响应。
强调结构化方法与重型的管理策略，往往在内心中拒绝变更，把变更作为被管理甚至被“管制”的对象；而为了尽可能避免变更，常常要求开发之前的需求获取、分析与定义要完整无误且精确。
这是一种理论上的理想状态，尽管我们可以采取诸如CMMI的一些理念及过程改进模板对其管理，但实际上往往会出现与用户商业价值要求的脱节；而为达成此目标，使得前期的需求开发工作变得小心翼翼，最终有可能在压力与时间约束下难免简单化而草草了事，在后期又不能得到及时的修正，从而形成一个隐患。
但实质上，重型、轻型过程方法论之间并不存在根本性的矛盾冲突，这体现于它们最终理念和出发点的一致。
把这些互补方法论拼在一起，“恰好可以发现整个软件过程体系全貌的一部分”。
CMM/CMMI 中不包括更为具体一点的如何写好需求，如何做好设计，如何写好测试等许多方面的软件工程技术、技能方面的指导，而这些恰好是敏捷的强项。
敏捷方法整合了一套轻量的管理、过程和工程技术方法，这是它作为一种先进方法体系补充于CMMI 的地方。
敏捷过程并不像业界所传的那样只适合小项目和新项目的研发，实际上它对于各种类型，包括企业所定义的A类、B类、C类在CMMI体系基础上都是可取舍适用的。
这需要过程体系间的适当裁剪和调整组合。
敏捷需求分析，将在全过程中扮演衔接、沟通和渗透的作用。
3、敏捷需求分析的过程特性IEEE对需求的定义是用户解决问题或达到目标所需的条件或性能；系统或系统部件要满足合同、标准或其他正式规定文档的条件或性能。
需求是设计、构造产品的前提，简单地说，是必须完成的事及其所必须具备的品质。
需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为提交的产品的一部分[5]。
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
业务需求（bu siness requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario）说明中予以说明。
功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。
图1. 需求的层次及组成我们可以看到，不管是传统的还是敏捷的需求开发阶段，需求的层级及组成，其基本特性是一致的，这反映方法的差异并不改变需求的本身属性。
一般的需求三个层次，忽略了一个问题，即每个层次所需的知识、技能、经验、背景等是不同的，不同的层次过程中，需要不同资源的整合。
业界相关的论述中，只是给出了笼统的需求分析人员的统一角色，但并未对其作出区别。
实际上，这很难映射到中小企业的现实操作层面。
这引发了我们进入详细的敏捷需求分析话题中第一个问题，需求的参与者如何定义？3.1 需求的参与者敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。
在《敏捷宣言》（Manife sto for Agile Software Development）中，强调了客户一起现场工作的重要性。
而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。
但应该清楚，这种纳入并不能真正代替真实的客户参与。
对于客户无法全程现场参与的情况，BA的出现是一种弥补。
BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。
同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptancetest）。
而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。
当然，这项工作可以分解为另外的角色来进行。
开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。
一个完整描述的用例可以很方便地导出测例（test case）。
而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。
我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为Acceptance Driven Development。
从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。
各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。
对于角色及其参与方式，我们可以比较如下：表1：需求的主要参与者（其他的stakeholders并未全部列出，比如PM、QA等）这些参与者如何工作的呢？我们引入到需求分析的工作形式。
3.2 敏捷需求分析工作形式敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。
比如，敏捷联盟所推荐的现场客户工作。
但多数情况下，客户都是很忙碌的，很难全力投入到过程中。
这时候，我们就需要BA这个角色，来充当客户的角色。
BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。
而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。
敏捷思想的核心是人与人的交流。
聚议是一种面对面的最好形式，它能促成问题从多个角度的现场核清。
在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。
对于需求分析中所用的各种形式，用户其实并不排斥参与——尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。
在某省电信运营商的项目中，我们已经发现了这一点。
用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。
在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。
迭代是敏捷最显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。
这些将在下文中讨论。
迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。
包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。
3.3 需求分析时机传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。