用例驱动的需求过程实践

      鉴于偶的此文引起大家评论中的内容，在下做出以下声明：

       1）本文是笔者在去年中国系统分析员年会（CSAI 2003，长沙）上的主题报告的讲义整理稿。因此并非十分精细。

       2）对于用例感兴趣的读者，笔者在《程序员》2004年3月刊上有一篇关于用例建模的文章，相信能够满足大家的需求。

一、需求矛盾

　　根据CHAO的权威统计，虽然自"软件危机"提出以来，软件工程方法得到了长足的发展与进步，但在去年的软件项目成功率仍然不足30％，绝大多数的软件项目仍然超进度、超成本。而在这些不成功的项目中，由于需求不清晰、需求不完整等方面的因素，占到了60％左右。

　　下面的这幅漫画虽然不乏夸张，但却是能够激起我们的深思：

　　根据笔者多年来从事软件需求捕获、分析工作的实践经验，认为造成这一现象的根本原因在于客户与开发人员之间的沟通存在障碍，双方都以自己的角度、自己的专业术语进行沟通，这使得大家并不能够很好地就软件需求达成共识。

　　由于帮助客户更好地利用信息化工具提高工作效率，是我们软件开发团队的责任，因此我们没有权利让用户理解我们所用的语言，而是反过来，我们有义务去理解用户的语言，站在用户的角度看问题。

　　而事实上，许多开发团队经常抱怨"我们的客户连需求都说不清楚"、"我们的客户对计算机了解太少了"。多年以来，大家都习惯从自己的角度来定义、分析问题，这也就造成了软件行业成为了一个最缺乏信任的行业，我们需要改一下习惯了。

二、现代需求实践

　　针对这些现象，许多先贤们开始了实践，并且总结出了一系列优秀的需求实践：

1）Use case：用例分析技术

　　鼎鼎大名的RUP是这样总结自己的：用例驱动，以体系结构为中心