软件和需求的实践

软件和需求的实践

林星 (iamlinx@21cn.com)
2001 年 10 月
来自《IBM DeveloperWorks》

在这个关于软件工程的新专栏里，作者将结合理论知识，实践案例，优秀的工具介绍，经典文章导读，告诉您软件工程中最重要的一个过程――需求过程各方各面的知识。通过阅读，您将了解到，需求的知识体系，需求的过程能力，相关的软件工程知识，在实践中如何做好需求分析。文章虽然有很多的例子，但是，文章主要还是偏向于宣传一种思想，一种面向对象的思想，一种实践的思想。

第一篇

1.1. 从猴子说起

有这样一个笑话：一个旅客走进硅谷的一家宠物店，浏览展示的宠物。这时，走进一个顾客，对店主说："我要买一只C猴。"店主点了点头，走到商店一头的兽笼边，抓出一只猴，递给顾客说："总共5000美元。"顾客付完款，然后带走了他的猴子。

这位旅客非常惊讶，走到店主跟前说："那只猴子也太贵了！"

店主说："那只猴子能用C编程，非常快，代码紧凑高效，所以值那么多钱。"

这时，旅客看到了笼子中的另一只猴子，它标价10000美元。于是又问："那只更贵了！它能做什么？"

店主回答："哦，那是一只C++猴；它会面向对象的编程，会用Visual C++，还懂得一点Java，是非常有用的。"

旅客又逛了一会儿，发现了第三只猴子，它独占一个笼子，脖子上的标价是50000美元。旅客倒抽一口气，问道："那只猴子比其他所有猴子加起来都贵！它究竟能做什么？"

店主说："我们也不知道它究竟能做什么，不过它是做项目顾问出身的。"

虽然这只是一个笑话，但是有一点是可以肯定的，项目管理是非常重要的，而项目管理的人才又是极为缺乏的。在软件工业发达的国家，大家多少都知道点软件工程规划的重要性。在我们身边的台湾、印度、日本，都不乏因实施软件工程而成功的软件团体，更不用说身为软件大国的美国，已经从较低级的软件实现摆脱出来，进入了设计和营销的境界。

软件首先是一种产品（软件是服务还是产品的问题，向来未有定论），看看世界上制造业的发展历程，就会发现一些很有意思的现象。在本世纪早些的年代，西方国家的制造业经历了规模生产、提高质量等等促进生产力提高的过程。可是由于西方国家的人力资源成本不断的攀升，越来越难降低产品成本，所以西方国家又不可避免的经历了一次将制造业外移的过程（制造业外移的结果是成本大幅下降、国际贸易频繁、接受制造业的国家发展了自身的制造业），而西方国家只留下营销和设计的能力，掌握了产品生产的重点。

同样，IT行业也在经历这种过程：美国将软件外包给印度，硬件外包给台湾。而中国的硬件也在崛起，但是在软件行业，中国和其他国家的差距还是太大了，且不说在软件行业中处于核心地位的操作系统、数据库。即便是应用软件，中国的软件水平也实在低的可怜。在国外制造业刚刚迁移进中国的时候（改革开放），中国的小企业家同样没有任何管理经验、质量意识。但是随着制造业的发展和国外先进思想的进入，中国也诞生了极为出色的全球制造业巨头。而中国的软件行业现在正是处于刚刚有了一点管理思想，但还没有成熟的地步。我们有理由相信，在不久的将来中国也会诞生出出色的全球性软件企业。

憧憬归憧憬，现实的问题还是必须要考虑的。软件这个产品很奇特，软件企业的管理思想同样很奇特。不同于现在企业推崇的各种管理思想，软件企业的管理思想主要是针对项目的管理，确保项目的成功。

1.2. 项目和需求

笑话里的猴子对应到项目就是指项目管理人员，这里要引入一个角色的概念（同样的人可以担任多种的角色），通常的项目管理角色包括：项目经理、项目复审员、变更控制经理、企业流程分析师、业务模型设计师、需求分析员、需求复审员、系统分析员…在一个成功的项目里，多种角色职责明确，分工合作，共同完成项目的设计实施。

那么这些"猴子"在项目中都做了些什么呢？RUP（Rational Unified Process 瑞理统一过程，本文采用了众多的RUP的思想）把一个项目分成10个核心工作流程（Core Workflows）和4个阶段（Phases），并以核心工作流程为Y轴，阶段为X轴建立起一个项目视图（图一）。

图 一

　

本文将主要对先启阶段做介绍。在先启阶段，需求是重中之中，这里指的需求不仅仅是RUP的一个工作流程（在业务建模下），而是比较广义的概念，包括了RUP的工作流程中的业务建模、需求、一部分的分析、测试计划、配置和变更管理。

1.3. 需求是根本

由于忽略需求过程造成的项目返工是恶性的，大量的项目在需求阶段就注定了它的失败。以下是需求过程不科学的典型例子：

1.        开发人员在用户处呆了两三天就埋头开发；

2.        用户告诉开发人员我要开发一个XX系统，但是我很忙，你先开发一个让我看看；

　

上面的这两种态度都意味着项目的不成功，应该说上面的开发人员和用户都应该对此负责。需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。当然，由于用户不是专业人士，开发者有权利告诉用户应该采用何种态度来对待项目的需求。曾经和几个朋友聊过他们公司开发过的项目，最后得出一个结论，所有最成功的项目都有一个重要的特性：用户非常的支持。

评判一个软件项目成功的标准是看它是否解决了用户的问题，而用户的问题就是体现为用户的需求，需求也就顺理成章的成为项目的成功标准。而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工，而需求的不慎不是说你小心就可以的，因为很多需求是隐性的，连用户都不清楚自己的需求。这时候就需要一种科学的方法来帮助软件组织实施需求过程。

1.4. 需求是变化的

大师说："没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。"

目前众多的软件项目有什么样的问题呢？早些时候上ERP的企业在企业发展的时候发现原有的ERP系统需要改进，可是要改进或者是更改现有的ERP系统，唯一的方法就是重新开发一个ERP系统。这对于企业来说是笔不小的支出。此时，落后的信息系统就成为制约企业发展的重要因素。是什么原因造成了这种情况呢？主要的因素是传统的系统分析是在假定需求不变的情况下进行的，这样可以把企业的资源配置到最优的程度。可是在现代瞬息万变的社会，一个企业固守旧有模式，势必会在竞争中处于劣势（因此现在也出现了"组件化"的ERP，这是题外话）。既然企业的需求是变化的、不稳定的，那么以变化的需求为基础建立起来的企业信息系统当然也就不稳定了。这时候，有个问题就产生了，前面我们已经说过，需求是项目的根本，既然需求都是不稳定的，那么何以建立起稳定的企业信息系统呢？

要回答这个问题，首先要比较面向过程和面向对象的开发方法的差别，传统的面向过程的开发方法在前20年大行其道，为中国企业的信息化建设立下了汗马功劳。之所以称为面向过程，是因为开发的焦点集中于过程，开发者集中于以函数为核心的过程，例如前些年很多人试图编写一些通用转账函数来满足银行的需求。面向过程的开发语言包括：Cobol、Pascal、C及C的变形语言。面向对象的概念是在近10年才进入中国的，而它的思想至今也没有真正意义上得到普及。简单的说，面向对象就是面向世界，世界上的任何事物都是对象，因此面向对象是很自然的思想，是符合我们的思维习惯的。面向对象的语言包括了Smalltalk、C++、Java，还有Object Pascal，以及刚刚诞生的C#。

需求是不稳定的，那么需求之中是不是没有稳定的东西呢？有的，就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物，植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。这种开发的方法就被称为OOAD（Object Orient Analysis & Design 面向对象的分析和设计），而分析出的企业对象就被称为Common Business Object。

1.5. 需求是什么

在RUP中定义了需求工作流程的工作目的：

1.        客户和其他涉众*在系统的工作内容方面达成并保持一致。

2.        使系统开发人员能够更清楚地了解系统需求。

3.        定义系统边界（限定）。

4.        为计划迭代的技术内容提供基础。

5.        为估算开发系统所需成本和时间提供基础。

6.        定义系统的用户界面，重点是用户的需要和目标。

* 涉众：涉众是所有会受到项目结果重大影响的人。如客户（或客户代表） 用户（或用户代表） 、投资者 、股东 、生产经理 、买方 、设计员 、测试员 、文档编写员等

从上面的目的我们可以大致想到需求过程中要做些什么事。事实上，用简单的话来说明需求过程，就是确定系统该做些什么以及该符合什么条件。话虽然简单，实现起来可没有那么容易。所以科学的需求过程有一整套完整的理论、工具、方法来实现。就像任何企业要盈利都必须要有业务和伴随业务的管理一样，需求过程也分为需求分析过程和需求管理过程。企业的业务是盈利性的，需求分析过程在项目中也是产出型的；企业要保证业务的开展就必须要有管理，而需求分析过程也同样离不开需求管理。小企业没有成为体系的管理方法，企业规模小的时候还能够对付，可是企业一大，各种问题都接踵而来，管理上的不足直接导致了业务开展的低效性。同样，需求管理的不足可能可以应付小型的软件项目，可是对于大型的项目，管理的不足就会暴露出来，而直接的后果就是项目的失败。

插句题外话，很多人认为需求管理的目的是为了控制需求过程，这是没有错，但是在RUP的思想中，更重要的思想是迭代*。迭代的目的是为了发展，为了进化，为了完善。所以RUP中的软件生命周期是分为多个迭代周期的（软件生命周期将会在下文讨论）。

* 迭代：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。

需求分析过程主要做的事情无非就是获取涉众对系统的要求，可是需求是多变的，而你不可能告诉客户等到他们把一切都固定下来再开发软件。所以需求管理过程做的事情就是保证需求变更的可管理性。

1.6. 需求的层次

《软件需求》一书中有对需求层次的详细定义：

软件需求包括三个不同的层次--业务需求、用户需求和功能需求--也包括非功能需求。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示：

图 二

对应到RUP的工作流程，业务需求其实是RUP的业务建模流程（Business Modeling），在这个流程中，参与者主要是业务流程分析员（Business-Process Analyst）。主要的目的是对企业目前的业务流程进行评估，并根据要进行的项目，确定进行何种程度的业务建模（你要做一个ERP项目就意味着你必须优化业务流程，而上一个部门级MIS项目就没有必要用牛刀了）。然后你会得到一个叫做业务前景（Business Vision）的东西，其实就是项目成功后会是个什么样子，并在涉众范围内达成一致。业务需求层次需要投入的精力视具体项目而定，而业务需求的确定对之后的用户需求和功能需求起了限定作用，业务需求就是需求过程的宪法，任何需求不得与之相违背。

到了用户需求层次上（RUP的需求工作流程），重心就转移到如何收集用户的需求上，即确定角色和角色的用例（这里的角色和用例是UML中的概念，我们在下文会讨论），需求分析是很难的，因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变的。一般来说，在过去作需求分析的时候，更多依靠的是阅读企业的文件，但是企业的文件往往有局限性，例如落后于当前的业务，不够明确，依赖于管理水平的高低，所以后来获取需求的方法逐渐倾向组织访谈会（Interview）。

功能需求依赖于用户需求，可以说是用户需求在系统上的一个映射（Mapping）。开发者思考的角度从用户转移到开发者。在这个层次上，为用户做一个软件原型是一个很不错的主意。直到现在，用户对软件还是没有一个实实在在的概念，如果你给用户一个原型，用户就会说，"哦，我的XX系统原来就是这样的。"这就避免了用户在软件开发完成后才看到软件所带来的一些风险。是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目，很多时候，用一些非正规的方法来生成原型：如果你要开发一个WEB系统，让你的美工做几个页面给用户看看，如果你做一个C/S系统，做一个界面给用户，都已经足够用了，甚至你完全可以在黑板上画一画你将来的软件的面貌都可以。用户大都是比较友善的，不要把问题想的过于复杂。

1.7. 需求的标准

讨论软件需求的文章有很多，对于需求的标准也不尽相同，但是在思想上是相同，都是为了保证项目的顺利进行。这里我总结一些比较通用的标准，可能并不完善，但你只要能保证做到这几点，你的项目就不容易失败：明确(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪、可修改等等。

明确：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。

除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。

完整：再也没有什么比软件开发接近完成时才发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。

一致：一致性也是一个比较大的概念，很难用几句话讲清楚。简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。

可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？"我们要用新的系统完成报表自动化处理"，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

第二篇

本文将继续花了一些篇幅来讨论软件工程中的一些基本概念，以求大家能够从整体的角度来理解需求过程。

1、煮鸡蛋的启示

有个英国人学煮鸡蛋，开始，他把鸡蛋放到开水里煮时总会炸裂。他为此想了各种方法，并找到了一个解决方案：在鸡蛋上打个孔。但在鸡蛋上打孔带来了另一个问题:孔打小了，鸡蛋还会裂；孔打大了，蛋清会在它凝固以前流出来。于是，这个英国人给一批鸡蛋分别打了各种不同孔径的洞，并记录下每个鸡蛋孔径的大小。通过这一方法，他找到了一个最合适的大小──既避免了炸裂，又保证蛋清不会流出来。这时，虽然煮鸡蛋炸裂的问题解决了，但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。为了解决这个问题，他又开始尝试煮不同时间的结果，并从中找出最佳的时间长度。最后，他终于找到了一个放之四海而皆准的煮鸡蛋的方法。这个案例对很多中国人来说是个可笑的例子。因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。

从煮鸡蛋这样一个小小的事件上，中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果，而英国人却仔细地把每一个过程细化到最简单，然后按部就班地执行。（管理软件的发展之路 洪奇）

聪明的中国人虽然拥有四大发明，但是对于现代的管理思想，中国人一直没有领会到真谛所在。无论是哪一种的管理方法，过程能力都是特别重要的，虽然生产一件产品的相关人员有千千万万，但是生产出来的产品却只有一种。这种能力并不是从天上掉下来的，是通过制定极为详尽的生产过程规定得到的。在中国接受了ISO的思想之后，这种能力也在国内的制造业中逐渐体现出来。但是在软件行业中，拥有这种过程能力的软件组织仍然是少的可怜，大多数的软件组织奉行的还是一种在八九十年代的个人英雄主义，开发软件单靠个人的力量，能力强的程序员能够成功的完成软件，能力差的则失败。大多数的软件组织中，少数人掌握着代码，他们就是一切，如果他们因为私人原因离开所在的组织，手上的代码则是他们的资本，原有的组织将受到沉重的打击。

中国人热衷于结果，2001年的热点在CMM上，现在还很难说CMM中是不是有一定的泡沫存在，但是可以肯定的一点是，CMM之进入中国软件组织为中国软件工业的发展开创了一个新的时代。中国的软件工业将逐渐摆脱原来的作坊式开发，进入软件工业时代。之所以用软件工业而不用软件产业的原因是希望软件产品能够像工业革命那样进入大规模生产，降低价格的时代。

可惜，软件毕竟不同于工业产品，在工业化生产的过程中，质量检测的一个方法是在产品出厂前设置质量检测，通过质量检测的出厂，否则回收。这种方法无法适用于软件。后来，质量检测逐渐倾向于生产过程，在过程中监测产品质量。这种方法比起前一种方法进步了很多，但是它需要对生产全过程进行追踪。这种方法的思想正是软件过程的质量保证的精髓所在。

在《软件工程》一书中，作者把软件工程分成三层，最底层是软件过程，上一层是软件方法，最高层是CASE工具。软件过程中充满了各种各样的方法论，从需求到最后的维护。要在自己软件组织中应用所有的方法是不可能的。所以你如果看完软件工程的文章后有一种要在明天就实现现代化的冲动的话，打消那种念头，从零做起。

2、需求过程

需求过程是软件过程的一个很重要的部分。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的"祸根"（Leffingwell 1997）。我在自己的身边也做过一次小范围的调查，结果显示成功的项目都离不开成功的需求（一个重要的标志是用户的支持）。

需求过程，也有叫做需求工程和需求阶段的，包括了需求开发和需求管理，他们所涉及到的具体工作流如图所示：

　

需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。需求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。

3、需求过程和CMM

软件工程协会 (SEI Software Engineering Institude) 的能力成熟度模型 (CMM Capability Maturity Model) 提供了一种著名的软件过程成熟度基准。CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件过程的成熟程度。（更详细的定义和说明请参看《CMM白皮书》）。

CMM中和需求有关系的是第2级（可重复级）中对需求管理的要求和第3级（已定义级）中对需求跟踪能力的要求。必须指出的是，CMM只是规定成熟的软件组织应该达到的关键能力，是一种改进软件过程的策略，对具体的方法并没有做限制规定。所以CMM中没有涉及到需求开发的内容。

4、需求过程和软件生命周期模型

任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

迭代式模型

迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如上图所示。

迭代和瀑布的最大的差别就在于风险的暴露时间上。"任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。"（RUP）二者的区别如下图所示：

　

由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"（RUP）

快速原型（Rapid Prototype）模型是我喜欢采用的另一种模型。快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。

上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。这个方面的讨论我们会在第5小节中继续

5、RUP和XP

RUP是瑞理（Rational）公司经过不断的实践和理论总结发展出来的一套软件开发统一过程（Unified Process）的思想集和方法集。还记得我们在第一章的那张图吗，那就是RUP的核心图。RUP把软件开发过程分成4个阶段（Phases）和9个核心工作流程（Core Workflows），通过一次次的迭代（Iterations），完成整个的软件生命周期。RUP可以把软件开发过程分到非常细小的单位，每个角色（Workers）都参与活动（Activities），产生出工件（Artifacts）。由于精密的控制，所以RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动，但是由于CASE工具的使用，它并不会像传统瀑布模型那样陷入文档的海洋中。RUP通过适当的剪裁，同样可以试用于较小型的项目。

XP（Extreme Programming），极端编程。不过好像并没有这样翻译的（听上去像是计算机领域的极右组织）。它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。

制定了大量的规则的RUP方法被称为重量级（Heavyweight）的方法，而像XP这样只制定少量的规则来规范行为的方法被称为轻量级（Lightweight）的方法（实际上，现在有一种倾向称这种方法为Agile方法的）。近来，也看到一些文章在讨论两种方法孰优孰劣。例如：XP兴起，RUP不适合中国国情等。我想，这和以前大家讨论C++和Java谁好的性质是一样的。方法都有两面性，只有最适合的方法，没有最好的方法。我在实践中也感觉到，国外的理论确实不能照搬于中国，毕竟中国人的人文环境和国外相差太大了。不过，RUP不适合的，我想，XP也未必会适合。如果说，有人把RUP的一整套东西生搬硬套，导致了最后项目失败的结果的话。这种行为无异于刻舟求剑。

在我看来，RUP就像是一个软件工程思想和方法的大百科全书。在其中，你可以看到诸子百家的论调，可以了解软件工程的整个演化过程。RUP是很值得你投入大量时间去研究的东西的。一个武林高手走进了少林寺的藏经阁，你可以想想，那是一种什么景象。XP，更强调团队的充分交流，最大限度的发挥人的创造力。它并不制定大量的规则来限制人的行动（必要的规范是必须遵守的），开发的团队中的每一个人都能自由的发挥想象力，毕竟，软件是创造性的劳动（这听起来像是共产主义实现了一般）。至少，国内的公司都应该学习XP的一条规则：一周只工作40小时。相比较之下，RUP比较适合大企业、大项目，因为大的团队往往需要法制；XP适合于小团队，比较能够发挥小团队的创造力。但是在实际中，也有例外的情况。例如XP方法的第一个项目就是克莱斯勒公司的一个名为C3的大型项目。

在现实中，RUP和XP应用于目前中国的软件企业都有一定的难度。有一些来信来问我，RUP真的适合中国的企业吗？我会直接告诉他们肯定不适合。对RUP这个庞然大物来说，很难去评定它的优和劣。关键在于它裁减以后的样子。我看到过一篇文章，是讨论如何将RUP裁减适合XP思想的方法的。所以RUP的使用要很小心。一个高明的铁匠用铁锤可能可以打出一把好兵器，如果是普通人搞不好就会砸到脚。

提升企业的内力值并不是一两天的事情，这需要长期的投入和锲而不舍的努力。大刀阔斧的引进一整套流程并不是不行，只是猛药伤身这个道理大家也应该懂得。很多年轻有为的软件界人士希望在自己公司中引入先进的开发理念，但是在真正实施时，往往会被碰得头破血流，也有这方面的原因存在。对他们，我是很佩服的。

6、结语

虽然该章的名称为需求过程，其中却花了一些篇幅来讨论软件工程中的概念。主要的目的是为了大家能够从整体的角度来理解需求过程，而不要把需求过程孤立的对待，否则，必然是见木不见林。

 

软件和需求的实践（2）

林星 (iamlinx@21cn.com)
2001 年 10 月
来自《IBM DeveloperWorks》

软件开发人员总是在困惑为什么软件分明是按照需求做出来的，可是客户为什么仍然不满意。客户总是在困惑为什么软件和自己想要的差距会那么大。这究竟是怎么回事？如何才能把开发人员和客户之间的沟壑填平？本文作为这个关于需求的软件工程专栏的第三篇，将向您介绍这个把客户和开发人员联系在一起的工具――UML（统一建模语言，Unified Modeling Language）。

一个软件系统的开发过程说到底就是由客户提出需求，再由开发人员将之翻译成机器能够理解的语言，构建成系统，交付给客户使用。在客户看到软件的时候，客户通常会说一句话："哦，那正是我所说的，但那不是我想要的。"

即使是开发人员异常的尽责，花费大量的时间了解客户需求，依然避免不了出现上述的客户抱怨。更何况开发人员通常都想当然的认为自己已经了解了需求，并喜欢按照自己的想法给软件加入一些新特性（feature）。在这样的情况下，用户的"真正"的需求就更加得不到保障了。

出现了什么问题？因为大部分的软件开发工作都是Program Oriented，而不是Customer Oriented。开发人员认为自己已经了解了客户的需求；客户表达不出或是表达不全自己的需求；开发人员抱怨客户经常修改需求；客户不明白软件开发为什么有如此多的限制…。所有这些，都是Program Oriented的软件开发模式避免不了的弊病。

归根结底，这些问题都是由于客户和开发人员的立场不同而导致的。

所以呢，在客户和开发人员之间，缺少一种东西来把他们联系在一起。因此，众多的方法学，都把这个问题视为重中之重。

1. UML
UML（统一建模语言，Unified Modeling Language）是一种面向对象的建模语言。在软件工业化方面做出了杰出的贡献。被OMG（Object Management Group）采纳为业界标准。

UML就是解决上面这个问题的一个相当有代表性的例子。UML的实质，就是一种沟通方法，就象是英语能够解决把世界各地的人交流的问题一样。

2. UML起源
公认的面向对象建模语言出现于70年代中期。1989年到1994年是建模语言的战国时期，其数量从不到十种增加到了五十多种。虽然有利于学术的发展，但是对于最终用户来说，了解众多的建模语言是一件非常没有必要的事。在建模语言的战国时期出现了三个强者：Grady Booch，James Rumbaugh和Ivar Jacobson（人称"The Three Amigos"），以及他们的方法：Booch 1993、OOSE和OMT-2。

Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念。Booch 1993比较适合于系统的设计和构造；Rumbaugh提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型。 OMT-2特别适用于分析和描述以数据为中心的信息系统；Jacobson于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。

天下大势，分久必合。Grady Booch，James Rumbaugh和Ivar Jacobson三个人的方法各有所长，而用户有希望能够有一种标准出现，结束混乱的百家争鸣的现状。1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch9 3和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 0.8（Un ified Method）。1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML 0.91，并将UM重新命名为UML（Unified Modeling Language）。1996年，一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应，并倡议成立了UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。这一机构对UML 1.0（1997年1月）及UML 1.1（1997年11月17日）的定义和发布起了重要的促进作用。

UML是集合了众家之长的建模语言，从诞生的那一天开始，就经过了不断的验证和修改，它着重强调的是一种标准的建模思想，但它并不是一种标准建模过程，对于不同的软件企业来说，建模的过程是不同的。UML并没有特定的平台，与具体的实现无关。它是一种图形化的面向对象建模语言。UML通过不同的图形表示来捕捉系统静态结构和动态行为的信息，建立起对象模型。不同的图形是从不同的角度来看待系统。由于UML的独立性，所以它可以通过专用的工具转化成具体的编程语言，或是从编程语言代码转回UML，这叫做"逆向工程"。

3. UML是什么
UML的概念包括了UML语义（Semantics）和UML表示符（Notation）两个部分，UML语义定义了结构（Structural）模型和行为（Behavioral）模型。结构模型（又称为静态模型）强调系统的对象结构，如对象的类（Classes）、接口（Interfaces）、属性（Attributes）和关系（Relations）；行为模型（动态模型）关注的是系统对象的行为动作，如对象的方法（Methods）、交互（Interactions）、协作（Collaborations）和状态（State Histories）。以此为基础，UML为UML表示符提供了完整的语义定义。UML的表示符包括了下面的几种主要的图：类图（Class Diagram），用例图（Use Case Diagram），顺序图（Sequence Diagram），协作图（Collaboration Diagram），状态图（State Diagram），活动图（Activity Diagram），部署图（Deployment Diagram）语义由于我们的讨论重点并不是UML语言，我们只是简单的介绍UML的实际应用，如果大家对UML有兴趣，可以参看《UML1.3白皮书》。

4. 用例图和用例
用例图（Use Case Diagram）是UML中最简单也是最复杂的一种图。说它简单，是因为采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。一个系统的用例图太泛不行，太精不行，太多不行，太少也不行。用例的控制可以算是一门艺术。突然想起当年我刚刚接触UML的时候，对用例不屑一顾，认为是UML中最无用的一种图，现在每每想到不禁感慨自己的愚蠢。

Use case diagrams show actors and use cases together with their relationships.『OMG-UML V1.3』

用例图表示了角色和用例以及它们之间的关系。

A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. 『OMG-UML V1.3』

用例描述了系统，子系统和类的一致的功能集合，表现为系统和一个或多个外部交互者（角色）的消息交互动作序列。

有点复杂是吗，就是角色（用户或外部系统）和系统（要设计的系统）的一个交互，为了实现一个目的（Goal），这个目的的描述通常是一个谓词短语，例如，开立信用证，给客户回单等。用例图则图形化的表示了这种关系。

一个具体的用例图可能是这样的：

　

5. 用例和需求，用例和过程
可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。

从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在可爱的Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。

在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和Use Case。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。

用例是重要的，用例图只是用例的表达方式，其实用例的表达不仅仅是用例图，还有很多方式，我们在下面会具体讲到。

6. 使用用例的误区
上面曾经花了一些篇幅来说明用例的简单和复杂的关系。在很多介绍UML的书中都会首先介绍用例图，并会用一些近乎完美的例子来说明用例图。可是在实际的使用过程中，都会有很多实际的问题。我咨询过很多使用UML的朋友，发现或多或少都存在问题。

用例的发明者Ivar Jacobson 曾经说过，Ericsson花掉了上千万元去研究建立Use Case模式的过程(process) ﹐现在他任职的Rational公司也花掉不少钱研究开发过程的问题。大师花了数十年心血建立起来的理论体系并不是那么容易的。用例决不仅仅是定义Actor、Use Case、Association那么简单。用例需要在很多的细节方面都做足功夫。我曾经看过一个软件企业推行Use Case图，但是在花费心血画出了几十张项目的用例图后，设计编码阶段却回到了从前的开发流程。

用例的使用绝不仅仅是画用例图，用例也不是软件团体一步登天的捷径。用例贵在思想，在软件团体中引入用例并能够和团体很好的融合，是一个渐进的过程。因为在软件工程领域应用用例思想涉及到的内容方方面面。即使是用例图的编号也是大有讲究。对于一个没有OO实践经验的软件团体，从事这样的作业，需要大量的工作，可以说是"百业待举"。如果没有长期的积累和探索，何来用例和软件团体的融合呢？

7. 用例的观点
为什么说用例是有效的呢？在软件开发的过程中，大部分问题的产生都是由于沟通的不畅。设计者和用户沟通不畅，设计者和实现者的沟通不畅。软件开发就是踢足球。教练、前锋、中场、后卫各顾各的，相互之间形成断层，怎么能赢球呢？上面提到的一些应用OO用例思想失败的例子也表明，如果开发团队有人排斥用例思想的话，项目是不会成功的。

用过Rose的人都知道，在Rose的界面中，有四种视图（View）：用例视图（Use Case View），逻辑视图（Logical View），组件视图（Component View），部署视图（Deployment View）。这个思路源于Kruchten大师提出来的4＋1的观点模式。其描述了系统开发工作的参与者﹕使用者(end users) 、程序员(programmers) 、系统整合师(system integrators)、以及系统工程师(system engineers)等5 种人员心中所关切的焦点与看法。

　

为了能够把4种人不同的观点统一起来，Kruchten大师提出了一个情节（Scenarios）观点（这个词翻译的不好，如果有谁有更好的翻译，请更正）。这个观点其实就是用例观点（Use Case View）。在用例观点的统一下，保证这四种观点能够相互协作，共同营造一种良好的开发氛围，实现软件项目的成功。

那么，应该如何营造一种和谐的气氛呢？还记得在介绍UML语言的时候我们谈过UML中的几种图吗。这几种图都不是孤立的。在画出一份用例图后，通常都会用顺序图和状态图来规定用例图的规格，这些都是Rose中的用例视图。在用例图中，我们可以分析出基本的类，并将类组织成包，并将其分配到系统的三层结构中，这是Rose中的逻辑视图。在写出基本类之后，我们还可以将类组织成组件（针对特定的架构，如J2EE或COM），这是Rose中的组件视图。把组件部署实现，就是Rose中的部署视图所关心的。（需要指出的是，Rose中的视图与Kruchten大师的4+1观点有些许出入，Rose中的组件视图相当于Kruchten大师的Development观点和Process观点。）

（注：这里的View对应的有两种说法：视图和观点。视图是比较正式的说法，但是我觉得在通常得用语中，大多采用观点的说法。所以这里的观点和视图表述的是同一个意思。）

这里谈到用例的观点主要是要让大家了解为什么会有用例的产生，以及在软件开发中不同的人看待问题有不同的角度。

8. 用例的不足
用例的出现虽然能够解决很大一部分问题，但是它并不是万能的。

The first is the matter of how difficult it is to get a UML-like design into a state that it can be handed over to programmers. The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing。（Fowler 2001）

首先是把像UML那样的设计图交给程序员来实现是一件极为困难的事情。问题的关键在于那种设计看上去不错，可你打算编程来实现它的时候就出现了问题。

不但是分析员和程序员之间的沟通存在问题，客户和分析员之间的隔阂更大。客户对于用例的观点仍然不能够接受，这仍然需要开发人员作出不懈的努力来调和这一矛盾。

由于软件工程最早提出是根据建筑方面的理论，所以很自然的就会把软件工程和土木工程做一个比较。在土木工程中，设计图和模型制定出来来需要严格的执行。可是：

The models that civil engineers use are based on many years of practice that are enshrined in engineering codes. Furthermore the key issues, such as the way forces play in the design, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams is peer review. （Fowler 2001）

土木工程师使用的模型建立在多年实践的基础上，它们用土木工程的专用语言来描述。而且主要的问题在于，通常这种设计需要符合数学原理。而我们对UML之类的图表唯一能做的就是同级检查。

看到问题所在了吧。单纯的凭借没有完善理论支撑的设计图就轻率的决定这个软件的设计是及其危险的。不止一次的经验告诉我，一开始写出的用例在项目结束时一看往往会吓一大跳：设计和实现已经完全脱节了。其中主要的代沟有两个：客户和开发人员之间，分析员和程序员之间。我们这里的重点在于客户和开发人员之间的需求部分。

需求的问题单单由UML语言来解决是不现实的，且不说国外的软件环境那么好的情况下，客户对于UML仍然不理解。国内的情况要糟糕的多，大多数的客户并没有计算机方面的基础知识，对于他们来说，只有一点："花钱买东西，天经地义。"在这样的观点下，软件的开发过程就很难得到客户的支持。所以这也是国内ERP项目鲜有成功范例的一个重要原因。

这时候，讨论的问题已经不是局限在技术层面了，主要的焦点已经转移到了管理、营销、谈判技巧等方面了。UML的成功也是需要这个大前提在的。McConnell建议在一个大的项目中，编码和单元测试的开销占整个项目开销的15%。而其中有很大一部分的时间都会花在BPA（企业流程分析）和BPR（企业流程再造）上面。因为有很多企业在实施电子化之前管理都不规范，以人治为主。对于软件而言，不论其中的设计多么的成功，如果没有各个环节输入的准确来保证，那结果是可想而知的。我的一个朋友开发过一套连锁店管理的软件，可是系统运行以来，会计帐从未平过。其中主要的问题就是各个结点的输入不规范。这种问题已经不是计算机能够解决的了。说到这里，有一个笑话，有一个特定行业的企业要开发一个管理软件，于是我就给企业的负责人分析他的流程，突然他很惊讶的看着我："你是我们这个行业的吗，怎么比我还熟。"其实，我只是以逻辑的观点来分析他们流程，把一些漏洞给堵住。关于业务建模方面的知识，在接下去的文章中还会有大规模的篇幅，这里就不罗嗦了。

所以呢，作需求分析，往往技术并不是最重要的。

9. 迭代式的需求分析
软件工程不断的向前发展，其中的一些新兴的方法论中的佼佼者就是XP。（关于XP的介绍请参看我的上一篇文章）。XP对需求的影响在于：开发方和客户方已经不再是客户关系，而是战略合作关系。客户将作为领域专家参加整个开发过程，并提供现场（on-site）指导。

XP大概的流程是：领域专家组（包括开发方和客户方）将会提出需要开发的功能，体现为素材卡片（Story Card）。项目经理配合将素材卡片分配到每个迭代周期。各个素材卡片都会有一个小型的开发团队（由分析人员、开发人员、品保人员组成）来负责。每次迭代周期都会得到一个可发布、可供客户使用的产品。通过把整个项目划分为多个迭代周期，可以：

·         较短的迭代周期容易预测，资源分配计划可以做的非常细致；

·         给客户提供了一种实际使用的感觉，并且客户可以通过实际使用发现自己潜在的需求，提交需求，在随后的迭代周期中安排实现；

·         不断的有最终产品推出，团队能够保持较高的士气；

·         不同的小组可以同时处于不同的迭代周期中，降低了传统开发方法中常常出现瓶颈的风险；

　

不可否认，XP作为新生代的方法，有它的优势所在。可是要指出的是，在中国，能够采用XP方法企业可以说是屈指可数。这个问题大家经常都可以看到评论，这里就不罗嗦了。不过，有一种开发环境，还是有天然的使用XP方法的优势的。就是内部开发。例如很多的大型企业、银行、事业单位都有自己的软件开发部门。这种和客户关系特别亲密，使用XP方法就有他的优势。只是，目前影响这种开发方式的主要原因，却是在体制上的。

10. 小节
平心而论，UML还是不错的，绝对值得我们花时间来学习。尤其是随着大环境的逐步改善，UML将很有可能成为统一建模语言，就像它的名称那样。需求要是Customer Oriented的，这点知易行难。要采用先进的方法，更非朝夕之功。