为了解决前文所述的软件需求困境，我们首先需要找到一种可以被各方真正理解和沟通、并可以被逐步精化的需求体系。我认为，这种体系应该是基于用例（usecase）的。
首先，让我们仔细研究一下用例的定义：
一个用例抽象了目标系统在现实中将执行的一组场景（每个场景由一系列动作组成）；这些场景会产生一个对某个Actor有价值的、可观测的结果;
在这个定义中，我们强调了两件事情：一、用例是被从现实的场景中抽象出来的，而不是被随便发明出来的；二、每个用例（场景）应能提供完整的商业价值。在未来的博文里会介绍这两条会如何帮助我们避免对用例的误用。
用例的优势在于它天生是黑盒的，它用自然语言抽象了用户和目标系统的交互，避免了混入分析、设计和实现细节，以保证用例可以被不懂具体技术的业务及测试人员所真正理解。同时，需求分析员又可以方便地通过用例分析（use case analysis）（即用分析类来试图在理想方式下实现用例），将需求体系精华成分析模型。在这一过程中，需求分析员可以更进一步地完善基于用例的需求体系，而不必担心分析模型会污染需求，从而实现需求与分析的分离及有效互动。
最后，我们必须指出，基于用例的需求管理体系中不仅仅包含用例，它还应该包括涉众请求，特性列表，前景文档，补充规约，词汇表等等。
用例其实是Ivar在许多年前发明的老技术了，现在被很多人所采用，而被更多人误用，下面的文章让我们看看一些对用例的典型的误解和误用。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
