一、需求矛盾
根据CHAO的权威统计，虽然自"软件危机"提出以来，软件工程方法得到了长足的发展与进步，但在去年的软件项目成功率仍然不足30％，绝大多数的软件项目仍然超进度、超成本。而在这些不成功的项目中，由于需求不清晰、需求不完整等方面的因素，占到了60％左右。
下面的这幅漫画虽然不乏夸张，但却是能够激起我们的深思：
根据笔者多年来从事软件需求捕获、分析工作的实践经验，认为造成这一现象的根本原因在于客户与开发人员之间的沟通存在障碍，双方都以自己的角度、自己的专业术语进行沟通，这使得大家并不能够很好地就软件需求达成共识。
由于帮助客户更好地利用信息化工具提高工作效率，是我们软件开发团队的责任，因此我们没有权利让用户理解我们所用的语言，而是反过来，我们有义务去理解用户的语言，站在用户的角度看问题。
而事实上，许多开发团队经常抱怨"我们的客户连需求都说不清楚"、"我们的客户对计算机了解太少了"。多年以来，大家都习惯从自己的角度来定义、分析问题，这也就造成了软件行业成为了一个最缺乏信任的行业，我们需要改一下习惯了。
二、现代需求实践
针对这些现象，许多先贤们开始了实践，并且总结出了一系列优秀的需求实践：
1）Use case：用例分析技术
鼎鼎大名的RUP是这样总结自己的：用例驱动，以体系结构为中心，迭代、增量的开发过程。Use case也伴随着RUP、UML一起名扬天下。
用例用来描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员（风险承担人，Stakeholder）之间就系统的行为所达成的契约。
2）User Story：用户故事、用户素材
用户故事是Kent Beck在极限编程（XP）方法论中推荐的最佳实践之一。它由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语写就，三句话左右。
3）Feature：特征
这是特征驱动开发（FDD）方法论的核心实践之一。一个特征就是一个小的，具有客户价值的功能，通常表示为<action><result><object>。
从上面的定义来看，这三种现代软件工程需求实践无一例外地遵从两个原则：一是站在用户的角度看待系统、定义系统；二是用用户看得懂的语言表达。而在笔者的实践中，鉴于以下两点考虑还是先在团队中应用了"用例分析技术"：
1）用户故事略显粗糙，掌握起来需要经验，没有详细的规则用于按部就班，一开始采用容易迷失方向；而用例相对来说更加形式化，易于上手；
2）特征看上去很有吸引力，但毕竟相关的理论还未完整，引入团队实践有些困难。
三、用例分析技术简介
用例分析技术是Rational三友之一Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。Ivar先生在加盟Rational之后，与三友合作提出了UML、完善了RUP，用例分析技术也因此被人广泛了解和关注。
用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。
许多人是在学习UML的时候接触到Use case，所以许多人都误解其为一种图表，把用例图当作用例分析的全部，其实这是错误的，用例描述才是用例分析技术的核心。下面是一个简单的例子：
3.1 参与者，Actor
参与者，定义了用户在系统交互过程中扮演的角色，其可以是一个人，也可以是另一个相关的系统。
3.2 用例，Use case
用例实例（场景）是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例（场景）。
一个用例应为参与者提供（实现）一个价值。
3.3 事件流
就像类对应于对象一样，一个用例的实例就是使用场景，用例就是对使用场景进行抽象的总结：
1）前置条件：指在用例启动时，参与者（Actor）与系统应置于什么状态，这个状态应该是系统能够检测到的、可观测的；
2）后置条件：用例结束时，系统应置于什么状态，这个状态也应该是系统能够检测得到的、可观测的；
3）基本事件流：基本事件流是对用例中常规、预期路径的描述，也被称为Happy day场景，这时大部分时间所遇到的场景；它将体现系统的核心价值；
4）扩展事件流：主要是对一些异常情况、选择分支进行描述。
建议大家在编写事件流时，注意以下几点：
1）使用简单的语法：主语明确，语义易于理解；
2）明确写出"谁控制球"：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；
3）从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是第三者的角度；
4）显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键做为一个事件就是不合适的）；
5）显示参与者的意图而非动作（光有动作，让人不容易直接从事件流中理解用例）；
6）包括"合理的活动集"（带数据的请求、系统确认、更改内部、返回结果）；
7）用"确认"而非"检查是否"：（如系统确认用户密码正确，而非系统检查用户密码是否正确）；
8）可选择地提及时间限制；
9）采用"用户让系统A与系统B交互"的习惯用语；
10）采用"循环执行步骤x到y，直到条件满足"的习惯用语。
四、Alistair Cockburn眼中的用例分析技术
在使用用例分析技术时，很多人都觉得如何确定用例的粒度是一个难点，而且感觉到用例没有什么规则遵从，甚至有无所适从的感觉。正如Cockburn先生提出的学习用例分析技术的"守、破、离"的三个阶段：
1）守：练习基本功夫，遵循规则，照章行事；
2）破：能突破传统，因地制宜地灵活应用； 3）离：超脱任何招式与规则，达到无招胜有招的境界。
但用例分析技术却让第一阶段的初学者感到无法很快地掌握。而其所著"编写有效用例"则想为用例分析技术补充规则，让大家能够更好地掌握。
Cockburn先生在Ivar Jacobson的基础上，做了一些补充：
1）用例是契约，是系统与涉众之间达成的契约。也就是将用例朝着形式化的方向发展；
2） 将用例分成三级：
◆ 概要级：包括多个用户目标（显示用户目标运行的语境，显示相关目标的生命周期、为低层用例提供一个目录表）；
◆ 用户目标级
◆ 子功能级
不过，对于Cockburn先生的贡献，用例始祖Ivar大师并未做出任何反应。本人在实践中认为，Cockburn先生的思路与理念对于初学用例分析技术的人来说，十分有价值，使得用例分析技术更具操作性，当其同时也有点画地为牢的感觉，也许Cockburn先生也意识到这点，因此第三阶段就是"离"，没有规则，按需灵活使用。
五、如何在开发过程中应用用例分析技术
用例分析技术在需求过程中的地位如下图所示：
对于用例分析技术理解上的两个最大的误区是：
1）用例分析技术包括了整个需求过程：它只是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，并无法替代这些技术；
2）用例分析技术是分解技术：其实用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成为用例：
5.1 用例分析前的工作
在用例分析之前，应该完成以下工作：
1）确定涉众（Stakeholder）和用户类型（命名、简要描述、涉众代表、特征、能力）；
2）确定涉众代表（命名、简要描述、责任、参与）；
3）在项目中加入涉众代表（访谈、问卷、顾问、评审、角色扮演）；
4）创建共同的构想（问题定义、系统范围、用户目标、非功能需求à前景文档）；
5）采用传统的需求捕获技术捕获需求；
6）组建用例分析队伍（少量、有问题域知识）。
5.2 用例分析过程中的注意事项
用例分析的过程如下图所示：
在使用中要注意：
1）用例源于涉众，请不要自己杜撰出用例；
2）用例的事件流的编写过程中，应充分加入团队的参与；
3）虽然用例源于涉众，但不要企图向他们直接问"你还有什么用例?这样的问题