发信人: heaven (谁是我的恒星), 信区: Npsos
标  题: 二、需求的是是非非
发信站: 哈工大紫丁香 (2002年12月29日09:54:48 星期天), 站内信件

2002年08月02日 22:21:31 linuxaid  
 
    前些日子有一个朋友向我要一份需求的标准文档，因为他现在正在负责一个项目。我
对他说，我的需求文档只适合我用，并不适合你用。如果你是真的想在开发过程中引入科
学的管理方法，静下心来，认真的学习需求的方法论，仔细的思考适合你们自身的方法。
如果你只是需要一份好看的模版来哄哄Boss的话，那你就随便去找一份文档来修改一下就
行了，保证糊弄得住人。最后我的朋友毅然的找了一份漂亮的文档走了。 

    朋友走后我思考了很久，中国目前有很多的软件公司都很有实力，可是他们在管理方
法上却很成问题。上半年在业界炒得沸沸扬扬的CMM是个什么东西呢？说穿了，就是一套适
合软件行业的管理方法。这套管理方法并不是说你花了大堆的票子去过了CMM的评估或是购
买了Rational公司的什么产品，而是在于你是不是真的理解了里面的管理精髓。前些日子
看一篇报道联想实施ERP系统的文章，里面一句很不起眼的话给了我很大的感触。它说，联
想在实施ERP之前，虽然也有大量的管理规范，但都是空谈的管理，公司主要还是靠“人治
”。而我们现在很多的软件公司还是处于“人治”。“人治”的后果是很严重的，必将导
致你的软件企业成本居高不下，管理上不传，下不达，企业无法快速发展。软件行业历来
以利润高出名，利润是高，你想想软件的边际成本才多少（拷贝一份软件需要多少钱？）
。可是中国的软件行业却做的不好。看看我们的台湾同胞们，虽然他们在软件平台的研究
方面并不出色，但是在软件应用水平上是很了不起的。当然，台湾有他的历史原因：深受
美国文化影响，属于美国制造外包的主要地区。 

    上面说了一大堆的废话，我们还是回到我们的需求上面来。 

沟通是一切 

    需求是一个过程，一个在软件生命周期中很重要的过程。在上一篇中，我们讨论了需
求的层次、需求的风险、需求的特点。而在这么多需求要素之上的要素只有一个：沟通。
沟通是什么，说小了是需求过程的重要技巧，说大了是软件企业的生命线。一个项目失败
的原因有很多，而绝大多数都可以总结到沟通不畅。需求过程中充满了沟通：需求分析员
和用户的沟通，不同的用户之间的沟通，需求分析员和需求审核人员的沟通，项目经理和
需求分析员的沟通。沟通到一个什么程度，是需求成功与否的标志。 

    曾经和几个老同学聊天的时候说起他们去用户哪里做需求调研，用户报来一堆资料，
和他们聊了半天，他们就回去开始设计、编码。我说你后面肯定吃苦头了。果不其然，项
目返工的时间差不多等于整个项目的时间。这太可怕了，意味着这个项目企业极可能亏本
。为什么会这样呢？项目好比一座大楼，如果设计师连大楼要盖多少层都不清楚，那你说
盖出来的会是个什么东西。 

    《软件需求》一书中提到了一个很有意思的概念：软件客户需求义务和权利 

    优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发
人员之间有效的交流与合作。通常，开发人员与客户或客户代理人，如市场人员间的关系
反而会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产
生摩擦，在这种情况下，不会给双方带来一点益处。 

    只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么
时，才能建立起一种合作关系。由于项目压力与日渐增，所有风险承担者有着一个共同的
目标这一点容易被遗忘。其实大家都想开发出一个既能实现商业价值，又能满足用户需要
，还能使开发者感到满足的优秀软件产品。 

    软件客户需求权利书列出了十条关于客户在项目需求工程实施中与分析人员、开发人
员交流时的合法要求。每一项权利都对应着软件开发人员、分析人员的义务。而软件客户
需求义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，可以将其作为
开发人员的权利书。 

软件客户需求权利书 

1. 要求分析人员使用符合客户语言习惯的表达。 
2. 要求分析人员了解客户系统的业务及目标。 
3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 
4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。 
5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。 
6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 
7. 描述产品使其具有易用、好用的特性。 
8. 可以调整需求，允许重用已有的软件组件。 
9. 当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评估。 
10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。 

软件客户需求义务书 

1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 
2. 抽出时间清楚地说明需求并不断完善。 
3. 当说明系统需求时，力求准确详细。 
4. 需要时要及时对需求做出决策。 
5. 要尊重开发人员的成本估算和对需求的可行性分析。 
6. 对单项需求、系统特性或使用实例划分优先级。 
7. 评审需求文档和原型。 
8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 
9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 
10. 尊重需求工程中开发人员采用的流程（过程）。 

    需求权利和义务规定了客户和开发者双方应该做些什么，双方共同出力，确保需求过
程的有序进行。不过，大多数的软件公司一般都把“客户是上帝”这句话贯彻的很好，客
户有什么样的要求，软件公司就做什么样的修改，最终损害的是客户和自己双方的利益。
一次，我和一个小软件企业的技术总监聊起这方面的事情，请教他的做法。他在经历了几
次销售人员随意答应客户要求的痛苦之后，决定亲自出动，在和客户接触的过程中掌握主
动权，判断客户是不是一个“好”客户，再决定做不做这个软件。实施了一段时间后，发
现效果非常的好，成本大幅度下降，客户也很满意。软件开发过程中软件企业和客户是一
对合作者，一荣俱荣，一损俱损。要达到双方共赢的局面，只能靠充分的沟通。 

需求分析和需求管理 

    需求的过程包括了两个过程，需求管理和需求分析。如同一个公司开展业务离不开管
理一样，脱离了需求管理的需求过程很难做到顺利的完成需求过程。当然，并不是所有的
软件公司都没有需求管理，例如安排需求的时间也是需求管理的一方面，大多数的软件公
司都没有一个科学的、 

    任何活动都离不开管理，需求过程也不例外。需求过程的活动分为需求管理和需求分
析两种。大多数人说不清楚需求管理和需求分析的差别，但是他们在进行需求过程的时候
已经不知不觉的在开展需求管理和需求分析两种活动了。这种行为就有点像一些小企业主
，缺乏科学的、系统的管理知识，但你却不能说他不懂管理，因为他有大量的实践经验。
同样的，一些不够成熟的软件企业在进行需求分析的时候，主要还是靠经验，并没有一个
经过验证的方法。 

    需求分析活动包括对一个软件项目需求的获取、分析、规格说明及验证。典型需求分
析的结果是软件需求规格说明（System Requirements Specifications）及相关分析模型
。经评审批准，这些文档就定义了开发工作的需求基线（baseline）。这个基线在客户和
开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定（agreement）。工程项
目可能会有其它的约定，例如可交付性、约束条件、进度安排、预算及合同约定等。但这
些并不是需求过程主要考虑的因素。 

    需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需
求约定集成性和精确性的所有活动，如图所示。需求管理强调： 

1、控制对需求基线的变动。 
2、保持项目计划与需求一致。 
3、控制单个需求和需求文档的版本情况。 
4、管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。 
5、跟踪基线中需求的状态。 

    和任何的管理活动一样，需求管理的目的也是为了确保需求分析活动按照既定方针执
行。 

CMM 

   CMM（capability Maturity Model）过程成熟度模型，这个概念是由位于宾夕法尼亚洲
匹兹堡市的卡内基梅隆大学所属的软件工程研究所提出的。CMM是在软件开发机构中被广泛
地用来指导过程改进工作的模型。该方法描述了软件处理能力的五个成熟级别。处于一级
的组织典型地以非正式的方式管理项目进度，要获得成功，主要依靠天才从业者和管理者
的英雄史诗般的奋斗。处于更高成熟度级别的组织把具有创造性、训练有素的员工同软件
工程和项目管理过程结合起来，将持续不断地获得成功。 

    过程能力成熟度模型对需求管理是一个有用的指导。为达到软件过程能力成熟度模型
的第二级，组织必须具有在软件开发与管理的六个关键过程域（key process areas，KPA
）以展示达到目标的能力。需求管理是其中之一，它的目标如下： 

1) 把软件需求建立一个基线供软件工程和管理使用。 
2) 软件计划，产品和活动同软件需求保持一致。 

    需求管理的关键过程领域不涉及收集和分析项目需求。而是假定已收集了软件需求或
已由更高一级的系统给定了需求。一旦需求到手且文档化了，软件开发团队和有关的团队
（例如质量保证和测试）需要评审文档。发现问题应与客户或其它需求源协商解决，软件
开发计划是基于已确认的需求。 

    开发团队在向客户、市场部或经理们作出承诺（commitment）之前，应该确认需求和
确认约束条件、风险、偶然因素、假定条件。也许不得不面对由于技术因素或进度原因而
不现实的需求作出承诺。但是，决不要承诺任何无法实现的事。 

    关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版本控制确保随时
能知道在开发和计划中正在使用的需求的版本情况。变更控制提供了支配下的规范的方式
来统一需求变更，并且基于业务和技术的因素来同意或反对建议的变更。当在开发中修改
、增加、减少需求时，软件开发计划应该随时更新以与新的需求保持一致。不反映现实的
计划于事无补。 

    必需要强调的一点是，CMM只是推荐方法，并没有说你一定要采用这种方法。仔细的分
析自身的特点，总结适合自身的方法。但是CMM提到的两个目标却是任何需求活动都应该追
寻的目标。事实上，不但各个企业采用的方法不同，即便是企业内部，对于不同的项目，
也不存在一个标准的模式。每个项目都有自身的特点，不能强制性的要求他们采用同样的
模板。所以在项目开始的时候，一般在项目可行性论证的时候，管理小组就会根据本个项
目的特性制定项目计划和需求计划。 

需求管理步骤 

    开发组织应该定义项目组执行管理他们需求的步骤。文档化编写这些步骤能使组织成
员持续有效地进行必要的项目活动。请考虑选择以下主题： 

1、用于控制各种需求文档和单个需求版本的工具、技术和习惯做法。 
2、建议、处理、协商、通告新的需求和变更给有关的功能域的方法。 
3、如何制定需求基线。 
4、将使用的需求状态，并且是谁允许作出的变更。 
5、需求状态跟踪和报告过程。 
6、分析已建议变动的影响应遵循的步骤。 
7、在何种情况下需求变更将会怎样影响项目计划和约定。 

    你可以在一个文档中包含上面所有的信息。或者，你可能喜欢专题分述，例如分成变
更控制过程，影响分析过程，状态跟踪过程。这些过程可能在多个项目中都有用，因为他
们反映每个项目所应遵循的公共功能。 

    需求控制的工具有很多，你可以使用专业的Rational公司的RequisistPro，也可以使
用一些可视化的数据库管理工具，甚至你可以只是使用目录结构。用什么样的工具并不是
特别重要，关键还是在于人。上面已经说过，需求的管理最重要的（关键过程域）就是版
本控制和变更管理。这两个方面是密切相关的。需要版本控制的一个重要因素就是需求在
不断的变化。 

文档的海洋 

    虽然到现在还没有提到任何的具体文档，但是需求过程的产品中大都是文档。文档的
产生目的是为了项目能够被控制。如果为了实现控制项目的目的，而文档却陷入了不可控
制的境地，那就是一条歧途了。想象起来是很可笑，但是这个错误是确实存在的。往往有
一些狂热的技术分子，为了追求完美的实施项目管理，实施了过多的文档，可是这个项目
本身并没有想象的那么庞大。到了最后，是由于文档的失控导致了项目的失控。即便是以
完善著称的RUP（Rational Unifined Process）也并不提倡制作过多的文档。控制好你的
计划，使之适合你的项目。需求分析人员应该专注于需求的获取和分析，而不是写出漂亮
的文档。当然，如果用户有这方面的要求的话，你是应当重视的。 

需求管理活动的积累材料 

    变更控制过程变更控制过程能够减少因无休止、失控的需求变更引起的混乱。它明确
了一种方法来提出、协商、评估一个新的需求或在已有需求上的一项变更。变更控制通常
需要问题跟踪工具的支持，但请铭记工具并不能替代过程。 

    变更控制委员会过程变更控制委员会(CCB)是由风险承担者的主要成员组成的，对提出
的需求变更决定执行哪一项，拒绝哪一项，以及在各产品发行版本中包括哪些变更。CCB过
程描述了变更控制委员会的组成及操作过程。CCB的主要活动是对提出的变更进行影响分析
，为每项变更作出决定，并且告知那些将受到影响的人。 

    需求变更影响分析清单和模板估计提出的需求变更的成本费用和影响是决定是否执行
变更的重要步骤。影响分析能帮助CCB作出正确的决定。影响分析清单包括许多自问自答型
的问题，如：要考虑到可能的任务、边界影响、实施所确定的变更引起的相关的潜在风险
。一张参与人员工作表可以作为估计任务工作量的简单方法，从这里就能明白确认变更的
复杂性。 

    需求状态跟踪过程需求管理包括监控和报告每项功能需求的状态和状态改变的条件。
你需要一个数据库或一种商业需求管理工具来跟踪一个复杂系统中大量的需求状态。此过
程也描述了当你随时查看收集到的需求状态时输出的报告格式。 

需求跟踪能力矩阵模板需求跟踪能力矩阵列出了SRS中的所有功能需求及相应的设计模块，
源文件和实施需求的过程，还有验证需求实施正确性的测试用例。跟踪能力矩阵应该也可
以指出对应的上一层用户需求或系统需求。 


需求分析 

    需求分析可分为：问题获取（elicitation）、分析(analysis)、编写规格说明（spec
ification）和验证（verification）四个阶段（Thayer and Dorfman 1997）。这些子项
包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方
面： 

1、确定产品所期望的用户类。 
2、获取每个用户类的需求。 
3、了解实际用户任务和目标以及这些任务所支持的业务需求。 
4、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决
方法和附加信息。 
5、将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 
6、了解相关质量属性的重要性。 
7、商讨实施优先级的划分。 
8、将所收集的用户需求编写成规格说明和模型。 
9、评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说
明之前将问题都弄清楚。 

需求开发过程的积累材料 

    1) 项目视图与范围模板项目的视图与范围文档明确了项目的概念性功能，并提供了确
定需求优先级和变更的参考。需求视图与范围文档是简明扼要的、高度概括的新项目业务
需求说明。用统一的方式编写项目视图与范围文档能确保在项目进行过程中作决定时能考
虑到所有应考虑的情况。 

    2) 需求开发过程该过程介绍了怎样确定客户及从客户那里获取需求的技术。也描述了
项目。需要创建的各种需求文档和分析模型。这个过程还指明了每项需求包含的信息种类
，比如：优先级、预计的稳定性或计划发行版本号。同时还应指明需求分析及需求文档检
验需要执行的步骤以及确认软件需求规格说明和建立需求基线的步骤。 

    3) 需求分配过程把高层的产品需求分成若干特定子系统是非常重要的，尤其是当开发
的系统既含有软件又含有硬件或是包括多个子系统的软件产品时尤为重要（Nelsen 1990）
。需求分配是在系统级需求完成和系统体系结构确定后才进行的，这个过程包含的信息是
怎样执行分配以确保功能分配到合适的系统组件中，同时也说明分配的需求怎样才能追溯
回它们的上两级系统需求以及在其它子系统中的相关需求。 

    4) 使用实例模板使用实例模板提供了一种把每项用户希望使用软件系统完成的任务编
写成文档的标准方法。使用实例定义包括一个简要的任务介绍，必须处理的异常情况的说
明和描述用户任务特点的附加信息。使用实例可作为软件需求规格说明中一条独立的功能
需求。另外，你也可将使用实例与SRS模板合并为一个文档，既包括产品的使用实例，又包
括软件功能需求。 

    5) 软件需求规格说明模板软件需求规格说明模板提供了一种组织功能需求和非功能需
求的结构化方法。采用标准的SRS模板将有助于创建统一且高质量的需求文档。可能要采用
多个模板以适应组织承担的不同类型和规模的项目。这样可减少因一种“万能”模板并不
适合你的项目所带来的障碍。 

    6) 需求优先级确定过程，此时为满足进度时限要求，计划的功能不得不放弃掉。我们
需要知道哪些性能、使用实例或功能需求的优先级最低，以便在任何阶段，我们都可适当
缩减范围。 

    7) SRS和使用实例审查清单对需求文档的正式审查是保证软件质量的一项重要措施。
审查清单指出在需求文档中发现的一些错误。在审查会议的准备中运用清单将使你的注意
力集中到通常存在问题的地方。
 

--

不开心，就算长生不老也没用，开心，就算只能活几天也足够

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 218.9.97.220]