为什么用例如此重要

开篇：润墨网以专业的文秘视角，为您筛选了一篇为什么用例如此重要范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

发表时间：2007-08-20 发表人：张恂

为什么用例如此重要？一言以蔽之，这是因为:用例是一种普遍存在的客观现实。我觉得，与其说亚各申博士发明了用例，还不如说他早在20年前就发现了用例这种客观现实，并最终发明了用例表示和用例驱动软件过程的方法。

而实践证明，用例及其相关技术是迄今为止最为深刻、准确和有效的描述系统功能需求的实用方法。用例为什么如此重要，笔者觉得至少有以下几方面的原因:

用例技术是表达功能需求的最佳形式

按照标准定义，软件的功能需求是指系统输入到输出的映射及其不同组合。显然，任何软件的功能必然要通过软件的外部环境与软件系统之间的交互、协作才能完成，而这不正是用例所要反映的内容吗？

通常一个用例需要描述为了实现用户的使用目标（某个关键功能），有哪些用户输入和系统事件，系统针对这些输入和事件都执行了哪些操作和事务，以及返回给用户的输出是什么。

在大多数情况下，我们可以在内容和形式上，把用例与软件系统的功能需求等同起来，尽管有时候不一定非要用某种具体的格式来严格描述用例。

用例描述中既包含数据流，也包含控制流，既包含用户、系统及所有干系者之间的消息发送和数据交换（交互），也包括干系者活动/动作的执行以及状态的变迁。这就是用例的本质，现象背后那个真实的、抽象的“胚”，而各种格式的文本、UML图形（在实践中我们至少可以用序列图、协作图、活动图和状态图这4种UML动态图分别从不同的视角来描述用例的真实内容），不过是些用例的外部表现形式而已。

每一个软件功能的执行和实现都需要一个具体的、从开始到结束的执行过程。而从形式上看，一个用例的基本组成包括前态、触发事件与后态，既有基本流程的步骤，也有反映异常处理的扩展条件和扩展步骤，还有用例之间的相互调用、扩展和继承，这些特征都与现代计算机程序语言非常相似，可见用例也是一种程序。

当然，用例不是可供计算机直接执行的程序，现阶段它是由自然语言编写的、主要供人工阅读、交流和沟通的程序，以及用来驱动计算机程序开发的程序。用例的这种类程序语言特点，也说明它是表达软件功能需求的一种最佳表达形式。

用例技术具有广泛的适用性

如今绝大部分的应用软件、系统软件，尤其像各类行业应用类软件如电信、银行、保险、税务、制造、电子政务等信息化领域的复杂系统，都是符合用例适用条件的。

从用例的发展历史上看，它最早诞生于复杂的通信行业嵌入式实时系统开发领域，而后从上世纪 90 年代至今，随着先进机构、大师和顾问们的应用与推广，逐步扩展到以上除电信行业之外的，包括企业信息系统、电子商务、Web互联网开发在内的广泛应用领域。

用例提高了需求分析的精度和准度

鉴于需求分析工作是软件开发工艺流程的最上游，因此需求不清、需求错误，必然会导致返工和延时，最终造成软件开发项目的失败。

如果做一个统计，总结一下在我国软件工程、信息化建设中软件项目失败的十大原因，据笔者观察和估计，恐怕需求方面的原因，因需求分析、管理失误而导致的项目失败，即便不是位居榜首，也很可能名列三甲。

我发现，在不少不成熟的软件工程团队管理者和开发者中间，存在着这样一种糊涂的认识:认为需求要讲究灵活性，所以需求分析越粗略、越简单、越随意越好，这样做很“敏捷”，所谓“敏捷”的需求。

需求（定义）要灵活？这当然是错误的，不但误解了敏捷，而且犯了一个逻辑错误，把用户使用功能上的灵活性与功能需求定义的模糊性混为一谈。用户当然希望在有限的预算内，功能越多越好，功能的使用方式越灵活越好，但我们知道，灵活是有成本的。

因此，不管功能有多么灵活，我们有必要对所有这些灵活的功能及其使用方式进行精确而准确的定义，需求可以灵活，但需求的定义和解释不能灵活。

长期以来，我们听到，国内软件开发商、软件企业最烦恼、最经常抱怨的一个问题和现象就是:客户需求变化总是难以预见、控制、应对和管理。需求变化必然会导致项目成本增加、工期延长，而一些开发商往往想当然地认为，这些需求变化都是由于客户的不成熟、不配合、不理解及不合理的期望所造成的，把责任一股脑地都推到客户身上。

需求变化其实只有两种:合理的变化，不合理的变化。对于合理的需求变化，比如市场、竞争、技术等客观条件的变化，我们无法拒绝，甚至应该为了客户价值的最大化，去主动迎接和拥抱这些变化;对于不合理的需求变化，往往是由于自身主观因素形成的，我们应该有效地去预防、减少和制止这些变化。

正是由于需求分析技能和经验不足，才导致开发后期出现不合理的需求变化，需求被理解错误或被忽略，而影响工程的进度。

在实践中，由于类似的“需求变化”，而导致项目的失败，真是屡见不鲜。如果主动、正确、及时、熟练地采用了合理的需求技术，在有限的时间内把需求分析得更彻底、更全面、更准确，而不是被动地等着不合理需求变化的发生，这种不该发生的意外原本是完全可以避免的。

需求的含糊不清甚至错误，极易造成频繁的返工和严重的资源浪费。那么，怎样才能提高需求分析的精度和准度？用用例！

用例是当今能显著提高需求分析质量的关键技术。我的建议是，在项目前期有限的时间和资源条件下，利用用例技术尽最大可能地提高您的团队需求分析结果的精度和准度，及时地做好与客户的沟通，确认需求，并尽早地开发出一个满足这些核心需求的软件架构。软件的需求和架构越早稳定下来，越好。如果追求需求定义灵活，那必将是一场灾难。

用例简化了需求分析与管理

表达软件功能需求，目前比较流行的只有两种方法:特性方法和用例方法。IBM RUP采用整合的特性和用例方法，XP采用 用户故事（本质上也是一种特性），FDD也采用特性，而我在10年前从《微软的秘密》中首次学到了微软的特性方法。国内采用的传统功能需求表达方式也是大致类似于特性的方法，通常是用不精确的一句话或几句话来简单描述软件“应该做什么”。

在实践中，特性的表达很灵活，也很随意，只要想到任何一项软件应该做的事，应该提供的功能点、具备的能力和满足的要求，往需求表格里添加一行记录，就算软件的特性需求了，通常没有特别严格的要求。

但特性的问题是:对于大量复杂的软件系统，比如企业级信息系统、通信系统、电子政务、互联网系统等等，特性的数量过多，往往存在数百、数千个需要管理的特性，这增加了需求管理的难度，容易出现只见树叶、不见森林的状况。

此外，精度不够，容易遗漏关键需求，非结构化，存在各式各样、未统一、标准化的特性技术，也是特性方法的诸多缺点。

用例的一大好处，是可以显著地减少待管理需求的数量。有一种说法，用例数量与特性数量之比大概在1:5-1:10之间。我们可以把大量的软件特性放入到用例这个容器中，利用用例的基本流、扩展流以及其他字段装载大部分的功能特性和非功能特性，把用例作为需求管理、驱动软件开发的主要核心单元，这样就可以显著减少待管理需求的数量，使得软件系统的需求模型实现结构化和模块化，条理更清晰，重点更突出。

用例与特性，它们不是矛盾而是互补的。特性只有两种:功能特性和非功能特性。而所有的用例本身就是一种功能特性，描述的内容比特性更完整和丰富，而且用例采用了基本流加扩展流的类程序描述形式，比特性能够更加准确、精确地表达软件功能需求。

在软件需求分析中，用例和特性，一个都不能少。在项目实践中，以用例描述为主，辅以特性表述，可以简化、优化复杂软件系统的需求分析和管理工作。

有关软件开发的一个最简单比喻是问题-解答模型，即Problem与Solution二元模型。这与学生时代的我们解一道数学题、物理题没有本质上的差别，把题目分析清楚，然后给出解答。

而如今我们的程序员、开发人员其实每天做的就是答题的工作，把某次软件开发中涉及到的所有问题都漂亮地解答完了，该项目也就完成了。因此，到底什么是我们需要解决的问题，我们的软件到底应该做些什么，为用户提供哪些服务，这些是一名职业软件架构师必须去细致了解的首要任务。

在学会了用例之后，笔者才体会到，原来自己10年前不会写软件需求:遗漏了软件需求中最主要的一部分内容。

用例是一种非常聪明的、敏捷的需求分析和管理技术。用例技术的魅力就在于它融简单和复杂于一身，巧妙而准确地反映了软件需求的简单本质（用户目标及其实现行为），因而它具有长久的生命力、出色的包容力和整合力，这已经得到了过去20年来实践的证明。