发现功能需求的的目的，是要形成构建的产品的一份合约，因此，功能性需求必须十分详细的描述预期的产品将执行哪些活动。为了满足这个指标，功能性需求必须包含足够的细节，让开发能够构造出正确的产品，使需求分析师与利益相关方的误解减少到最低程度。
为了使需求更规范、清晰、有条理，就需要考虑发现和组织需求的方法。我们可以这样来考虑：
- 首先：把每个用例看成一个大的需求集，描述清楚这些需求集之间的交互关系，这就自然的使需求与用例之间有了映射关系。
- 其次：把视野集中在每个用例。一个用例表现了为实现一个大的目标所必需的行为，而每一个大目标需要若干小目标来实现，这个小目标就是事务。在用例点规模估计中，我们已经定义了事物就是从用户到系统，再回到用户的一个“环形路线”，我们可以把每个用例所包含的若干事务分离出来并进行命名。这就有了一个清晰的需求框架。
- 最后：再把视野集中到每个事务，仔细分析为了完成这个小目标（事务），系统需要哪些功能？这些功能有哪些模糊不确定的地方？能不能据此定义开发？
这种从功能集到事务再到功能的层层分解方式，不但减少了需求定义的难度，而且是最后形成需求文档和用例文档之间有很好的追踪关系，下图展示了这种渐进式得到功能性需求的方法。
我们用已经讨论过的“预订房间”作为案例，讨论如何在场景中发现事务并细化功能的。
据此可以发现功能需求如下：
在完成了每个场景的功能提取之后，需要整体审视一下已经形成的功能表，看看哪些功能是重复的可以共享的，并把它们提取出来。虽然在编写用例场景的时候，已经利用用例的包含关系做了一些这方面的工作，但是基于下面一些原因可能是不充分或者不正确的：
- 最初掌握的信息不足，不足以发现更多的共享功能；
- 场景可能是由不同的人编写的，限于范围，不足以发现更大范围内的共享。
在掌握更多信息的情况下，我们会发现原来用例场景的不足，从而修正用例的场景，使他们趋于完善。我们用上一章讨论过的宾馆管理作为例子，最初编写场景的时候针对顾客和柜台服务员的应用场景，是由不同的人编写的，所做出的用例可能是下面的样子。
在针对每个场景提取功能需求之后，在统一审视的情况下，人们发现在每个用例中都存在“查询房间详情”的功能集。于是把它们提取出来，反过来修正原来的用例，如下图所示。
我们不可能一下子掌握所有情况，对情况的掌握是在过程中逐步完成的，这种后一步骤对前一步骤的修正称之为反馈。在软件工程中，有效的利用反馈过程的原理，可以大幅度提升每个过程的质量。
例如，前面我们在明确了客户需求之后，根据新掌握的信息，可能会修正原来确定的范围（总比到了最后范围蠕变强）；在功能提取之后，可能会修正原来确定的场景；在进入设计阶段，根据掌握的更多设计信息，可能会修正最初确定的需求；在每个阶段集成测试并评审之后，我们可能会根据已经获得的新情况，修正已有设计，甚至提出需求变更要求。
遇到这些情况不要奇怪，这正是符合人们认识事物的螺旋上升法则，与其避开这种螺旋性，还不如承认它，并利用它帮助我们提升质量。不要怕修改，精雕细刻与粗制滥造根本性的区别，就是一个是反复修改的，一个是做出来就算了。那么这会不会影响效率呢？从一个节点看是会的。但是从整体上看，前期付出的努力会在后期获得丰厚的回报，并且会大大提升整体的效率。这种精益求精的文化，无论对于企业还是个人，都是良好的正向推动力。