正确执行的敏捷消除了对经典需求工程的需求。
需求工程是引出涉众需求和愿望，并将它们发展成一组商定的详细需求的过程，这些需求可以作为所有后续开发活动的基础。需求工程方法的目的是使所陈述的问题清晰和完整，并确保解决方案是正确的、合理的和有效的。
＇涉众需求“看起来很奇怪。当然，我们有利益相关者，但最终我们只需要确保我们满足了用户的需求。(用户是一种利益相关者)。”清晰和完整，以确保解决方案是正确的。’是另一种有趣的措辞;我不愿意说我的要求是明确和肯定的，从来没有完整过。如何保证正确?我们不是在解一个数学方程，而是在为一个还不知道自己想要什么的客户设计一个解决方案，在一个我们还不了解的技术中，在一个不断变化的环境中。无论你如何打磨你的水晶球，总会有波动、不确定性、复杂性和模糊性。欢迎来到VUCA(3)世界。
软件产品的RE的结果是文档。这个文档的目的是什么?它是关于通过持久化信息来编纂知识。你可以在几个月或几年后再读它们，仍然能得到同样的意思。糟糕的是，记录和阅读是一个非常有损的过程。所以，意思经常被扭曲。
那么我们为什么要这么做呢?它的历史。在过去，我们按照活动的顺序工作:计划、分析、设计、实现、测试、发布．第一步”．.．作为所有后续发展活动的基础……’，它们都是为了引出需求，将它们表达成需求然后把它们投进去然后交给IT部门的程序员(创造和加强筒仓)。基本的信念是，我们可以事先知道一切。一旦项目完成，抱怨和指责就开始了。产品发现和产品交付被清晰地分开。
敏捷来拯救(看看敏捷宣言(4)中的原则)!而不是被我们计划的活动所驱动一切,分析一切、设计一切,……(有趣的是，我们在一开始就做了所有的计划，尽管我们知道的最少——但这是另一篇文章)在Scrum中，我们被用户价值最大化所驱动。结合产品发现和产品交付。我们垂直切片，我们在一个Sprint中完成以上所有的活动．识别最有价值的特征(例如:风险，业务影响，…)，分析，设计，实现，测试，直到可能发布。我们没有创建文档，而是创建了一个真正的工作软件产品，在Sprint评审中向我们的利益相关者和用户演示，从而创建了真正的透明度。这种方法的重要好处是通过足够的资源来创建一个共享的心理模型与所有相关方的对话:产品负责人、开发人员(包括所有必需的技能，如:编程、测试、业务分析、用户体验等)，以及必要的用户。我们创建的信息通常被写入用户故事(如果你不知道，用户故事的定义:它是一个对话发生的承诺(5)，它是关于谈话，而不是写作)。对话创造了认知上的一致性，使我们能够朝着同一个方向前进。罗恩·杰弗里斯把它和他的完美结合卡，谈话，确认(3 c)模型。(6)
简而言之:我们与合适的人交谈，我们的发现写在一张卡片上(或在一张票上;包括验收测试)。确认确保它正确工作并被用户接受(验证和验证相结合)。一个完整的垂直切片的产品发现和交付，及时-精益再生。
如果你要说，‘我们需要文件，因为……’，别担心，我有好消息。为此，Scrum有完成的定义(DoD)。国防部除了确保无所不在的非功能性需求(NFR)和确保良好的工程实践之外，还可以要求需求文档、规范文档、体系结构文档、测试文档、操作文档……与可用产品并行创建并保持每个Sprint的更新。更好的是，由于文档是在工作完成后创建的，因此持久化的知识是正确的，不需要返工(通常不需要返工)。这甚至可以应用于规范的环境中。
这一切都是关于愿景、价值和验证。(3对)(7)
(1）https://www.sciencedirect.com/topics/computer-science/requirement-engineering
(2)阿利斯泰尔·考伯恩
（3）https://en.wikipedia.org/wiki/Volatility,_uncertainty,_complexity_and_ambiguity
(4) http://agilemanifesto.org/principles.html
(5)阿利斯泰尔·考伯恩
(6)https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/