基于软件需求管理的风险研究-20160419

1、基于软件需求管理的风险研究学生姓名： 学 号：学 院：专 业： 指导教师： 论文成绩： 内 容 摘 要随着互联网的发展，各行各业对软件系统的需求愈来愈复杂，规模愈来愈大，从最初的纸质化转为电子化的发展，到现在的大数据分析的信息化的发展。并且随着企业的发展，工作过程重组，需求管理也越来越成为必然。需求管理是软件项目管理的基础，也是决定软件项目成功的关键。而软件需求的不确定性产生软件项目的高风险，对于软件需求造成的系统风险，需要进行风险管理。而风险管理是项目管理中的重要部分，通过对软件项目需求的风险管理，减少风险的损失，从而实现软件项目的科学管理方法。本论文从风险管理的风险识别、风险分析、风险应对

2、和风险监控几个方面入手，分析研究了训练系统中需求风险管理和控制的方法。关键字：需求管理 风险管理 风险识别 风险分析 风险应对 风险监控 训练系统ABSTRACTWith the development of the Internet, all walks of life demand of the software system becomes more and more complicated, the scale is getting bigger, from the original paper turn to electronic development to today's

3、 big data analysis of informatization development. And with the development of enterprises, the restructuring of the work process, demand management has become increasingly inevitable. Demand management is the foundation of software project management, and it is also the key to the success of softwa

4、re project. The uncertainty of the software needs to produce the high risk of the software project, the system risk caused by the software requirements, the need for risk management. And risk management is an important part of project management, through the risk management of software project requi

5、rements, to reduce the risk of loss, so as to realize the scientific management of software project. This article from the risk management of risk identification, risk analysis, risk response and risk control aspects of the analysis of the need for risk management and control of the training system.

6、KEY WORDS：Demand management risk management risk identification risk analysis risk response risk monitoring training system23目 录第一章 绪论1（一）研究背景和意义1（二）国内外研究现状2（三）研究内容和方法2第二章 相关理论概述4（一）风险相关理论4（二）项目风险管理相关理论5（三）软件需求管理相关概念6（四）软件需求和风险管理的关系7（五）国内外软件项目需求风险研究综述8第三章 XX系统及其需求风险控制9（一）XX系统概述及特点9（二）项目需求的风险识别10（三）项

7、目需求的风险分析14（四）项目需求的风险控制14（五）项目需求的风险监控17第四章 项目需求管理中风险管理的心得体会19（一）项目需求管理中风险管理中的实践及感悟19（二）项目需求管理中对项目风险管理的启示19第五章 总结19（一）论文总结19（二）论文的局限于不足19参考文献20基于软件需求管理的风险研究基于软件需求管理的风险研究第一章 绪论（一）研究背景和意义自20世纪80年代以来，我国软件产业呈现出迅猛、广泛、深化的发展趋势，而全球范围内经济和社会的信息化发展，更催化了市场对软件产品的巨大需求。软件产品作为一种逻辑产品，是人类思维的创造物，其更替速度比传统领域要迅速的多。随着软件产品规模

8、的不断增长，软件的复杂性也不断提高。复杂软件系统在国防、通信、航空航天、大型计算机等领域，以及证券、医疗、金融等国民经济领域上的应用，更使得软件产品成为人们生活中必不可少的重要组成部分。对软件产品依赖程度的加大一方面方便了人们的生活，另一方面也使得软件产品的质量直接关系到人们的生活、财产甚至是生命安全。因此，在软件开发过程中影响软件产品质量的问题也引起了普遍关注。国际化标准组织ISO中定义软件质量为“反映软件产品满足规定需求和潜在需求能力的特征和特性的组合”。由此可知，衡量软件质量标准的根本在于软件是否能满足用户的需求，在多大程度上满足用户的需求。软件需求与软件质量息息相关，对软件需求管理的好

9、坏也将直接影响到软件项目开发的进度、预算、质量，甚至是软件项目开发的成败。软件需求是软件工程中的重要环节，是软件设计的基础，也是用户于软件工程人员之间的桥梁。作为软件开发的源头，需求定义和限制了软件产品最终实现的要求。但是，软件产品的抽象性、高度复杂性使得软件产品的需求同传统产品相比具有更多的不确定性、变化性、主观性和模糊性。软件开发过程中存在大量与软件需求相关的问题。对软件项目实践的统计数据表明：大多数导致软件项目失败的原因并不是软件开发的技术问题，而是管理问题，其中尤以需求管理的问题最为突出。软件需求管理的难度是由需求本身的特点造成的。软件需求的一个重要特征就是“不确定性”，这些不确定性可

10、能导致项目失败、费用超标、开发周期延长、产品功能不完整等后果。对不确定要素造成的损失进行预测，并根据预测的结果选择合适的管理方法和技术方法降低不确定带来的损失，成为风险管理。而风险管理是项目管理中最重要的任务，是因为项目的确定性和常规性的工作及其管理都是程序化和结构化的管理问题，它们所需的管理力度十分有限；项目风险是一种带来损失的可能性，如果不管理或管理不当就会造成损失；反之，项目风险还包含机会成分，如果能够很好地开发和管理将会有效地提升项目的成功度。而对软件项目需求管理的风险研究，就是找出这些导致不良后果的风险，并使其对产品的不良影响最小化。（二）国内外研究现状1.国外研究现状根据美国专门从

11、事IT项目实施效果跟踪的权威机构Standish Group的；CHAOS报告：2003年，在所调查的IT项目中，彻底失败的项目占调查总数的15%，还有超过50%的项目因为质量原因受到不同程度的质疑；2004年的调查显示，绝对成功的IT项目占调查总数的29%，彻底失败的占到了18%。CHAOS的报告分析还指出：导致这些项目失败和质量问题的最主要原因都与需求相关；仅有20%的软件项目能够在预定工期内完成，其主要原因也是非预期的需求变更，尤其是需求形态的变化和新需求的增加。2.国内研究现状目前国内很多的软件企业，在提供IT整体解决方案的项目中不太关心对项目进行需求风险管理，结果导致项目延期、超支、

12、甚至失败的情况比比皆是。随着信息时代的发展，计算机软件的需求愈来愈复杂，规模愈来愈大，而且随着企业的发展，工作过程重组，需求管理已愈来愈成为必然。软件危机持续了30年之久，至今仍无法得以很好地解决。究其原因，与软件本身的特点固然有关，但长期以来，缺乏对软件开发和维护的正确方法以及忽视软件开发过程的质量控制仍是最为关键的原因。其中软件开发和维护的方法的不正确性主要体现在：1) 忽视软件开发前期的需求调研及分析；2) 开发过程缺乏统一的、规范化的方法指导；3) 文档资料不齐全或不准确；4) 忽视与用户之间、开发组成员之间的交流；5) 忽视测试的重要性；6) 不重视维护或由于上述原因造成维护工作的困

13、难。这样，就经常出现用户对“已完成”系统不满意，软件产品的质量经常出现漏洞，补丁一大堆。（三）研究内容和方法最近几年，不论是软件开发的技术和工具，还是对软件项目进行项目管理的水平都取得了较大的进步，但是由于软件项目管理和一般项目管理不同，往往存在着很大的不确定性，直接影响着项目的顺利完成。控制软件项目的风险是软件项目管理的重要组成部分。目前的软件风险管理方法存在着一些不足，在软件项目管理实践中不能取得最佳效果。本文通过对软件产品开发中资源、用户需求和产品之间的内在关系的分析，提出了基于用户需求的软件项目风险管理。在收集相关材料之后，依据科学的研究原则，通过对资料的深入细致研究，最后形成本论文的

14、内容框架。图1 本文内容框架第二章 相关理论概述（一）风险相关理论1.风险风险，是某些不确定性以及由其可能引起的偏离预定目标的不良后果的综合。风险包含三个主要特点：（1）不确定性。风险的本质是不确定性，这种特性表现于多个未来的不良后果及其发生的可能性。（2）后果的客观性。当一种后果已经成为现实，或一项活动已结束，风险也就不存在了。（3）风险的可控制性。在我们周围存在大量的风险，人们试图评估它或者控制它，有些控制是成功，但有些控制是失败的。人们可以通过风险发生的一些规律制定一些对应方案从而达到对风险进行控制。2.项目风险项目风险是指在项目生命周期内，由于某些不确定性可能导致项目偏离目标，造成项目

15、损失的风险。美国项目管理大师马克思·怀德曼将其定义为某一时间发生给项目目标带来不利影响的可能性。项目风险具有以下特征：（1）客观性。在项目的全寿命周期内，项目风险是无处不在，无时没有的，风险的存在决定于风险的各种因素的存在，只要决定风险的各种因素都达到发生风险的要求，风险就会发生。虽然人类一直希望能认识和控制风险，但直到现在也只能在一定的条件下适当改变项目风险存在和发生的条件，降低其发生的概率，减少损失程度，要完全消除所有风险是不可能的。（2）偶然性和规律性。风险具有不确定性，任何一种风险的发生，都是由许多条件和不确定性因素相互作用的结果，是一种随机现象。个别风险事件的发生是偶然的、

16、无规律的，但是通过对大量风险事件资料的统计分析，我们可以从中找到其发生的规律，也就是说我们可以利用概率统计的方法来描述具有随机不确定性的风险的发生规律，并在此基础上进行风险管理。（3）多样性。一般情况下，比较大型的项目实施周期长、规模大、涉及范围广，风险因素数量和种类多，导致大型项目在项目全寿命周期内面临的风险种类多种多样，如质量、技术、时间、成本等各种风险。（二）项目风险管理相关理论项目风险管理是指项目承担单位对项目全寿命周期内可能遇到的风险进行预测、识别、分析、评估，并在此基础上采取措施，提出对策，减少风险的损失，从而实现项目目标的科学管理方法。项目管理知识体系（Project Manag

17、ement Body of Knowledge，PMBOK）中告诉我们：项目的风险管理是对项目风险从识别到分析乃至采取应对措施等一系列过程，它包括将积极因素所产生的影响最大化和使消极因素产生影响最小化两方面内容，风险管理包括四方面内容：1. 风险识别风险识别是是指在风险事故发生之前，人们运用各种方法系统的、连续的认识所面临的各种风险以及分析风险事故发生的潜在原因。风险识别风险管理的第一步，也是风险管理的基础。只有在正确识别出自身所面临的风险的基础上，人们才能够主动选择适当有效的方法进行风险处理。风险识别的主要任务是确定项目风险来源、风险产生的条件、描述风险特征和确定哪些风险条件有可能影响到本项

18、目。2. 风险分析风险分析有狭义和广义两种，狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险，开发、选择和管理方案来解决这些风险的有组织的手段。风险分析是对风险影响后后果进行风险评估和风险之间的相互作用，以便评定可能结果范围。3. 风险应对风险应对是指在确定了决策的主体经营活动中存在的风险，并分析出风险概率机器风险影响程度的基础上，根据风险性质和决策主体对风险的承受能力而制定的回避、承受、降低或者分担风险等相应防范计划。风险应对过程的活动是以求将风险降至可接受程度。4. 风险监控风险监控是指在决策主体

19、的运行过程中，对风险的发展与变化情况进行全程监督，并根据需要进行应对策略的调整。因为风险是随着内部外部环境的变化而变化的，它们在决策主体经营活动的推进过程中可能会增大或者衰退乃至消失，也可能由于环境的变化又生成新的风险。风险监控是跟踪已经识别的风险，完成风险管理计划，可根据项目执行情况、已出现的风险和可能风险，对风险进行计划调整，保证风险管理计划的实施，并评估削减风险的效果。（三）软件需求管理相关概念 1.软件需求的概念。软件需求，是（1）用户解决问题或达到目标所需条件或权能。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。（3）反应以上两点所描述的条件或权能

20、的文档说明。它包括功能性需求及非功能性需求。软件需求包括三个不同的层次，即业务需求、用户需求和功能需求，也包括非功能需求。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明；用户需求文档描述了用户使用茶品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明；功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。2.软件需求管理的重要性。在软件项目的开发中，要想让项目取得成功，就应该充分的理解和满足用户的开发要求，如果不进行需求管理，就很难达到客户的项目要求，设计出来的软件不是用户想要的那种，自然就会降低项目获得成

21、功的机率。需求管理是软件开发的第一步，也是最难走的一步，需求管理的好坏关系着软件的好坏，甚至影响到软件项目的成败。从某种意义上来说，软件行业和一般的生产行业有异曲同工之处，它们的性质都是为了更好的满足消费者的需求掌握市场的最新动向。但软件和传统的生产企业还是有所区别，生产企业的需求管理是具体地、可直接描述的，而软件是一种看不见摸不着的商品，它是无形的，因此它是需求管理具有模糊性、难以确定性。软件行业的需求管理比传统生产企业的需求管理更加重要，因为需求管理是软件行业的命脉，决定着软件项目的成功与否，需求管理不当会直接导致企业利益受损。因此，通过需求管理，建立和维护软件项目和用户需求之间的共识，要

22、求用户的需求要合理，充分的理解和满足用户的开发要求，确保软件项目满足用户需求，实现软件项目的成功。（四）软件需求和风险管理的关系软件项目是一项要求协同完成的任务，它关注一个系统的软件成分及其相连文档的分析、详细说明、设计、开发、测试和维护等工作。它根据用户需求分配资源来完成软件产品，用户需求作为项目的初始条件，引发资源的分配和使用，在软件过程结束后，资源转化为软件产品，项目中的资源包括：时间、技术、费用、软硬件、人力资源和软件过程，软件过程作为一种特殊的资源，分配和安排其他资源的使用。软件项目的不确定性导致项目高风险性，而软件需求不确定性更是造成这些不确定性最主要因素。软件需求对于软件是否能按

23、时交付和成功应用有着举足轻重影响。提高软件产品质量，必须对软件需求进行严格风险管理。即风险管理应该以用户需求为根据：1.有统计数据和研究报告证明，软件项目中的关键风险和需求有关；2.在软件项目实施过程，用户需求主导着项目中资源的分配和产品的生成，所以用户需求决定着软件项目的风险；3.从用户需求在软件项目中的地位来看，由于一切软件产品、软件项目都是为了满足用户需求而存在的，用户需求能够为软件风险管理指明方向；4.一般性经验证明，风险管理实施的越早，为风险付出的额外代价就越小，需求管理从软件项目的最早阶段开始贯穿于整个项目中，从用户需求出发进行风险管理可以实现最佳效果。因此，风险管理方法应该直接反

24、映对用户需求的管理。用户需求在软件项目风险管理中占据着很重要位置，关系着软件项目的成功与否。如下表所示：表1 判断软件项目是否成功的统计表成功的标准（风险度）权重成功的标准（风险度）权重用户的参与19高层管理的支持16明确的需求说明书123适当的计划编制11切合实际的预期10更小的项目里程碑9胜任的工作人员8所有权6清晰的前景和目标3努力工作、专注的工作人员3对于软件项目的用户需求和风险管理方法之间的关系研究目前还比较缺乏，对需求度量和需求风险管理进行了一些研究。但这些研究中的单纯的对需求度量的方法不足以支持在软件项目中进行准确的风险预测。软件项目风险管理方法应该以用户需求为基础，并应用其他软

25、件工程方法，才能在最大程度上保证软件产品满足用户的需求，实现软件项目的成功。（五）国内外软件项目需求风险研究综述由于软件需求本身的隐含性、用户于开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致软件开发的失败，这种可能性称为需求风险。关于需求风险的辨识、分析和控制，国内外很多学者进行了一系列的研究。1.国内研究付玉等讨论了需求风险的控制方法。王延明则采用了一些软计算的方法讨论了需求风险的评价问题。杨皎平等建立了软件需求风险的灰色模糊综合评价模型。黄蒙基于用户需求的软件项目风险管理模型从用户需求角度出发，通过软件过程技术、产品工程技术和度量技术的

26、支持可以有效地控制软件项目风险，保证了软件产品满足用户需求的能力，从而使软件项目达到成功。蒋海昌对降低软件需求分析风险进行了探索，通过对需求分析的风险探索了解到对于一个需求分析师，需要不断地积累需求开发、需求分析和设计经验，通过沟通、可行性分析、需求等级划分、需求范围界定、定期向用户决策层汇报、业务知识学习、提供系统原型、需求文档编写、数据分析、深入了解需求人员要求、建立需求评审机制和需求管理机制等方法可减少需求分析的缺陷、避免软件返工，以降低需求分析的风险。2.国外研究罗伯特格拉斯（2002）指出，需求不断变化是软件项目失败最主要的原因。The Standish Group Internat

27、ional,Inc.自1994年开始对IT项目的成功率进行统计研究，并发布了一系列题为“混沌（CHAOS）”的报告。导致许多项目失败的原因并不是缺乏资金或技术，而是缺乏成熟的项目风险管理；以及低估项目的复杂度和忽视需求变化带来的风险。基于需求风险对项目成败的重大影响，很多学者提出了需求风险管理的思路，实践上也出现了一些定性和定量分析风险的方法。Myers开发了一种用于帮助项目管理这今早识别在项目周期内引起需求风险原因的方法。Samson通过研究需求分析中潜在的问题来改进软件需求定义。Robinson开发了一种需求工程风险评价方法，这种方法可以包含需求错误类型和风险事件的定量信息。Romano指

28、出了怎样识别有潜在风险的需求的问题。由此，本文针对特定项目，研究其需求管理的风险控制，同时对XX系统项目提供一定的借鉴和参考。第三章 XX系统及其需求风险控制（一）XX系统概述及特点 根据总参谋部颁发“十二五”时期军事训练改革总体方案。为加快推进训练管理信息化建设，按照“正规化组训、标准化作业，精细化管理”的要求，依托军队现有信息化资源，建立覆盖某部各级的军事训练信息系统，实现训练组织网络化、监控管理实时化、辅助决策智能化、统计评估精确化。用户方组织力量深入基层调研论证，充分借鉴军内外信息化建设经验，研制XX系统。XX系统是针对用户单位教学、训练管理研发的一套信息化管理系统。通过信息化手段将训

29、练过程中的各类业务融为一体，具备全面获取信息、实施监控训练进度、客观分析训练绩效、自动管理训练数据、有效辅助训练决策等功能。依托军队网络建立覆盖用户方各单位的双向数据传输机制，自动汇总各单位的数据，通过直观的图形化方式进行展现，避免了因地域分布散、技术手段落后带来的训练管理难以“全程化、精细化、实时化”等问题，做到了“小的放大管，远的拉近管，散的集中管”。根据XX系统本身的特点，本文主要介绍我们在系统需求风险管理中如何面对、处理和解决出现的风险问题，在此基础上，为了处理需求中的各种风险，本文提出了对此系统的需求风险监控办法，以保证此项目的正常进行。软件项目是需求驱动典型，项目从立项、开发、测试

30、到交付，需求变化是正常的。需求变化控制不好，轻则严重拖延工期，重则导致项目失败。在系统设计和开发过程中，随着对系统需求理解的深入，客户可能对需求补充或扩展，都会引发需求变更。即便系统交付，客户在使用过程中仍然会对系统提出改进意见甚至增加新的功能。功能变更或增加的同时，给项目本身也带来一定风险。而在项目的整个寿命周期内，不同阶段的修改需求带来的费用成本是不一样。软件各阶段发现错误修复成本统计如图2所示。图2软件各阶段发现错误修复成本的统计（图例说明，需求阶段检查和修改一个错误所需的费用只有设计阶段的1/5，编码阶段的1/10，单元测试阶段的1/20，到了交付阶段则需要200倍的代价）从上图及说明

31、可以看出，在软件研发过程中，越到后面阶段修复错误的成本越高，而且往往是需求阶段成本的百倍。为了能够提供高质量产品给用户，更好地管理软件项目，管理好需求成为项目成功的关键，而XX系统将用户、开发人员和软件质量保障人员等紧密联系起来，协同工作，共同努力，从需求风险识别开始，然后对识别的需求风险进行分析，最后根据分析结果采取解决办法，最终达到降低项目需求风险的目的。（二）项目需求的风险识别风险识别常用方法有：德尔菲法（专家调查法）、头脑风暴法、鱼刺图（因果分析表）。而在XX系统开发中，常使用头脑风暴、专家调查，对计划、过程、需求评审等方式，形成包含业务、管理和技术等风险检查表，借此进行风险识别。同时

32、，以以往经验形成检查表中的风险项（如表2所示）。表2 需求检查表文档编号版本号密级软件需求检查单项目名称及版本号项目经理项目类别产品研发项目 客户定制或应用开发项目 实施项目 维护项目序号检查项是否不适用注释清晰性1对需求的描述是否易于理解？2是否存在有二义性的需求？3是否定义了术语表，对特定含义的术语给予了定义？4最终产品的每个特征是用唯一的术语描述的吗？组织和完整性1需求是否能为设计提供足够的基础？2是否包括了所有客户代表或系统的需求？3在需求中是否遗漏了必要的信息？如果有的话，是否标记为“待确定”的问题？4是否每个需求都在项目的范围内？与商业目标一致？5需求是否与一些业务限制、政策或规约

33、相冲突？6与组织机构或政策问题相关的需求是否与系统同的商业目标相冲突？7是否有的需求应该描述的更详细些？8是否定义了功能需求在内的算法？9是否识别了设计约束？10是否对假设条件进行了说明？一致性1所有需求的编写在细节上是否都一致？2对同一对象的术语定义存在矛盾吗？3对同一对象的特征描述存在矛盾吗？4是否多个需求相互冲突？可追踪性1需求是否具有明确的来源，从而它可能被跟踪？2是否每个需求都具有唯一性并且可以正确地被识别？可检验性1是否所有的需求都能实现？2是否每个需求都是可测试的？可修改性1每个需求描述是否清晰、符合逻辑？2组织结构是否合理、可接受？3是否每个需求都没有内容上和语法上的错误？4是

34、否有冗余的信息？接口1是否对用户界面进行了说明？2是否对硬件接口进行了说明？3是否对软件接口进行了说明？4是否对接口的设计约束进行了说明？5是否对接口的安全性需求进行了说明？6是否对接口的可维护性需求进行了说明？质量、性能属性1是否合理地定义了性能目标？2是否合理地确定了所有性能需求？如预期处理时间，数据传输速度等3是否合理地确定了安全与保密方面的需求？可靠性1是否描述了所有软件故障的原因和结果？2是否记录了所有可能的错误条件所产生的系统行为？3是否定义了防止故障或错误探查策略？4是否定义了修正策略？软硬件1是否指明了硬件需求如内存、硬盘空间等？2是否对要求的软件环境/操作系统进行了说明？3是

35、否说明了需要购买的软件？4是否给出了要求的或估计的网络吞吐率？5是否描述了将要使用的第三方软件、中间件的应用及其批准？特殊问题1是否所有需求都是名副其实的需求而不是设计实现方案？2是否确定了对时间要求很高的功能并且定义了它们的时间标准？3使用实例是否是独立的分散任务？4使用实例是否处于抽象级别上？而不是详细的情节？5使用实例中是否记录了所有可能的可选过程？6使用实例中是否记录了所有可能的例外条件？7使用实例中的每一个操作和步骤是否都与所执行的任务相匹配？8使用实例中定义的每个过程是否都是可行的？可验证？得分=“是”的项数/（总项数-“不适用”的项数）X100 通过风险识别方法进行风险识别后，X

36、X系统中存在以下问题:1. XX系统具有常规软件存在的问题（1） 开发进度难以控制。（2） 质量难以控制。（3） 软件修正以及维护困难。（4） 软件工作量的准确度难以实现，进度难以把握，成本高，且复杂度随规模增大指数增加。这不仅是技术问题，更是管理问题。2. XX系统本身特有的问题（1） 开发人员缺乏与用户决策层深层次交流，对需求延伸性把握不好。（2） 用户参与不足，沟通少，需求把握不准确，导致工作前期设计和后期使用截然不同。（3） 在开发过程中用户随时可能出现新的需求，或者业务发生变化，系统只能不断增加投入，或者系统根本无法按时投入正常使用。（4） 用户需求和流程在系统完善进步中逐渐清晰，软

37、件实现也需要随时跟进。（5） 前期无此需求，后期增加，系统考虑的兼容性不够，严重影响系统可靠性。XX系统不仅有通用软件固有问题，也有本身特有问题。系统要求一定要做好需求分析。整个需求阶段要把系统中所有相关环节的风险，在系统初期风险计划中体现出来。并对在风险检查表中已识别的风险分配优先级，初步给出风险分析和解决或降低风险的策略。（三）项目需求的风险分析有资料研究表明，系统故障的44.1%是在规格说明阶段出现的。79.6%的接口故障和20.4%的实现故障是因为不完备或者遗漏的需求所致。还有资料表明，8.12%的故障归咎于功能需求中的问题，认为危害最大的是那些最早进入系统，而最后才被除掉的错误。因此

38、，花时间加深对于问题及其背景的理解，并在第一时间明确并完善需求是值得的。在软件项目XX系统中需求通常包括用户需求、项目需求和技术需求。其中，用户需求和项目需求是需求分析基础；而技术需求除了功能需求外，包括可靠性、可用性、安全性、操作性、可移植性等非功能需求。除了在项目内人员、物资和技术上保证外，还需要在实际分析过程中，通过需求分析方法的使用、文档的建立和管理、与用户间交流方式的选择和应用等，切实掌握用户各方面需求信息。在整个阶段最主要的风险有：用户不能提供足够资料和信息或者用户不能准确描述需求；用户对需求没有给出承诺，以后会经常修改；未挖掘用户核心需求，或没有深入理解需求，导致需求频繁变动；需

39、求文档不能准确完整地描述用户需求，不能作为测试人员的测试输入。同一体制内，不同用户对于同一功能的需求不一致，甚至相冲突。在需求管理全过程中，不仅要对文档进行严格管理，而且做到清晰明了，对所涉及的风险项目进行影响分析并采用全过程跟踪方式，定期完成状态更新。（四）项目需求的风险控制为了更好的控制整个系统风险，为软件开发提供质量保证，将需求工作分为三部分：需求开发、需求管理和需求验证。需求开发工作主要针对需求获取、分析和编写相关文档；需求管理主要包括需求变更，需求跟踪和配置管理工作；需求验证包括评审、测试，让获得的需求得到有关人员认可。在XX系统需求管理实践中，采用以下方式控制需求风险的相关过程。1

40、. 需求开发过程（1）首先，对需求进行确认。即需要确定系统用户、项目范围、工作流程和过程场景、确定需求重用等；同时，针对质量属性和一些非功能需求，进行研究确认；通过与用户交流、阅读用户工作文档、了解用户当前工作内容等方式进行需求确认。（2）其次，绘制需求各类图。通过需求分析方法绘制系统组织结构图、接口连接图、数据流图、实体关系图、状态转换图、时序图等，通过软件工程化方法中的原型开发技术进一步完善需求；对系统进行可行性分析；采用质量功能展开技术，对应一定的完成阶段，将产品功能、性能和用户需求紧密联系，对需求进行优先级分类。（3）然后，将所有分析的结果，采用文档方式进行记录并确认，包括需求定义表和

41、软件需求规格说明书（需求定义表，是面向软件用户，有关用户需要完成的事情，包括使用环境、约束、监控和转换等；而需求规格说明则面向技术人员，将需求描述成为系统构建和运转）。在实施过程中，需求定义表中需求和需求规格说明中的需求必须有直接对应关系，以便于对今后实现的系统是否满足需求进行跟踪，同时也为工作量估算及实现难度提供了定量依据；同时需求定义可以作为用户验收依据，而规格说明则可以作为系统测试的准则。需求和软件产品横向跟踪如图3所示。图3 需求和产品横向跟踪（6） 最后，完成对需求的冲突、技术难点及设备需求等的可行性分析。2. 需求管理过程通过需求的三部分工作内容进行需求过程管理；需求管理过程流程图

42、，如图4所示。图4 需求管理过程流程图（1） 通过对用户需求调查，经需求分析形成需求规格说明和需求定义。（2） 获取用户或使用方的需求确认。（3） 管理需求的变更。通过需求跟踪矩阵来维护需求的可跟踪性，确保系统在计划、产品和需求方面不会出现不一致。（4） 针对文档的最终确认和有影响的需求变更，完成需求评审；将需求作为测试计划的输入，验证需求是否完全符合用户要求。定期对产品或文档进行审查，对系统流程和工作状况进行验证。（五）项目需求的风险监控风险监控采用审核检查法、监视单、项目风险报告、费用偏差分析表等方法，利用直方图、因果分析图、帕累托图等工具直观体现。在系统管理过程中，为了弥补软件测试工作的

43、不足，成立过程与产品质量保证小组，主要完成软件项目的第三方审计和过程审计，防患于未然。1. 需求阶段的产品审计产品质量保证小组对需求的正确性、一致性、无二义性、组织和完整性、可检验性、可测试性、可跟踪性、可修改性等通过检查单方式确认，以保证能够正确研发系统。针对用户需求采用5W1H方法，明确是否正确反映用户意图。进行需求文档检查，即对需求分析人员提供的文档或者原型以完整性、正确性和可行性为基础进行严格评审；需求确认记录检查和需求不符合项报告。2. 需求阶段过程审计（1） 对于需求变更的管理采用制定有关系统需求变更流程体系文件，并严格执行。（2） 采用需求变更7步法进行需求变更流程管理，具体内容

44、如下：第一步，变更申请。对客户口述、电话、当面交流进行记录，确认变更的必要性；第二步，评价工期、成本、质量等对系统的影响，对变更需求进行细化、量化和图形化；第三步，评价变更需求对于不同项目阶段的影响，主要针对项目稳定性、可靠性、安全性、测试性、缺陷密度等方面进行研究；第四步，对变更需求对项目带来的风险进行风险分析，主要对人员、效率、变数等方面进行分析；第五步，估算需求变更带来的人员、工时等人力成本及材料、软硬件、差旅、调研等非人力成本；第六步，进行技术评审；第七步，记录变更决定并登记变更记录。（3） 需求风险控制方法对于需求的风险控制，可采用的控制方法有： 要求用户签署文件，达到控制需求变化的

45、目的； 对变更进行可行性分析，评估每次变更的成本及风险； 使用专家参与等方式有效控制需求变更； 受影响的组（系统测试组、软件工程组、系统工程组、质量保证组、配置管理组合文档支持组）均参与变更评审； 进行有效的配置管理； 变更后，重新完成测试。（4） 检查需求的可追踪性一旦发生需求变更，则产品的计划、产品研发和活动将随之变更。产品质量保障组采用需求和产品横向跟踪图来检查分配需求在各个阶段状态。确保需求定义中的文档可以追踪到规格说明及后期的设计文件和测试文件中；对每种需求评审、设计、测试等更新计划安排，同时完成跟踪；检查测试用例的变更情况及完整性。（5） 定期进行状态评审重新评估各需求的进展及状态

46、，对需求在各阶段的优先情况重新划分，并完成评审；定期对于风险计划中的风险项目重新评估其风险、概率及影响。（6） 定量评估对需求准确性进行定量评估的方法；根据需求的改变次数和规模可以按照需求类型来统计，有助于确定需求变更是否集中于特定类型的需求上；同时，将需求提供给设计人员和测试人员，就需求的理解程度（完全理解，部分新/可借鉴；全新/可以理解；不理解/不肯定；不理解/肯定不行等）进行打分，如果变更需求集中居多，则需要重新修订需求。定期对于需求变更的范围、强度和频度进行评估。产品质量保障组定期对风险计划、项目监控数据及项目进展情况进行报告，对风险系统较高的提交优先处理；对风险管理过程文档（包括风险

47、检查表和风险管理报告）完成配置管理产品质量保障组进行同步监控和跟踪管理。需求分析阶段是系统建设中任务最繁重，也是难度最大的阶段。在XX系统中，采用各种协同工作方式，经过系统工程组、质量保证组及相关人员的共同努力，降低软件需求分析的风险，就是为了能够用系统前期的辛苦工作换取软件可靠性的提高。由于对软件能力成熟度模型的摸索中，系统中实现风险管理依然处于起步阶段，对于需求风险的定量分析等工作需要以后进一步探索和加强。第四章 项目需求管理中风险管理的心得体会（一）项目需求管理中风险管理中的实践及感悟从XX系统需求开发、管理和验证的三部分工作内容或工作步骤来讲，每一项工作的开始或完成都是一个风险管理的过

48、程，或是一个风险控制的过程。从识别出需求中的风险因素，到对这些因素的分析，找到对应这些风险因素控制的方案或降低这些风险因素的方法。虽然这个过程是复杂的，需求种类是多样的，但是风险管理的过程是明确的，在软件项目最初需求管理时，就做好风险管理，很大程度上已经保证了项目的成功。（二）项目需求管理中对项目风险管理的启示在软件项目的需求管理中，风险是多种多样的，是无处不在的。在项目管理活动中，要积极面对风险。越早识别风险、越早管理风险，就越有可能规避风险，或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目，应加强风险管理。如果不主动驾驭风险，就会面临风

49、险。第五章 总结（一）论文总结本文以XX系统需求管理中的风险管理为研究案例，以项目管理知识体系为基础，从XX系统需求的开发过程，到需求验证的整个过程进行研究分析，同时结合风险管理中各阶段应对解决办法，详细列举了XX系统在需求管理过程中可能发生的各种风险及风险发生的相关解决办法，然后提出了一套针对于XX系统需求管理的风险管理监控办法，以供大家借鉴或参考，希望能将项目需求管理中风险发生后的不利影响范围降到最低。通过本次论文的撰写，让我又重新梳理了整个项目管理知识体系，特别是对项目中的风险管理又有了新的认识，回想起自己在XX系统需求管理过程中的风险管理，往往都是遇到问题才去开始想处理办法，很少会有一个系统的风险管理规划，而且这也是当前需求管理中普遍存在的问题，通过这次学习，让我认识到了自己项目管理中的一些不足，在今后的学习和工作中会更加的注重和加强这方面的学习。（二）论文的局限于不足项目管理知识体系涉及的范围非常广泛，本文只是从风险管理的角度对需求管理中存在的一些问题进行分析研究，从而忽略了项目管理中的其他方面，比如时间管理、成本管理