软件和需求的实践

第一篇

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轴建立起一个项目视图。

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)，此外还有其他的概念，如可跟踪、可修改等等。

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

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

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

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

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

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

原文转自：http://www.ltesting.net