在全球软件业高速发展的今天，软件项目的实施情况却不甚理想。据统计，约80%～90%信息化投资没有达到预期目标，80％的项目超期或超预算，40%的项目以失败告终，只有不足25%的项目达到预期的技术和业务目标。这种局面的出现是与软件项目本身所蕴含的诸多风险密切相关的，如技术风险、管理风险、需求风险等；而能够对需求风险进行有效控制则是决定整个项目成败的关键。
　　企业信息化项目中存在的主要需求风险
　　1.软件需求的定义和层次
　　什么是软件需求呢？关于这个概念有各种各样的定义，IEEE软件工程标准词汇表（1997）中定义需求为：
　　（1）用户解决问题或达到目标所需的条件或权能（Capability）。
　　（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
　　（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
　　这个定义包括了从用户角度和开发者角度来阐述需求；另外一种定义是从系统外部出发认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”（Jones 1994）。下面的定义则从用户需要进一步转移到系统特性（ Sommerville and Sawyer 1997）：需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
　　从上面这些定义可以看出，人们可以从不同角度去理解和描述需求，而关键是参与项目的人员能够针对需求描述达成清晰一致的共识。此外，软件需求又划分为业务需求、用户需求和功能需求三个层次，业务需求（Business Requirement）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement）定义了开发人员必须实现的软件功能。这种层次的划分体现出了需求从抽象到具体、从系统外部到内部的逐级转化过程。对于软件开发人员来说最终必须获得准确详细地功能需求描述，而客户经常会认为只要将业务需求或用户需求描述出来就足够了，从而使最终开发人员获取的需求信息不够充分，或与客户的期望产生差异。
　　2.软件需求的重要性
　　对于软件开发工作来说，其原始驱动力来自于用户的需求，而非软件开发技术本身。软件或信息系统只是辅助人们完成某项工作任务的工具，必须依靠使用者告诉它要做什么和怎么做，且每一细节规则的定义必须是明确具体的，才能使整个信息系统正常运转起来。因此软件需求是软件开发工作的一个最重要的输入。
　　在判断一个软件项目是否成功时，一般从以下几方面来衡量：
　　（1）项目是否达到预期目标；
　　（2）项目的实施是否使工作效率得到提升；
　　（3）软件的使用者是否有良好的感受；
　　（4）项目成本和工期是否控制在计划之内。
　　从以上几点不难看出，要在这几方面取得理想成果，项目需求将是一个关键因素：
　　（1）项目范围和需求的定义要明确清晰；
　　（2）对利于工作效率提升的需求能够得到充分挖掘和体现；
　　（3）需求应能全面真实体现出各个层面软件使用者的诉求；
　　（4）项目建设过程中能够对需求变更实施有效控制。
　　3.主要需求风险识别
　　既然需求对软件项目的成败起到如此关键之作用，对需求风险的控制就变得尤为重要了。在应用软件开发过程中，由于软件需求本身的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致软件开发的失败，这种可能性称为需求风险。总结以往企业信息化项目实施过程中遇到的需求问题，大致可将需求风险归纳为如下几种类型。
　　（1）需求频繁变更，项目范围被随意扩大，导致项目的成本费用增加、开发周期延长、开发质量和工作效率下降；
　　（2）缺乏明确的部门或人来真正对需求负责，造成业务需求缺乏规划，需求的片面性和矛盾性比较突出，需求质量受到需求提出者个人能力的影响；
　　（3）受专业领域所限，技术人员和业务人员在沟通上存在着一些障碍，双方都用自己的方式和专业术语进行交流，使最终开发人员理解的需求与业务人员的初衷存在差异，导致开发出的系统与用户的期望不符；
　　（4）开发人员将兴趣点更多放在技术产品和程序编码上，对需求分析工作的关注度和精力投入不足，在拿到一些尚未描述清晰具体的需求后，草草投入程序开发，对不明之处以自己的理解来代替，同样造成了实际系统与用户期望不符；
　　（5）业务人员对项目初期的需求确认缺乏足够重视，往往等到系统上线后才提出各种问题，严重影响了项目的实施效果。
　　需求风险成因分析
　　造成需求风险的原因是多种多样的，包括人的问题、历史遗留问题、管理问题等。笔者结合电信企业在IT项目建设中遇到的典型需求问题，总结出如下几点需求风险成因。
　　1.人员和职责分工问题
　　软件需求来源于软件使用者，是对人的心理期望的具体体现，因此在进行需求收集时能否找到最理想的需求提供者是至关重要的。对企业信息化项目来说，信息化需求应是对企业管理者管理思想的体现，这样做出来的系统才能对提升企业竞争力起到积极作用。然而，目前在企业内部由于在部门机构划分上采取的是条块状分割的组织架构，每个部门只从自己所负责的工作出发考虑需求，甚至是需求提供者只从自身工作便利角度出发提出需求，造成不同来源的需求之间存在着矛盾，需求质量很大程度上受需求提供者个人水平的影响。对于这些纷杂需求的取舍也缺乏某个主管部门去裁决，往往只能由信息技术部门出面去推动相关单位协商解决，其难度是相当大的，造成需求长时间无法确定，严重影响了项目整体进度。
　　另一方面，业务和技术人员之间天然存在着一条认知上的“鸿沟”，彼此缺乏对对方领域的了解，从企业层面缺少一批既懂业务又懂技术的复合型人才来整体把握业务和技术的平衡点。业务人员不理解为什么实现一个需求要花费那么长时间，为什么他们提出的需求经常会被技术人员压缩或拒绝；技术人员面对需求首要考虑的是实现这个需求是否需要对系统进行较大改动，是否会给系统的性能和稳定性带来负面影响。技术人员往往习惯于按照自己的思路对需求的必要性产生疑问，并暗自嘲笑业务人员对信息系统一无所知。正是由于进行需求沟通的双方人员彼此缺乏共同语言和相互了解，致使对需求的理解很难达到共识。寻找技术加业务的复合型人才充当中间人角色的难度又是相当大的，具备此能力的人可以说是凤毛麟角，且需要一段较长时间的培养。
　　2.业务驱动力问题
　　企业信息化项目的源动力来自于企业为寻求自身进一步发展，而对信息技术的一种迫切需要。在发达国家信息化需求非常旺盛，企业员工普遍具有很强的信息化意识，人们投入信息化项目的热情和精力普遍较高，致使项目的需求质量较理想；反观国内企业，人们受思维和行为惯性的影响，对传统工作方式难以形成突破，很多人已经习惯于长期以来采取的手工工作方式和信息获取方式，加之人力成本的低廉，使得人们对借助信息系统改善工作状况的愿望并不十分强烈，造成一些会对提升工作效率有显着成效的信息化点没能被充分挖掘出来，从而使项目收益大打折扣。
　　另一方面，从企业自身发展水平来看，业务和管理活动本身在规范性和精细化程度上尚有待提高，信息化所依赖的基础环境尚处在一个较低水平线上，这在一定程度上也降低了信息化需求的质量。
　　3.市场竞争环境问题
　　当今电信企业仍处于激烈的市场竞争年代，激烈竞争带来的是一系列不合常规的行为和需求，原有的秩序和规范在某些情况下不得不被打破，从而在一定程度上对软件项目建设造成了冲击，例如需求频繁变更、开发时间被大幅度压缩、规范化流程无法正常执行等。
　　对需求风险的控制策略
　　通过以上对信息化项目所蕴含的需求风险的分析，我们可以看到这些风险的存在是无法避免的，要想彻底消除风险是不可能的。但我们可以通过采取一些必要措施将需求风险尽可能降低至可接受的水平。针对上面谈到的那些典型需求风险，我们通常可考虑从以下3个方面入手实施风险控制。
　　1.对需求变更的控制
　　在项目实施过程中发生需求变更是不可避免的，并且一定程度的需求变更也是合理的。对于项目管理者来说，要试图彻底阻止需求变更的发生是不现实的，事实证明这种努力都是徒劳的。对需求变更实施控制的目的是要尽量降低变更发生的频度和变更对项目造成的不良影响。通常会采取以下几种措施来实施需求变更控制。
　　（1）建立项目需求变更管理流程，由开发人员和需求人员共同组成需求评审组，对变更　　需求进行严格评审，同时要使所有人员清楚变更的代价会有多大；
　　（2）需求确定后，要建立明确的需求基线，并敦促业务人员要对需求确认这个环节的工作给予高度重视，以正式文件形式发送至业务部门签署确认意见；
　　（3）与业务人员一起对变更的需求建立优先级，采取分批方式逐步实现，并注意确保核心模块的相对稳定；
　　（4）在与业务人员的沟通中注意讲求沟通技巧，对业务人员提出的变更需求尽量通过各种方式给予巧妙地引导，通过向业务人员推荐其他可行的方案来对即将发生的需求变更进行转化。
　　2.对需求质量的控制
　　对需求质量控制的关键是要保证找到理想的需求调研对象。通过前面的分析可以看出，需求调研对象的角色、个人经验和能力将直接影响到需求的全面性、有效性和合理性。由于信息系统面向的是各个层面的使用者，因此在选择调研对象时应首先将需求按使用者的不同进行分类，针对各类需求选择最具代表性的人物来访谈。同时针对不同类型的调研对象，应注意采取适合的访谈方式，并在提问时给予必要的引导。例如在访谈管理者时，他们通常会提供一些比较原则性的、抽象的、方向目标一类的需求信息，而对要实现的具体功能考虑不足。而对于操作人员来说，他们往往一上来就直接提出非常具体的细节化的需求，缺乏对目的和整体体系的描述，使需求收集人员看不清方向。这就要求访谈人员根据这些特点向被访谈者提出引导性的、有针对性的问题，启发他们对忽略的需求点做出考虑，这样才能保证收集到的需求信息是完整的。
　　另一方面，开发人员可以根据以往项目积累的经验，提出一个比较成熟的原型需求，交给业务人员进行确认，在此基础上进行一些必要的取舍，这样做一方面可以使需求质量有一定保证，在一定程度上弥补了业务人员个体上的局限性；另一方面也可大大缩短需求调研阶段花费的时间，同时有效降低系统定制开发的工作量。
　　对需求理解差异的控制
　　由于业务人员和技术人员在专业背景上的不同造成对需求理解上存在差异，是导致项目返工和实施效果不理想的重要因素。要尽可能减小差异量，就需要双方对需求的沟通要尽可能充分。特别是开发人员，在进行需求调研时要注意多主动提问题，对不清楚的地方一定要反复确认，直到搞明白为止，切不可含糊过关。在讨论需求时，应尽量要求业务人员采取举例方式阐述需求，并将例子详细记录在调研文档中。此外，针对不同业务领域，可指定业务部门有经验的代表全程参与项目建设过程，随时进行需求沟通，及时消除在需求上的误解。
　　另一方面，在项目实施过程中，可采取分阶段确认的跌代开发模式，将整个项目的开发过程分成若干小的阶段，每个阶段开发完毕后就立即交给业务部门进行测试和确认，及时发现问题及时改进，从而避免整个系统开发完毕后再发生大的返工。
　　结束语
　　总之，由于软件自身特点决定了企业信息化软件开发项目天然存在着可能导致项目失败的各种风险。软件需求对软件开发质量的影响也决定了，对需求风险的控制是关系项目成败与否的关键环节。根据典型需求风险的种类，我们可以分别从需求变更、需求质量和需求认知三方面入手实施必要的风险控制策略，其结果是可以有效降低由于需求问题导致项目失败的机率。天津移动在2005年的BOSS1.5工程项目建设中由于实施了有针对性的需求风险控制策略，从而在中国移动31个省中率先完成了新旧系统的割接，取得了整个项目的圆满成功。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。