需求的实践(1)-软件和需求

需求的实践(1)软件和需求林星(iamlinx@)2001 年10 月在这个关于软件工程的新专栏里，作者将通过一系列的文章，结合理论知识，实践案例，优秀的工具介绍，经典文章导读，告诉您软件工程中最重要的一个过程――需求过程各方各面的知识。

通过阅读，您将了解到，需求的知识体系，需求的过程能力，相关的软件工程知识，在实践中如何做好需求分析。

文章虽然有很多的例子，但是，文章主要还是偏向于宣传一种思想，一种面向对象的思想，一种实践的思想。

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. 需求是变化的大师说：目前众多的软件项目有什么样的问题呢？早些时候上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. 需求是什么在RUP1.2. 使系统开发人员能够更清楚地了解系统需求。

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

4.5.6.* 涉众：涉众是所有会受到项目结果重大影响的人。

如客户（或客户代表）用户（或用户代表）、投资者、股东、生产经理、买方、设计员、测试员、文档编写员等企业的业开需求管理。

小企业没有成为体系的管理方法，企业规模小的时候还能够对付，可是企业一大，各种问题都接踵而来，管理上的不足直接导致了业务开展的低效性。

同样，需求管理的不足可能可以应付小型的软件项目，可是对于大型的项目，管理的不足就会暴露出来，而直接的后果就是项目的失败。

插句题外话，很多人认为需求管理的目的是为了控制需求过程，这是没有错，但是在RUP的思想中，更重要的思想是迭代*。

RUP下文讨论）。

* 迭代：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。

所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。

实质上，它类似小型的瀑布式项目。

1.6. 需求的层次《软件需求》一书中有对需求层次的详细定义：软件需求包括三个不同的层次business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用用例（use case）文档或方案脚本（scenario）说明中予以说明。

功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

软件需求各组成部分之间的关系如图所示：图二对应到RUP RUP的业务建模流程（Business Modeling），在这个流程中，参与者主要是业务流程分析员（Business-Process AnalystERP项目就意味着你必须优化业务流程，而上一个部门级MIS项目就没有必要用牛Business Vision而业务需求的确定对之后的用户需求和功能需求起了限定作用，RUP角色和用例是UML（Interview）。

Mapping）。

开发者思考的角度从用户转移到开发者。

给用户一个原型，用户就会说，"哦，我的XX系统原来就是这样的。

"这就避免了用户在软件开发完成后才看到软件所带来的一些风险。

是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目，很多时候，用一些非正规的方法来生成原型：如果你要开发一个WEB系统，让你的美工做几个页面给用户看看，如果你做一个C/S系统，做一个界面给用的过于复杂。

1.7. 需求的标准讨论软件需求的文章有很多，对于需求的标准也不尽相同，但是在思想上是相同，都是为了保证项目的顺利进行。

这里我总结一些比较通用的标准，可能并不完善，但你只要能保证做到这几点，、和用户的沟通将成为一个大问题，的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。

的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。

信用卡有卡号、余额。

一张信用卡有多笔的交易记录。

象一下遗漏需求而不得不返工，可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。

要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。

"我们要用新的系统完成报表自动化处理"，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。

因此这项需求是无法。