敏捷过程中的需求分析
敏捷开发流程的8个步骤
敏捷开发流程的8个步骤敏捷开发是一种以迭代、循序渐进的方式进行软件开发的方法论，它强调团队合作、快速响应变化和持续交付价值。
在敏捷开发过程中，有以下8个主要步骤。
1. 需求收集与分析在敏捷开发中，需求是一个动态的过程，不断地收集、分析和细化。
团队与客户紧密合作，明确项目的愿景和目标，并将其转化为用户故事或需求项。
通过不断的讨论和反馈，团队可以更好地理解客户需求，并将其转化为可执行的任务。
2. 规划与估算在敏捷开发中，规划是一个迭代的过程。
团队根据客户需求和项目目标，制定短期的开发计划，确定每个迭代的工作范围和目标。
同时，团队也需要对工作量进行估算，以便更好地安排资源和时间。
3. 设计与开发在敏捷开发中，设计和开发是并行进行的。
团队利用迭代周期进行软件设计和编码，采用简单而优雅的解决方案。
团队成员经常进行代码审查和知识分享，以确保代码的质量和可维护性。
4. 测试与验证在敏捷开发中，测试是一个持续且重要的过程。
团队进行单元测试、集成测试和系统测试，以确保软件的质量和功能完整性。
同时，团队也需要与客户进行验证，确保软件满足客户的需求和预期。
5. 交付与部署在敏捷开发中，交付和部署是一个可重复且自动化的过程。
团队使用持续集成和持续交付的工具和方法，将软件快速交付给客户。
同时，团队也需要确保软件能够顺利地部署和运行。
6. 反馈与优化敏捷开发强调不断地学习和改进。
团队与客户保持密切的沟通，收集用户反馈和需求变更。
团队通过迭代回顾和持续改进的方式，优化软件的功能和性能。
7. 沟通与协作在敏捷开发中，沟通和协作是非常重要的。
团队成员之间需要密切合作，共同解决问题和完成任务。
团队与客户之间也需要建立良好的沟通渠道，保持及时的反馈和信息共享。
8. 迭代与持续交付敏捷开发是一个持续迭代的过程。
团队通过多次迭代的方式，逐步完善软件，持续交付价值。
团队通过反馈和学习，不断优化和改进软件的质量和功能。
总结敏捷开发是一种灵活、高效的软件开发方法论。
解读敏捷需求分析五大关键因素
代逐步精化；
・ 整 个 过 程 中 以 分 析 为 支 撑 ， 做
需 求 同 时 也 在 做 分 析 ，分 析 模 型 的 输 出结 果 应 跟 需 求 分 开 ；
需 求 文 化 与敏 捷 的 衡 点 Ｉ ￡
至于 用例 和用户 故事 。按 照敏捷 大 ９Ｍａｔ 博客 中的说法 ，两者都是组 ￣ ｒｎ ｆ ｉ
织 需 求 的 方 式 ， 只 是 目的 不 同而 已 ， 用 例 的 目 的是 为 了 把 需 求 描 述 清 楚 ， 而 用 户 故 事 的 目 的 是 把 需 求 分 解 成 可 用 于 迭 代 计 划 的 单 元 。 对 应 到 产 品级
瀑 布 式 开 发 中 ， 更 多 的是 合 同 式 验 证 的 情 形 ， 大 多 数 客 户 的思 想 基 础 都 是 基 于 需 求 最 初 就 能 确 定 下 来 的 。但 事 实 上 ，这 在 当 前 阶 段 基 本 属 于 “ 可 不 能 完 成 的 任 务 ” ，不 符 合 软 件 开 发 本 质 。 在 敏 捷 需 求 分 析 中 ， 需 求 应 是 贯
虑 如 何 实 现 如 何 合 理 调 整 工 作 量 提 高 效 率 ， 这 些 都 是 找 （ 户 ） 故 事 的 过 用
程 ，也 是 一 个 白盒 的过 程 。
・ 迭 代 ， 即 需 求 不 是 一 次 最 终 确 定 ， 而 是 先 完 成 主 要 框 架 ， 再 通 过 迭
些核心 功 能是 不 改变 的，这 些都 是产
敏捷开发测试流程
敏捷开发测试流程
敏捷开发测试流程主要包括以下几个步骤：
1.需求分析：在敏捷开发中，需求分析是一个持续不断的过程，需要敏捷团队的产品经理或业务代表不断跟进需求，细化、补充、修正需求快速反应用户需求变化。
2.测试计划：在敏捷开发中，测试计划是一个重要的步骤，需要测试团队在产品未开发之前就开始规划测试任务、测试用例以及测试方法等，在后续的开发过程中进行完善和调整。
3.测试设计：根据测试计划中的测试需求，测试团队需要进行测试用例设计，确保详尽覆盖产品需求与功能，同时也可提出测试建议及测试环境需求。
4.测试执行：在敏捷开发中，测试是需要持续进行，所以测试团队需要紧密跟进产品的开发进度，及时对开发的产品进行测试，并向研发团队反馈产品的bug。
5.缺陷管理：测试团队在测试产品时，需要记录和管理测试过程中发现的问题或缺陷，包括对问题或缺陷的详细描述、优先级等信息，及时告知产品研发团队进行修改。
6.测试报告：测试团队会对测试结果进行分析和总结，并撰写测试报告，向项目
组、研发团队、产品经理等汇报产品的测试结果，反馈问题和瓶颈，以及产生的风险，方便及时调整。
7.迭代测试：根据敏捷开发的特点，测试团队需要持续地进行迭代测试，及时发现和解决问题，确保产品质量达到最优状态。
敏捷开发中的需求变更与变更管理
敏捷开发中的需求变更与变更管理敏捷开发方法论在软件开发领域逐渐流行起来，其核心思想是通过迭代、协作和快速响应变化来提高开发效率和质量。
在敏捷开发过程中，需求变更是不可避免的，因为客户需求经常会发生变化。
然而，如何有效管理和处理这些需求变更是一个关键挑战。
本文将探讨敏捷开发中的需求变更与变更管理，以及解决这一挑战的方法。
一、需求变更的原因及影响1. 需求变更的原因需求变更的原因主要包括客户需求的变化、市场竞争的变化、技术的进步等。
客户需求的变化可能是由于客户市场的变动、用户反馈、竞争压力等因素引起的。
市场竞争的变化可能导致原有的需求不再适应市场需求，需要进行调整。
技术的进步可能带来新的功能或者解决方案，需要对原有需求进行修改。
2. 需求变更的影响需求变更会对软件开发过程产生各种影响。
首先，需求变更会引起开发进度的延误。
原计划好的开发任务可能需要被修改或者重新安排。
其次，需求变更还会导致软件开发成本的增加。
如果需求变更频繁且不受限制，开发团队不得不不断地修改代码，增加了开发和测试的工作量。
此外，需求变更还可能导致软件质量下降。
频繁的需求变更意味着开发团队可能没能充分理解需求，容易出现功能缺陷或者逻辑错误。
二、敏捷开发中的需求变更管理1. 灵活的需求管理在敏捷开发中，需求管理要求具备高度的灵活性。
首先，开发团队应该与客户保持紧密的沟通与合作，及时了解到客户的新需求和变更需求。
其次，开发团队需要保持良好的开放心态，对变更需求给予积极的回应和支持。
最后，开发团队应该采用敏捷方法中的用户故事（User Story）或者规范化需求描述（Normalized Requirement Description）等技术手段来管理需求，确保需求的准确性和可追溯性。
2. 变更管理的实施变更管理是一种管理变更的流程，旨在保证变更的有序，减少变更可能带来的风险。
在敏捷开发中，变更管理不应该成为一个繁重的过程，而是应该是一个简洁高效的流程。
敏捷开发中的测试流程
敏捷开发中的测试流程敏捷开发是一种迭代式的开发方法，通过不断的迭代和反馈来快速交付高质量的软件。
测试在敏捷开发过程中起着至关重要的作用，它是保证软件质量的关键环节。
在本文中，将介绍敏捷开发中常用的测试流程，并探讨如何将测试融入到敏捷开发的每个阶段。
一、需求分析阶段中的测试在敏捷开发中，需求分析是非常关键的一步。
测试团队需要参与进来，与开发人员和产品负责人一同讨论和明确需求。
测试团队可以通过提出一些测试相关的问题，帮助完善需求，并确保需求的准确性和一致性。
二、计划阶段中的测试计划阶段是敏捷开发的第一个迭代周期，也是测试团队准备测试工作的时候。
在这个阶段，测试团队需要与开发团队一起制定测试计划，明确测试的范围、目标和策略。
测试团队还需要评估测试资源的需求，并与项目管理团队协商，确保能够及时获得所需资源。
三、设计阶段中的测试设计阶段是敏捷开发的第二个迭代周期，也是测试团队进行测试设计的时候。
在这个阶段，测试团队需要根据需求和开发人员提供的设计文档，编写测试用例和测试脚本。
测试用例应该覆盖所有的功能和边界条件，以确保软件的完整性和稳定性。
四、开发阶段中的测试开发阶段是敏捷开发的第三个迭代周期，也是测试团队进行测试执行的时候。
在这个阶段，测试团队需要执行之前设计好的测试用例和脚本，并记录测试结果。
测试人员还可以根据需要进行一些手工测试，以发现潜在的问题和漏洞。
与开发人员密切合作，并及时反馈测试结果和问题，以便他们及时修复bug。
五、部署阶段中的测试部署阶段是敏捷开发的最后一个迭代周期，也是软件发布前的最后一次测试。
在这个阶段，测试团队需要执行各种类型的测试，包括性能测试、安全测试、兼容性测试等，以确保软件可以在不同的环境和配置下正常工作。
测试团队还需要与运维团队一起制定软件的部署计划，并在部署过程中监控和验证软件的稳定性。
六、迭代和持续集成中的测试在敏捷开发中，软件的迭代是一个不断循环的过程，每个迭代周期都要进行测试。
敏捷开发过程中的需求分析
、 、 、
,
,
、
、
需 求 分 析 时机
更 多 地 集 中在 项 目早 期
近 乎 均 匀 地 贯 穿于 项 目 的
大大加快系统上 线或 产 品投 放 市 场 的速 度
一
前 两 个 阶 段 总 体 上 是 在 项 目初 期
一
整个 生 命周 期
。
次 性进行 的
，
分 析 工 作 的主 要 目 的
a s e
有进 行 软 件 开 发 活 动 的读 者 作 为 参 考
能 够 适 应 系 统 需 求 的不 确 定 性
。
需 求分 析
”
阶段
，
。
需 求分 析 工 作 大 体
如表2 所示
。
敏捷软件 开 发过 程 的主 要优 势是
，
上 分 为 四 种 类型
将客
，
表 2 需 求分 析 工 作 的四 种 类型
其实两 类方法 并不 是 非此
L／ 1
①
U
‘．J
U
阿
L
吐
敏捷开发过程 中的需求分析
在 做 需 求分 析 时
更五 个方面
。
錾 林
，
敏 捷 与 传统 方 法 的 差 异 体 现 在 分 析 时机
、
划分 单位
、
细化过 程
、
文 档 要 求和 应 对 变
■
文 ／桑 大 勇
“
天 雾蓁篓嚣警雾 冀蓑霎 兰 篙
甚嚣 尘 上
，
单
于 轻 量 级 的敏 捷软 件 开 发 方
表 1 传 统 需 求 分 析 方 法 与 敏 捷 需 求分 析 方 法 的 对 比
个 具 有 完 整 业 务 价 值 和 功 能 的可 运 行软件 将 项 目分
敏捷开发的关键要素：迭代与需求管理
敏捷开发的关键要素：迭代与需求管理敏捷开发是一种以人为中心、自组织、迭代和增量开发为特点的软件开发方法。
它强调快速响应变化、灵活性和透明度，旨在提高团队的生产力和工作效率。
敏捷开发的关键要素包括迭代和需求管理。
首先，迭代是敏捷开发的核心要素之一。
迭代是指将整个开发过程分解为若干个短周期的开发阶段，每个阶段都包含需求分析、设计、编码、测试和部署等工作。
每个迭代都有一个可交付的产品增量，在每个迭代结束时，团队会对产品增量进行评估和反馈，然后根据反馈进行调整和改进，进入下一个迭代。
迭代的周期通常为2至4周，这使得团队能够更快地响应变化和适应需求变更。
通过采用迭代开发的方式，团队可以在项目的早期进行需求验证和反馈，减少了开发过程中的风险，提高了产品的质量和客户满意度。
其次，需求管理是敏捷开发的另一个关键要素。
在传统的开发方法中，需求通常在项目一开始就被全面定义和决定，而在敏捷开发中，需求是可以变化的，并且是通过与客户和用户的密切合作来收集、分析和确认的。
敏捷开发强调与客户和用户的持续沟通和合作，通过快速迭代和增量开发，及时反馈和响应需求变更。
需求管理的关键是建立一个有效的沟通和协作机制，确保团队和客户之间的需求理解一致，并及时识别和处理需求冲突和变更。
需求管理需要灵活性和透明度，团队需要能够快速理解和响应新的需求，同时也需要向客户和用户显示其工作进展和产品质量。
除了迭代和需求管理之外，敏捷开发还强调以下几个关键要素：1.自组织和团队协作：敏捷开发强调团队的自主决策和自我管理能力。
团队成员需要在一个相对自由和开放的环境中协作和合作，共同完成项目的目标。
团队应该具有多样化的技能和知识，以便能够互相支持和帮助，同时也需要建立良好的沟通和信息共享机制。
2.持续集成和自动化测试：敏捷开发倡导持续集成和自动化测试，这些能够帮助团队在开发过程中及时发现和修复问题，减少开发周期和成本。
持续集成是指开发团队将代码频繁地集成到共享的代码仓库中，以确保各个模块之间的兼容性和稳定性。
敏捷测试的流程与方法
敏捷测试的流程与方法敏捷测试是一种迭代式开发方法中必不可少的环节，旨在确保软件质量并提供反馈。
本文将介绍敏捷测试的流程和一些常用的测试方法。
一、敏捷测试的流程1. 产品需求分析在敏捷开发中，测试团队与开发团队密切合作，在需求阶段参与讨论并与业务分析师、产品经理一起分析需求。
测试团队了解需求后，制定测试策略和计划。
2. 编写测试用例基于需求分析，测试团队编写详细的测试用例，包括测试步骤、预期结果和测试数据等。
测试用例应覆盖各种场景和边界条件，以尽可能发现潜在的缺陷。
3. 进行单元测试单元测试是开发人员在编写代码时自测的过程。
测试团队可协助开发人员编写单元测试用例，并进行代码审查，确保代码的质量和覆盖度。
如果发现问题，开发人员应及时修复。
4. 进行集成测试集成测试是将各个独立的单元组合在一起进行测试。
测试团队验证不同模块之间的接口是否正常，是否能够协同工作。
通过集成测试，可以及早发现系统集成带来的问题并解决。
5. 进行系统测试系统测试是在整个系统集成完成后进行的全面测试。
测试团队基于测试用例进行功能、性能、兼容性等各方面的测试，并记录和报告问题，与开发团队紧密配合以解决问题。
6. 进行验收测试验收测试是最后一道测试阶段，测试团队模拟最终用户使用系统，确认系统是否满足业务需求和用户期望。
开发团队根据测试结果进行调整和修改，直到符合需求为止。
7. 进行持续集成与部署测试持续集成是指开发人员频繁地将代码合并到主干，并进行自动化构建、测试和部署的过程。
测试团队应确保持续集成过程中的质量控制，包括检查代码冲突、运行自动化测试等。
二、敏捷测试的方法1. 自动化测试自动化测试是利用工具或脚本来执行测试用例，提高测试效率和准确性。
通过自动化测试，可以快速回归和执行大量重复性的测试，减少测试时间和人力成本。
2. 探索性测试探索性测试是一种以发现缺陷为目标的测试方法，通过测试人员的经验和直觉进行测试。
测试人员在没有明确的测试用例的情况下，根据系统的特点和背景进行测试，以发现更多的缺陷。
- 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 需求分析时机传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。