过程中并在其中不断变更、迭代和完善。
敏捷需求分析认为，需求应建立在以用例为中心的需求文档体系，采取协作式而非合同式的沟通方式之上。具体可分为五个关键点：
用例；
协作；
迭代，即需求不是一次最终确定，而是先完成主要框架，再通过迭代逐步精化；
整个过程中以分析为支撑，做需求同时也在做分析，分析模型的输出结果应跟需求分开；
把用例分解到用户故事，在整个软件生命周期过程中来驱动开发和测试。
业务/技术沟通频现“两份需求”
同时还要考虑到的是，将两份需求改为一份文档，而不必死抠CMMI概念区分出用户和软件需求。首份需求稿将由SA（系统分析师）来牵头完成，负责各方协调和沟通的工作。理想的情况下，整个团队在项目开始前就应搭建完毕，包括客户、开发测试人员都参与的写作和迭代，而不是以往的由技术人员对用户进行里程碑式的教辅。通常来说，一个项目里一名SA同时对应5~9名开发人员是比较合适的。
需求文档化与敏捷的平衡点
至于用例和用户故事。按照敏捷大师Martin博客中的说法，两者都是组织需求的方式，只是目的不同而已，用例的目的是为了把需求描述清楚，而用户故事的目的是把需求分解成可用于迭代计划的单元。对应到产品级和项目级文档，用例是产品级，例如做咖啡机，不管有多少不同版本，有些核心功能是不改变的，这些都是产品级需求。而用户故事则是项目级，属于做完就扔的“抛弃型”。
进一步理解的话，用户故事其实是一个或多个完整的业务场景，而用例是场景的抽象，一个用例里可以包含成百上千个场景。用户故事是基于开发思想的，不光要考虑业务，还要考虑如何实现包括工作量大小、任务分配、项目风险以及架构风险等多重因素。有人认为写用户故事是极简单的事，但在吴穹看来，现在有很多人都还在用功能点套用用户故事，显得不伦不类，而没有理解到用户故事的精髓。
以ATM取款为例，正常流程是插卡、取钱、把钱拿走。这个看似简单的场景其实工作量很大，可以在整个流程中做一些必要的简化。有人认为既然用户故事是一个场景，那就把它变成一个场景步骤吧，于是就成了功能点。其实他们忽略了一点，用户故事还是一个简化了但还保证完整业务价值的场景。ATM取款建立用户故事会涉及哪些因素呢？取款是否需要输入密码？小额取款时能否取消密码输入的步骤？取钱后打印账单，查询余额等，在这里面哪些功能是风险级别高的，哪些需要与银行核心数据通信？这不仅涉及（功能）优先级的问题，还可以根据原则简化用户故事。例如可以考虑做一个用户故事，储户用不需验密的卡，限额是一千块，取几百块钱的时候，把去银行验证的过程取消掉。这种情形下很多时候都要考虑到账户的风险情况，这些都需要多方沟通。类似的用户故事简化的情形有很多，但这时一定基于黑盒方式来做简化。而在简化的过程中，考虑如何实现如何合理调整工作量提高效率，这些都是找（用户）故事的过程，也是一个白盒的过程。
在实现上，除了强调快速交付或生命周期很短、业务模式高度可变的互联网、网游等项目，可以采用纯用例的模式，现阶段让（大型）企业IT项目全面接纳需求完全无文档化还是不现实的，更实际的解决办法是在文档化和敏捷需求分析之间找到一个平衡，一份需求用例加上用户故事，然后驱动开发这种方式，目前看来，这是现阶段更适合大型企业的敏捷需求实践模式。