（工商管理专业论文）需求管理在软件项目管理中的实践.pdf

0 2 2 0 2 5 3 5 6 禹哗需求管理在软件项目管堙中的实践 摘要 随着软件行业的不断发展，软件项目开发的复杂性不断增加。软件项目实践过程 中有大量的统计数字表明，许多软件开发项目失败，并不是软件开发技术方面的问题， 而是管理方面的问题造成的，而需求管理的不够完善在诸多项目管理问题中尤为突 出。需求管理是当前软件项目管理中相对薄弱的一个部分，也是现代化软件项目管理 中急需加强和提高的重要环节。在大量的软件项目管理实践中，需求管理或者完全欠 缺，或者是仅仅停留在需求获得和需求分析上。在整个软件项目的生命周期过程中， 即：项目的启动、计划、执行、控制和收尾这五个主要的项目过程中，需求管理是一 个系统化的，贯穿始终的过程。在软件项目生命周期的各个阶段，需求管理有不同的 内容和侧重方面，实施过程中有相应的方法和技巧。就整个需求管理过程来看，达到 用户的需求满足是最终目的。因此，需求管理对于软件项目的成功实施不仅是重要的， 而且是必要的。需求管理在软件项目管理中具有非常重要意义。文章从软件项目开发 实施中存在的实际问题入手，介绍了需求管理的基本原理和实施要求。文章重点介绍 现代软件项目管理实践中对于需求管理的认识，实施。并以中国银联信息处理中心交 换系统集成项目成功实施需求管理为例，详细介绍了在软件项目管理各个阶段的实践 中对于需求进兴有效管理的方法和措施。文章在介绍中国银联信息处理中心交换系统 需求管理的目标，计划，实旆，控制的同时着重对于其中的实施和控制提出了看法和 改进意见，并对于项目的需求管理实践做出总结。 关键词：需求管理软件需求需求变更价值工程 0 2 2 0 2 5 3 5 6 禹哗需求管理征软件项目管理中的实践 a b s t a e t a st h eg r o w t ho ft h es o f t w a r ei n d u s t r y ，t h ec o m p l i c a t i o no fs o f t w a r es y s t e mb o o m s i n s t a n t l y al a r g en u m b e ro fs t a t i s t i c so ns o f t w a r ea p p l i c a t i o ns h o w st h a tt h ef a i l u r e so f s u c hp r o j e c t sa r ed u et op r o b l e m si nm a n a g e m e n ti n s t e a do ft e c h n i c a li n s u f f i c i e n t p o o r r e q u i r e m e n tm a n a g e m e n ti so u t s t a n d i n gi nl i s to fp r o b l e m si np r o j e c tm a n a g e m e n t i n m a n yp r o j e c t s ，r e q u i r e m e n tm a n a g e m e n ti s i n s h o r t a g eo rl i m i t e di n t or e q u i r e m e n t a c q u i r e m e n ta n da n a l y s i si t s e l f ir e q u i r e m e n tm a n a g e m e n th a sv a r i o u sc o n t i n e n t sa n d p r e f e r m e n t ，w i t i lc o r r e s p o n d i n gm e t h o d sa n dt e c h n i q u e si nt h el i f e c y c l eo fs o f t w a r ep r o j e c t ， t h a ti s ，s t a r t ，p l a n ，e x e c u t i o n ，c o n t r o la n df i n i s h r e q u i r e m e n tm a n a g e m e n t ，a saw h o l ei n s o f t w a l e p r o j c o t ，f o c u s e s i nr e q u i r e m e n tf u l f i l l m e n ta sf i n a l t a r g e t a s ar e s u l t ， r e q u i r e m e n tm a n a g e m e n ti si m p o r t a n t a sw e l la sn e c e s s a r yi ns u c c e s so fs o f t w a r ep r o j e c t s i ti sa l s om e a n i n g f u li nm a n a g e m e n to f s o f t w a r ep r o j e c t s t a r t e dw i t hp r o b l e m so f s o r w a r e p r o j e c ta p p l i c a t i o ni nr e a l i t y ，t h i sa r t i c l eg i v e sa ni n t r o d u c t i o na b o u tt h ec o n c e p t i o na n d p e c u l i a r i t yo ft h er e q u i r e m e n t sm a n a g e m e n t , d e s c r i b e st h ei m p o r t a n c eo fr e q u i r e m e n t s m a n a g e m e n ti ns o f t w a r ee n g i n e e r i n ga n dp r a c t i c eo ft h es o r w a r ep r o j e c t t h e n ，t h ea r t i c l e r e p r e s e n t sp r i n c i p l e so fr e q u i r e m e n t sm a n a g e m e n ta sw e l l 站g u i d e st oa p p l i c a t i o no f r e q u i r e m e n t sm a n a g e m e n t t h ea r t i c l ef o c u s e si np r a c t i c eo fi n f o r m a t i o ne x c h a n g i n g s y s t e mo fi n f o r m a t i o nc e n t e ro fc h i n au n i o n p a y b e s i d e so ft h ef u n d a m e n t a lt h e o r y , t h e a r t i c l ei l l u s t r a t e sc o n t e n to fr e q u i r e m e n t sm a n a g e m e n ti np r a c t i c e t h ea r t i c l ea l s ot e l l s a b o u tp r o s p e c t e di m p r o v e m e n t si na p p l i c a t i o no fr e q u i r e m e n t sm a n a g e m e n ta f t e rg i v i n g s u m m a t i o no f t h i sp r o j e c t k e y w o r d s ：r e q u i r e m e n tm a n a g e m e n t s o f t w a r er e q u i r e m e n t r e q u i r e m e n tc h a n g i n g v a l u ee n g i n e e r i n g 0 2 2 0 2 5 3 5 6 禹哗需求管理在软件项目管理中的实践 引言 本论文讲述了软件开发中一个至关重要的问题一软件需求问题。 软件丌发人员及用户往往因为缺乏系统科学的管理，忽略信息沟通等原因，导致 软件开发出来后，不能很好地满足用户的需要，造成大量返工。返工则不仅在技术上 给开发人员带来巨大的麻烦，而且软件性能深受影响，同时造成人力、物力的浪费。 所以在整个软件项目生命周期加强需求管理，提高项目需求提炼、分析和确认的质量， 减少重复劳动，通过控制项目范围的扩展及对于需求变更的管理来达到按计划完成预 定目标，实现需求的满足是当前我国软件业急需解决的问题，这也是本篇论文讨论的 主要内容。 本篇论文的编写目的在于通过整个中国银联信息处理中心交换系统项目的需求 管理实践介绍，揭示需求管理问题在软件项目管理中贯穿始终，而不是局部和割裂的。 需求管理在软件项目周期的各个阶段有着不同的内容和重点。文章着重分阶段探讨对 于需求管理问题的注意事项和解决方案，介绍软件项目实旆过程中的管理实践。 本文分为四个部分。第一部分介绍软件项目管理在实践中存在的需求管理问题和 现状；第二部分介绍需求管理相关的理论和近期研究的发展状况；第三部分介绍银联 信息处理中心交换系统项目背景和需求管理实践；第四部分提出对于软件项目巾的需 求管理进一步实践的展望。 1 软件工程发展和存在的实际问题 在第二次世界大战结束后的1 9 4 6 年，第一台计算机诞生了。在计算机技术发展 过程中，软件开发历经几个阶段。从最初的几个数学家和电子工程师个人进行的代码 开发到上个世纪六十年代起计算机专业程序员们进行多人的，经由设计、实施、测试、 交付的大型项目开发，其间经历的变化是巨大的。随着硬件通用性逐渐被人接受，软 件通用性的要求也随之被提出。但是随着软件开发的复杂性不断增加，早期带有强烈 个人色彩的软件开发模式出现了种种问题：软件系统的庞大和复杂让人吃惊，软件维 护的难度越来越大，软件开发的成本不断升高。六十年代末，这样的问题最终演化成 为“软件危机”。为了解决这些问题，一门新的科学软件工程学应运而生了。软 件工程学是一门指导软件开发和维护的工程科学。它采用工程的概念、原理、技术和 方法来开发和维护软件，把经过时间考验和证明正确的管理技术和当前能够很好得到 的技术方法结合起来。软件工程强调使用生命周期的理论和结构分析和结构设计的方 法以及在最近的几年来提出面向对象的设计方法。软件工程是一门研究如何用系统 化、规范化、数量化等工程原则和方法进行软件开发和维护的学科。 从1 9 6 8 年软件工程的概念提出到现在，已经有了三十多年的发展和实践。软件 0 2 2 0 2 5 3 5 6 禹晔需求管理在软件项目管理中的实践 工程逐渐成为- - f q 成熟的专业学科，在软件产业的发展过程中起了举足轻重的作用。 但是在软件项目开发的实践过程中，许多的问题不断涌现，原有的问题还没有得到完 全的解决。软件项目实践过程中还有大量的问题需要解决。统计数字表明，大量的软 件开发项目失败，并不是软件开发技术方面的问题，而是管理方面的问题造成的。尽 管人们对于软件项目的管理问题重要性的认识不断提高，相关的管理理论也在不断发 展，但是和技术方面的设计方法学与实现方法学上的进步相比较，仍然有着不小的差 距。1 9 9 4 年( s c i e n t i f i ca m e r i c a n 的报道认为“尽管经过5 0 年的进步，仍然存 在着一种慢性的危机。这就是缺少能够满足信息时代要求的成熟工程科学的状况已经 持续几十年了”。 软件工程将软件的生命周期划分为三个部分，软件定义，软件开发和软件维护。 问题定义、可行性研究分析和需求分析是软件定义部分的三个阶段。也有人将软件的 开发过程具体划分为制定计划、需求分析与定义、软件设计、程序编写、软件测试和 运行、后期维护几个阶段。无论是在哪种划分方式，从划分的结果来看，需求分析都 处于软件项目整个过程的起始阶段。 然而，在软件开发的实际过程中，人们往往注重软件的设计和代码实现。从事软 件开发的工程人员更关注软件的整体架构，软件语言和实施平台的选择，以及代码运 行的效率等等。对于处于软件项目起始阶段的需求分析与定义，往往是工程人员忽视 的问题。但是，在最近十年来的软件项目开发实践总结表明，软件项目失败的原因大 多数都和需求管理存在的问题相关。 1 9 9 7 年1 1 月( c o m p u t e ri n d u s t r yd a i l y 的一份调查报告显示：在美国和英国 计算机公司的5 0 0 名管理者中，7 6 都经历过整个项目的失败。对于失败的总结和失 败原因，出现最多的字样是“用户变更的需求”。 一项对t r m 公司所做过的软件项目分析结果表明：在所有检测出来的错误中， 5 4 是在编码和单元测试阶段以后才被发现的，而此类错误的最大一部分( 占全部的 4 5 ) 是在需求和设计阶段发生的。相比之下，编码错误所占的比例仅仅有9 。 一项对g t e t r w 、i b m 三家公司的研究结果表明，在需求阶段检查和修复一个错误所 需的费用只有编码阶段的1 5 到1 1 0 ，而维护阶段所做同样工作付出的代价是编码阶 段的2 0 倍。 由于软件是逻辑实体而不是具体的物理实体，因此软件工程和硬件制造项目工程 有很大的不同。软件在维护过程中的改变有可能引入新的缺陷，如图1 1 所示。这些 新的缺陷往往隐藏很深，在特定的时刻或者逻辑条件下爆发。软件的可靠性因为缺陷 的存在而大大降低。越来越多的引入缺陷会最终导致软件失效。 0 2 2 0 2 5 3 5 6 禹哗 需求管脞在软件项目管理中的实践 f 修 实际 十 软件失效曲线 软件维护时的改变 会引入新的缺陷 图1 1 软件失效曲线 新产品开发一般都是从构想开始，经历一系列的阶段，最后实现商品化。在产品 开发的早期阶段，对于产品设计进行更改还是相对容易的。但是如果产品的原型已经 开发出来，再想更改设计的就相当困难了。更改设计的费用的变化正好与更改的灵活 性特点相反。在产品原型开发出来后，更改设计的开支就会变得越来越大。同样的， 当软件开发过程中出现问题，尤其是出现策略性失误时，这些错误和问题会影响整个 系统的可靠性和安全性。问题解决得越晚，为之付出的修改成本和可靠性代价就越大。 因此，把握软件项目的前段的需求环节是至关重要的。 在实践过程中，软件项目的实施人员最常见到的问题是： 用户陈述的需求并不是软件项目实施人员理解的需求，双方在理解基础业务过程 和描述需求方面存在很大差异。 软件项目实施人员没有好的需求管理方法，面对不断变化的需求，逐渐丧失对于 需求影响软件系统的控制： 由于在需求之间的矛盾和需求变更造成了不断的返工和修正错误，项目计划被拖 延，项目开支超过预算。 在这些问题中，都与软件项目的需求分析和定义环节相关。由于需求定义的模糊， 软件项目的实施就失去了依据。在此基础上继续项目的施工，要么与原先构想偏离， 最终要退回重来，要么等待需求定义澄清，最终延误了工期。依靠侥幸进行软件项目 实施，其失败的风险是巨大的。需求定义完成后，需求分析的质量也直接影响项目的 成败。缺乏科学的需求管理方法将导致低质量的需求分析。低质量的需求分析对于软 件项目的开发危害极大。且不说软件今后的维护和升级问题，由此带来的代码冗余和 错误就足以让一个软件项目面临质量危机。 实际工作过程中，我们可以不断地体会到对于软件需求不仅仅是做到需求的分析 和定义，我们更加需要对于需求进行系统的、全面的管理a 在软件项目的开发实践过 0 2 2 0 2 5 3 5 6 禹晔 需求管理在软件项日管理中的实践 程中，用户的需求常常是杂乱无章，甚至是相互矛盾的。不仅如此，这些需求常常是 不断地提出，而且在不断的变更中。开发者必须面对这一现实，穷于应付。为了满足 需求。软件系统不断更改，甚至破坏和颠覆从前设计的框架结构。这样，不仅大大降 低了软件的可靠性和安全性，更为今后的维护问题留下隐患。往往经过一段时间的修 改和变更之后，软件系统变得面目全非，异常复杂，甚至于崩溃，无法使用，只有推 倒重来。即使经历了一系列补丁操作，软件系统最终如期或者延期完成代码实现，项 目仍将面对验收和测试的严峻挑战。需求管理不完善会造成验收测试标准的混乱。在 验收测试阶段发生争执，各持己见于是成了项目实施阶段中不可避免的风景线。无论 这样的争执最后以哪一方的优胜结束，其对项目涉及各方都不会有很好的影响。 怎样对于需求进行系统的、全面的管理? 这里显然不仅仅需要在项目管理者的脑 海中存在需求管理的意识。在对于需求管理重要性有充分的认识之后，项目管理者需 要更多的需求管理工具和方法，这些方法与工具的使用将帮助项目管理者完成他们所 期望的、有效的需求管理实践。那么，这些方法和工具从何而来? 需求工程把对于软件需求的研究从一个阶段的事务上升到作为一项完整工程的 高度，为需求的管理提供了可贵的理论参考和指导。需求工程可以直观的理解为在软 件开发的关于获取、分析、编写、验证、跟踪和控制需求的技术、方法和工具。也就 是说，用工程的方法管理需求。这样一来，现实软件开发过程中存在的许多需求管理 相关问题就能够通过需求工程的实践得以解决。 2 需求管理的理论研究 2 1 需求管理概述 2 1 1 需求的定义 需求在现代汉语词典的定义为“因为需要而产生的要求”。这个定义从用户 的角度表达了用户方提出的某种满足其意愿的能力要求。具体到软件项目来说，就是 用户方对于软件产品和服务能够满足其某些需要的期望。但是，对于需求所涉及的开 发者而言，这里没有提及。按照这个定义，在开发者听来，用户所定义的需求似乎更 像是一个产品的概念。 但是开发者所说的需求，往往包含着更多的诸如“数据库容量”，“用户界面”等 设计内容。需求就是关于系统行为或系统特性和属性的种种描述。按照这个定义，在 用户听来，这些更像是开发者的详细设计。 面对这种因为所处角度不同而造成的差异，也有人把“需求”的概念澄清为：需 求就是关于系统应该做什么而不是怎么做的陈述。在h a r w e l l 等人编著的w h a ti sa r e q u i r e m e n t ) ) 一书中，它定义需求是系统中的一种必要属性，需求是标识系统的能 - 8 - 0 2 2 0 2 5 3 5 6 禹晔需求管理在软件项目管理中的实践 力、特点或质量因素以使系统具有价值并使用户能够使用的描述。( p 2 3 3 9 ) 就软件工程而言，目前最权威的定义是i e e e 给出的定义。i e e e 的软件工程标准 词汇表中定义需求为： 1 1 用户解决问题或者达到目标所需的条件和能力； 2 ) 系统或系统部件要满足合同、标准、规范或者其他正式文档要求具有的条件 或能力： 3 ) 某种能够反映以上1 ) 和2 ) 描述的条件或能力的文档说明； 由此可见，从需求所涉及的双方来看，需求是一种满足要求的能力。这种能力是 通过正式的条款、规范等文档得以表达，并由双方确认的要求的总和。按照需求的内 容又可以划分为：业务要求，系统目标、重要资源、理由、用户类型、用户需求和约 束条件等等。 2 1 2 需求工程的定义 需求工程( r e q u i r e m e n t se n g i n e e r i n g ) 的准确定义没有统一的或权威的描述。按 照前文所述，需求工程可以直观的理解为在软件开发的关于获取、分析、编写、验证、 跟踪和控制需求的技术、方法和工具。这里使用“工程”术语意味着采用系统的，可 重复的技术来确保系统需求是完整的、一致的、相关的。从系统工程角度定义，需求 工程包含与发现、记录和维护计算机系统的需求相关的所有活动i 。从工程角度理解， 可以认为需求工程是软件工程的一个组成部分。 2 1 3 需求管理的定义 顾名思义，需求管理是完整管理模式中的一环，同其他特性诸如一体性 ( c o m p l e t e n e s s ) 、一致性( c o n s i s t e n c y ) 等不可分割，彼此相关而成一体。一套需求 管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满 足( 甚至是充分满足) ，仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能 是灾难性的，比如一架飞机的外形设计和内部舒适性的设计都尽善尽美，但是安全设 计不过关，那么后果会是怎样的? 在软件项目过程中，代码是简洁的，结构也足够清 晰，但是对于某个特殊问题的处理会出现逻辑错误。这样的软件当然是无法被接受的。 因此，需要对诸多需求的关键需求加以识别，对于需求的满足是尽可能的充分满足。 不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解 决的问题以及所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的 每一件事，指明了所有设计应该提供的功能和必然受到的制约。 在i b mr a t i o n a l 白皮书中将需求管理作如下定义： 需求管理就是： 一种获取、组织并记录系统需求的系统化方案，以及 0 2 2 0 2 5 3 5 6 禹哗 需求管理在软件项目管理中的实践 一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。 这个定义与d o f f m a n 与t h a y e r 以及i e e e 的“软件需求工程”的定义相似， 需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是 对所有相关活动的规划和控制。i i 关于需求管理和需求工程之间的关系在后面的专题 加以论述。 2 1 4 需求管理的任务 需求管理的挑战对于软件工程人员而言远远超出了“管理需求”或者是“需求分 析”的概念范畴。需求管理要求在项目或者系统的整个生命周期付出努力和实践，解 决其中产生的所有需求问题。 需求管理能够确证： 我们确知客户的需求是什么( 质量) ： 满足客户需求的最佳解决办法( 统一陛) ； 需求管理所要完成的任务： 需求可以说是一种模型，是产品的早期雏形，是所有后续工作的基础。通过进行 需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处 于变化之中的。需求管理需要完成的任务包括： 明确需求并达成共识； 建立关联： 根据不同需求设计相应解决办法： 进行系统优化： 提出设计方案： 监控和解决可能出现的问题以及需要做出的改变； 控制不同开发任务的开展； 对最终产品做出评测； 监控可能出现的重复开发： 提出项目实施时间表； 确定最终用户界面。 从以上两个要点的陈述可以得出，需求管理的首要任务在于使开发人员和用户双 方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关 人员包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一 个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明 确需求，并使所有相关人员达成共识。此后，需求管理要求需求的各方共同对需求负 责，控制项目实旌的进度、成本等因素，推动项目的有效协作。最终，需求管理要求 通过有效的机制进行测试与检验，最终达到用户的需求得到满足。 0 2 2 0 2 5 3 5 6 禹哗 需求管理在软件项耳管理中的实践 2 1 5 需求管理的重要性 需求管理是在软件项目管理的实践中被提出并加以认识的，因此，需求管理的重 要性也就需要通过回顾软件项目管理的发展的经验与教训历程得到论证。 2 1 5 1 需求管理不当带来的问题 s t a n d i s h 集团公司1 9 9 4 年在一项涉及3 5 0 家公司超过8 0 0 0 个软件工程项目的调 查中发现3 1 的软件项目在完成前被取消。在小公司，只有1 6 的项目在工期和预 算上符合要求，在大公司，这个数字只有9 。为了弄清其原因，该公司在1 9 9 5 年对 于失败的项目进行调查，结果发现排在最前面的一些因素为：i i i 1 ) 需求不完整( 1 3 1 ) 2 ) 缺乏用户参与( 1 2 4 ) 3 ) 缺乏必要的资源( 1 0 6 ) 4 ) 期望超出现实( 9 9 ) 5 ) 缺乏实施的支持( 9 3 ) 6 ) 变化的需求和期望( 8 7 ) 7 ) 缺乏计划( 8 1 ) 8 ) 不再需要这个系统( 7 5 ) 在所列出的诸多因素中，和需求管理相关的因素就占了5 条( 第1 、4 、6 、7 、8 条) ，所占比例之和达到4 7 3 。由此可见需求管理在软件项目管理中是非常重要的 一个组成部分，也是软件管理实践过程中非常薄弱，需要加强的一环。 通常情况下，项目的开发实施仅仅停留在需求分析的角度上。即：弄清客户的需 求是怎样的，并以此指导开发和生产实践。项目管理过程中对于客户的需求没有提高 到需求管理的高度上，而是认为它等同于需求分析，简单的作为项目的一个阶段内容。 这样的认识是片面的，也是有害的。需求管理是一个贯穿软件项目始终的交互式的过 程。它需要有一整套有效的机制、方法、手段和工具的支持。把需求管理等同为需求 分析，在外表看来是存在着对于需求的关注，但是局限在软件工程的某个阶段，其所 做的事情是非常有限的，完成的也是相对简单的一些事情。随着软件工程规模的扩大， 面对的需求越来越多，需求相互之间的关系越来越复杂。在这种情况下，单单是需求 分析无法完成对需求的有效管理。面对需求的变更问题，如果仍然依靠需求分析这个 环节，对于问题的解决就是一筹莫展了。 有了需求分析也并不意味着有了一切。需求管理的过程是一系列系统的活动。从 需求的标识、描述、分析、定义、变更、实现、跟踪和验证需要清晰流畅的步骤、方 法和管理工具。组织成员在这个过程中充分利用各种资源。采用科学管理的方法和遵 循系统工程的一般规律，才不致造成不必要的资源浪费，高效率地完成项目任务。管 理方法的不当，危害的不仅仅是项目本身，也将损害团队的合作精神。 以上需求管理不当带来的诸多问题长期以来困扰着软件项目的管理者，应该是对 0 2 2 0 2 5 3 5 6 禹晔需求管理在软件项耳管理中的实践 这些问题做一个彻底清理的时候了。对于需求管理而言，它的重要性正在通过一次次 教训的经历和一个个问题的提出而体现出来。 2 1 5 2 需求管理在新时代的重要性 自2 0 世纪7 0 年代以来，学者和企业经理们不断探求顺应变化形式的市场营销的 新方法，从最初的以产品为中心，单纯注重产品质量，到“以顾客为导向”，争取顾 客的满意与忠诚。直至9 0 年代，顾客价值概念的提出，将市场营销的理念推向了 个全新的高度。 与传统的营销概念相比，顾客价值的创新之处在于企业站在顾客的角度看待产品 和服务的价值。这种价值不是企业决定的，而是有顾客的实际感知决定的。从这个意 义上来说，顾客价值是顾客感知价值( c u s t o mp e r c e i v e dv a l u e ) ，是顾客感知利得与感 知利失之间的权衡。特雷西( t r e a c y ) 和威尔斯玛( w i e r s e m a ) 将顾客价值描述为： 顾客所得到的收益之总和减去其在获取产品和服务时所付出的成本。受益在某种程度 上形成了价值，这个价值是指产品或服务提升了顾客的绩效或经验。成本包括购买和 维护上的支出，以及花费在延期、差错和努力上的时间和精力。有形的与无形的成本 抵减了价值。从顾客满意、顾客忠诚、到顾客价值的每个阶段，企业经营侧重点都存 在着差异。产品质量、服务质量、价格、品牌形象以及企业与顾客的关系等构成了顾 客的价值来源。i v 顾客价值的构成往往不是单一的，而是多重的、复杂的。对于顾客价值进行系统 地分析需要利用价值工程( v a l u ee n g i n e e r i n g ) 的成果。价值工程的定义为：力求以 最低的寿命周期费用可靠地实现产品或作业的必要功能，籍以提高其价值，而着重于 功能研究的、有组织的活动。按照价值工程的要求。在产品设计的早期阶段就对原材 料、元器件的需求进行审查，确保该产品的设计实现最低总体投资。图2 1 5 1 是“设 计更改的灵活性和成本”曲线。说明供应商早期参与对于成本的降低来说是多么关键。 从构想开始的新产品开发，经历一系列的阶段，最后完成商品化。伴随着新产品开发 的过程，公司对于产品设计更改的灵活性已经大大降低了。在早期阶段，对于产品设 计进行更改还是相对容易的。但是如果产品的原型已经开发出来，再想更改设计的就 相当困难了。更改设计的费用的变化正好与更改的灵活性特点相反。在产品原型开发 出来后，更改设计的开支就会变得越来越大。因此，越早让供应商参与产品设计，公 司就越有可能利用供应商的知识和能力，提高协作设计的效益。对软件产品而言，它 也同样遵循这个规律，有着相同的结论。为了确保软件项目总体上实现最低的成本， 在软件项目的早期阶段就应该对于项目的需求进行认真地审视。需求管理正是在软件 项目的整个周期内对于项目的需求进行管理和控制的中心环节。 0 2 2 0 2 5 3 5 6 禹晔 需求管理在软件项目管理中的实践 圈2 i 5 i 设计更改的灵活性和成本曲线 从价值工程的角度来说，需求管理是创造价值的，虽然不是创造直接价值。设计 开发虽然是创造直接价值，但是可能由于需求管理的失败没有任何的意义，价值成为 垃圾。按照价值工程的定义要求，必须将项目实施各个阶段哪些是真正创造价值的， 那些具有决定意义的活动找出来。项目管理的重心就要放在这些有价值的、有意义的 活动上，而不是其它。试想以下的情况： 一个需要每天结算银行利息收入的软件开发成功，但是产生最后的报表却使用 超出了一天的时间。 一个电子商务软件开发项目按时完成，经过测试性能可靠，然而通过它进行交 易的成本是原有方式的两倍。 这两种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。需 求管理通过对于需求价值的分析和评价，避免了上述问题的产生。由此可见，在用户 需求日益复杂和多样的今天，软件项目管理更需要科学的需求管理。 从软件项目的一般过程来看，就行业而言，软件项目开始就有很多的不确定性： a ) 不清晰的客户需求 b ) 设计不完全可以预测 c ) 不断变化的需求 d ) 不断变化的技术 所以，在软件业，客户的需要很难确定，结构常常必须保持开放，以结合接下来 的变化：不然，昂贵的返工会接踵而来。如图2 1 5 2 软件项目不确定程度曲线所示， 随着时间推移，客户需求的不确定性逐渐降低。在软件项目生命周期的后期，客户的 需求逐渐确定下来。( 资料来源：麦肯锡公司m c k i n s e y & c o m p a n y ) 由于这些不确定 性的存在，软件项目管理需要在整个过程中都关注需求问题，即需求管理应当自始至 终。 0 2 2 0 2 5 3 5 6 禹哗需求管理在软件项目管理中的实践 水确定的程度 时闻 图2 1 5 2 软件项目不确定程度曲线 各类软件工程项目可能千差万别，但是每个项目的最终用户都期望得到需求的满 足。结束的项目究竟是否能够满足用户的需求呢? 要避免出现用户的需求得不到满足 情况的发生，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了 一项设计或者一个软件项目并不意味着工作的结束，只有这项工作的最终结果充分解 决了需求满足问题，它才具有里程碑般的意义。同样的，软件产品只有在测试和实际 操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产 品在本阶段工作的结束。需求管理本身的一体性和一致性恰恰完整地体现了这种要 求。 还有研究结果表明：所有软件错误里4 0 是由压力产生的。v 我们知道错误会造 成大量的返工，返工使压力水平更加上升。对于压力一错误一返工一压力这个恶性循 环，需求管理通过在项目的初期尽可能避免错误，在项目的中期尽可能将其控制在小 范围内，在项目的后期尽可能消除来脱离这个恶性循环。 诸多的研究成果，诸多角度的管理理论分析，有效的需求管理对于软件项目实施 的重要性不言而喻了。总而言之，软件项目的需求管理不仅能够为用户创造实际的价 值，更为软件项目管理顺利实施提供了保证。 2 1 6 需求管理的多种模式 需求管理所要搭建的不同模式是由系统工程所采用的标准决定的。传统上需求管 理有两种模式：用户模式和系统需求模式。从这两种模式出发的方案应该分别进行设 计，不幸的是现实中二者常常被混为一谈。 用户模式着重描述用户面临的问题或希望得到的结果。用户模式的语言组织非常 类似于使用场景的实地描述，常常指明时间、场景等信息，比较侧重结果。用户模式 的主要特征就是：无论谁搭建用户模式，都必须从用户的角度出发。 0 2 2 0 2 5 3 5 6 禹晔需求管理在软件项目管理中的实践 系统需求模式实际是抽象化的解决方案。系统需求模式的语言组织经常运用功能 描述或使用详解性的说明文字，事实上功能描述和使用详解正是系统需求模式语言组 织的典型风格。 实际上设计方案应当是第三种模式，即具体化的解决方案。从字面意义上就可以 看出，这种模式已经非常接近于最终解决方案。很多不同的设计方案都能解决用户需 求，而在用户需求既定的同时对设计方案做出修改也是切实可行的。三种模式的形象 说明如图2 1 6 所示： 努 图2 1 l6 需求管理模式 在实际工作中的需求管理模式选择往往受到工程规模大小，现存管理工具的重复 利用，组织机构的结构和工作效率等问题的制约。尽管第三种模式最符合工程实际应 用的需要，但是在现实中更多的是三种模式的混合。显而易觅在三种模式的混合现 实情况下，我们追求的目标应该是让第三种模式占主导地位。 在中国银联信息处理中心交换系统项目中，进行需求分析的方式有两种。进行需 求分析的工具是w o r d 、v i s i o 、r a t i o n a lr o s e 。具体的情况如下： 口传统方式：( i p o 、数据流程) 大部分的业务需求采用传统方式进行分析 口面向对象方式：( 用例图、顺序图、状态图) 用户界面以及系统框架 口分析工具： w o r d 、v i s i o 、r a t i o n a lr o s e 其中i p o ( i n p u t 、p r o c e s s 、o u t p u t ) 是指输入、处理、输出。v i s i o 是一个图表 绘制程序，它可以帮助创建说明和组织复杂设想、过程与系统的业务和技术图表。使 用v i s i o 创建的图表使用户能够将信息形象化，并能够以清楚简明的方式有效地交流 0 2 2 0 2 5 3 5 6 禹哗 需求管理在软件项目管理中的实践 信息，这是只使用文字和数字所无法实现的。v i s i o 最新的2 0 0 3 版本还可通过与数据 源直接同步自动形象化数据，以提供最新的图表；用户还可以对v i s i o2 0 0 3 进行自 定义，以满足特定的需要。 r a t i o n a l r o s e 是一个面向对蒙的软件分析设计建模工具。它使用u m l ( 统一建模 语占) 的图形化的模型描述规范，对软件系统的内夕 部特性和结构进行描述和定义， 在描述和定义的过程中，自动生成和管理设计文档和源代码框架。并可对原有的c + 十 源代码进行分析( 称为逆向工程) ，生成用u m l 描述的系统的逻辑结构模型，供进 一步的分析、设计之用。它把软件的分析设计和编码过程有机地结合起来，相当于在 设计收音机时使用的三角板、圆规、绘图仪，以及万用表、示波器和逻辑分析仪。面 我们过去常用的c c + + 编译器就相当于生产收音机用的电烙铁。 中国银联信息管理系统项目所采用的传统方式即是在软件项目经理角度提出的 抽象解决方案，面向对象的方式即具体化的解决方案把用户界面和整体软件系统的框 架结合起来。 2 1 7 需求管理的工具 对于需求进行管理需要有合适的工具。也就是说对于需求增加、变更、删除等操 作都需要通过合适的手段和工具进行管理。项目管理过程中遇到的具体的问题有很 多，比如：保持文档和现实的一致，及时通知受到变更影响的设计人员，跟踪需求变 更和记录需求的状态等等。所有这些问题的解决都需要有需求管理的工具。这些需求 管理的工具需要满足以下的要求： 1 ) 管理版本和变更 项目基线( b a s e l i n e ) 是每个版本所包含的需求的集合，通过基线的设定自动 维护每个需求的变动历史，同时，在需要的情况下能够取得任何一个时刻的版 本。 2 ) 记录需求的属性 每个需求都有自己的属性纪录，有关人员可以看到并且维护这些属性纪录，通 过属性纪录可以对于需求进行相关的查询和统计工作。 3 ) 影响分析和记录 明确需求和需求之间的关系，建立链接。能够对需求变更做出变动影响分析， 并且可以及时通知受到影响的相关组织人员。 4 ) 跟踪需求状态 保存所有的需求，并且在项目实旌过程中跟踪每个需求的状态，从而实现对于 整个项目的全程跟踪。便于管理者对项目实施过程的控制。 5 ) 权限分级和控制 通过对于开发小组，部门的人员设置不同的权限，实现有层次的共享需求信息， 0 2 2 0 2 5 3 5 6 禹哗 需求管理在软件项廿管理中的实践 并且保证需求管理的有序和安全。 目| j 需求管理工具不足的问题十分突出。虽然在商业市场上有很多的需求管理软 件在出售，但是这些软件对于复杂的需求关系类型，定义和建立关系比较困难。对于 需求通常使用描述的方法可能丢失一些重要的信息，同时又可能产生很多无关紧要的 信息。这些信息都在占用资源，使管理任务加重。需求按照内容可以划分为：业务要 求，系统目标、重要资源、理由、用户类型、用户需求和约束条件等等。这些不同的 需求内容在类型和类型之间首先确定关系，然后再建立需求之间的关系。由于软件工 程面对的实际千差万别，关系的复杂程度可想而知。目前最好的方式是利用图形来表 达这些需求之间的关系，但是现有的需求管理工具在此方面的进步还难以让人满意。 相对于管理工具而言，具体的手段和方法因为自身的灵活性，在需求管理实践中得到 检验。在需求的管理贯穿的整个开发过程中，可以采用的方法有： 料c c b ( 变更控制委员会) 建立c c b ( c h a n g ec o n t r o lb o a r d ) 是需求管理的前提，否则需求管理将成为一句 空话。 c c b 必须包含客户方的决策人士，项目经理，项目经理的领导，关键设计人员， 测试负责人，s q a ( s o f t w a r eq u a l i t y a d m i n i s t e r ) 等，以5 - 7 人左右为宜。 需求确认，发生变更等活动必须由c c b 以会议形式批准。 c c b 对整个项目有最高权力( 不仅负责需求变更，还负责听取项目经理汇报、关 键中间工作产品评审等重要决策) 料需求评审，纳入基线 原始需求必须形成文档，被c c b 评审，然后纳入基线管理，所有变更都需要c c b 评审。 该评审一般步骤： 1 项目经理提出被评审对象，指出受影响、被牵涉对象，评估影响( 主要是带来的 规模、工作量、成本) ，提出计划和计划执行人，举出可能风险； 2 c c b 来决定是否同意或要求项目经理修改上述项目； 3 之后，项目经理提交执行情况汇报。 4 最后，c c b 指定代表或由s q a 进行核实。 如果变更过小，过多，可以进行周汇总评审。 料联系链 联系链的存在使用户了解每个需求对应的产品部件，从而保证每个部件满足每个 需求。这种联系链的存在使用户和相关管理者知道每个部件存在的原因，使开发者知 道为什么写每一行代码，代码的设计元素通过联系链，体现用户的需求。这样，保证 不会有漏掉的需求没有得以实现，也保证没有多余的代码和不必要的功能开发。典型 的联系链如图2 7 所示。在联系链中标志了需求管理各个环节以及相互作用关系。 0 2 2 0 2 5 3 5 6 禹晔需求管理在软件项目管理中的实践 臣姻 圃 虹 上 臣函口 图2 7 需求管理中的联系链模型 以上所介绍的需求管理工具都是在近十年来需求管理实践的产物。在许多的软件 项目工程中通过采用c a s e 工具达到需求管理的目的。关于c a s e 工具的使用在软件 工程的相关文献中有大量介绍和讲述，在本文中将此部分省略。有兴趣者可以参考相 关的软件工程文献。 2 2 项目中的需求管理 2 2 1 需求管理和需求分析的差别 需求管理和需求分析这两个名词在其他的文献中也常常被提到，在论文中有必要 比较澄清二者的区别和联系。总的来说，需求管理和需求分析主要在以下的三个方面 存在不同： 1 ) 定义不同； 2 ) 涉及范围范畴不同： 3 ) 作用和影响不同。 需求分析是一连串的处理过程，处理的精神在于找出使用者的需求，经过萃炼， 将需求( 资料的、功能的以及行为的需求) 模式化，最后产出一份需求规格。在过程 中，系统开发者扮演的角色，是利用高度的沟通技巧，采各种不同的询问角度( 肯定 句、疑问句或不断地重复) ，将可能是被误解或是模糊不清的讯息一一加以澄清。由 0 2 2 0 2 5 3 5 6 禹晔需求管理在软件项目管理中的实眭 以上对需求分析的定义，衍生出软件需求分析的五大主要部份，分别为问题的认知、 问题的评估及综合、模式化的过程、需求规格的产生及需求规格的审查。v i 需求分析的任务是发现、求精、建模和规范约束的过程。它包括对于软件项目范 围的确定，创建数据流、信息流和控制流的模型，分析可以选择的方案，并把它们分 配到软件系统的各个环节、元素中去。它在用户需求和软件设计之间建起桥梁。必须 要注意的是，需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需 求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下 药、量体裁衣，才能才设计开发中去伪存真，不断改进。“需求之需求”正是强调了 贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异 于纸上谈兵。在小型的软件开发，或者说时间要求不强的软件开发项目中，需求管理 所产生的效益或许并不明显，或许要日后才能体现，但是在目前的银联信息处理中心 交换系统项目上，没有一个有序的、经过精心策划的需求管理是不可能