论文摘要：由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。换句话说，需求管理就是:一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。需求管理是整个软件工程的管理的基拙，也是项目成功的关健所在。本文论述了软件项目中需求管理的重要性及存在的问题，并针对这些问题提出相关解决方法。本文选自《中国信息化》。《中国信息化》杂志由新闻出版总署正式批准、中华人民共和国工业和信息化部主管主办的一本国家批准创刊的唯一一份以关注工业化与信息化融合，推进信息化进程为使命的国家级信息化媒体国公开刊物。《中国信息化》杂志立足经济与社会发展大背景和信息化发展趋势，反映信息化实践，深度体现信息产业与信息化相互促进。主要面向和服务于政府信息化推进部门的决策层，重点领域应用机构的领导层，企业的CIO及管理层，信息化实施部门的主导层，以及关注信息化的专家、学者等。集思想性、知识性、可读性为一体的权威杂志传媒。
关键词：软件工程需求,管理软件项目,中国信息化
1背景
1.1需求管理的概念
理解需求管理的第一步就是对什么是需求管理达成共识。Rational把需求定义为“(正在构建的)系统必须符合的条件或具备的功能”。
由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。换句话说，需求管理就是:一种获取，组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
1.2需求管理在软件项目管理中的地位
简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。以下最近收集的证据很有说服力:StandishGroup从1994年到2001年的CHAOSReports证实，导致项目失败的最重要的原因与需求有关。2001年，StandishGroup的CHAOSReports报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，即这些项目不能按时按预算完成。其中提到最多的导致项目失败的原因就是“变更用户需求”。
在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，在软件项目管理中需求工程是软件开发的第一步，是关键的一步，也是最难把握的一步。需求管理做得好坏直接影响到软件的质量，甚至软件项目的成败。从软件的项目立项、研发、维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能、优化性能、提高用户友好性的要求。在项目管理过程中，项目经理经常面对用户的需求变更，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。
2需求管理现状
随着信息时代的发展，计算机软件的需求愈来愈复杂，规模愈来愈大，而且随着企业的发展，工作过程重组，需求变更已愈来愈成为必然。软件危机持续了30年之久，至今仍无法得以很好地解决。究其原因，软件本身具有的特点固然有关，但长期以来，缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关键的原因。其中软件开发和维护方法的不正确性主要体现在:忽视软件开发前期的需求分析;开发过程缺乏统一的、规范化的方法论的指导;文档资料不齐全或不准确;忽视与用户之间、开发组员之间的交流;忽视测试的重要性;不重视维护或由于上述原因造成维护工作的困难。
这样，就经常出现用户对“已完成”系统不满意，软件产品的质量经常出现漏洞，补丁一大堆。因此人们意识到以工程化的原则和方法组织软件开发工作是解决软件危机的一个主要出路。
需求分析作为软件生命周期的第一个阶段，并贯穿于整个软件生命周期，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域—需求工程。进人20世纪90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会(ISRE),1994年起，每两年举办一次需求工程国际会议(ICRE)。一些关于需求工程的工作小组相继成立。
3存在的问题
3.1需求描述的细致性问题
在文章的开头就说明了软件需求在整个软件系统开发中的重要性，正是由于它的重要性，一般来说，需求描述越详细越好。项目的开发方与用户在各种问题上的要求都是基本轮廓达到一致即可，具体的细节可以以后再填充，这是一种非常危险的思想。不管需求分析做的多么细致，以后对需求的变更都是必然的。另一方面，在需求分析阶段，开发人员希望再多投人一些时间，但是用户却不这么认为，因为需求阶段是软件系统开发首先要进人的阶段，离最终开发出可用的系统还有很长一段距离，这导致了双方的不一致。但如果在需求阶段投人很多时间，时间越长，可能的变化就越多，对设计的限制越严格，因此在需求描述的问题上，没有统一的界定，需要开发人员学会适当的把握。
3.2需求描述的正确性
软件开发是一种专业行为，一般的业主难以理解软件开发人员的开发理念。所以在和业主交流时，他们讲述的需求在实际中利用现有的技术是实现不了的，用户以为自己很清楚自己的需求了，但实际上他们只是依据当时的工作需求提出的。随着开发工作的不断进展，用户可能想到更多的功能和特色，进而对以前的需求进行改动，导致需求的不一致。
另外一种情况就是开发人员和业主交流时，由于业主本身对需求的描述不清晰，导致开发人员误解或曲解了业主最初的要求，最后开发出来的系统不是不能满足用户，就是一个发生需求错误的系统。事实上这种错误在需求阶段也会经常发生。更可怕的是，对于需求阶段出现的错误，如果在软件项目进行到后期的时候才发现，修复费用是非常可怕的，甚至会超出项目本身的费用。因此做好需求管理、减少需求错误的出现对于降低软件项目的成本是必要的，也是至关重要的。
3.3需求描述的完备性
系统的需求是层出不穷的，我们不可能做到把所有的需求都一一列举出来，并且随着时间的推进，用户的需求也会越来越多，要穷举需求是不可能做到的。另外，并不是用户提出的所有需求都要满足，在项目的最后，改变一个需求对整个项目的影响或损失很可能会超过需求本身给用户带来的益处。
3.4需求的变更
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变(ProjectScopeCreep)问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定程度时，双方才蓦然回首，发现已经物是人非，换了一番天地。
4解决问题的策略
4.1对需求文档版本控制
客户签收的所有过程文档都要作为基线确定下来，做好相关文档的管理工作。需求的基线是指是否容许需求变更的分界线，需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档，这个需求文档在通过需求评审后即可以建立第一个需求基线。此后每次需求变更并经过需求评审后，都要重新确定新的需求基线，以免将来用户需求发生变更时，原来的需求无法查找。为有效进行需求变更控制，必然要做的工作就是保存好各个版本的需求基线，维护需求基线文档，以备不时之需。
4.2正确认识需求变更
在软件开发过程中有这样一条真理:需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是一个变化的过程，需求的变更不一定是坏事，也有可能是好事。
变更的需求之所以变得难以管理，不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。管理变更包括建立基线，确定需要追踪的重要依赖关系，建立相关项之间的可追踪性，以及变更控制等活动。
需求变更贯穿了软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳人计划之中，在应对需求变更时可以更加的从容和有信心。
4.3管理需求变更
变更控制不应该只是软件开发过程应该考虑的事情，随着软件产品的开发和时间的推进，用户会提出越来越多的新需求，甚至在交付软件产品的最后阶段用户还会有不同的需求，因此需求变更的管理应贯穿于整个项目生命周期的全过程。
为了使变更对项目的影响降到最小，就应当采取合适有效的变更控制策略，确定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此流程。对需求的变更的处理应该分以下几个步骤:提出变更、变更评估、实施变更、监督变更过程。
4.4建立需求管理模型
需求建模是表达需求的一种形式，是对需求的一种描述与阐释，它使用标准的语言，利用类似积木的概念来建模，最大的好处是大家可以直接根据需求，轻易地反复修改需求模型。并且不会产生歧义，从而可以使大多数人快速地理解。
需求建模的目的是要消除人际沟通随意性很强的弱点，所以需要致力于将沟通标准化、自动化、准确化，而且责任到人负责的具体阶段。具有可测试、可验证性的特点。建模的过程就是通过需求的特点和要求进行分析，以建模标准为基础进行准确、完备和有效的阐述，以确保客户和开发方都能够明确无误地、通用的理解。
4.5与用户充分沟通
在需求管理过程中与用户的沟通很重要，因为它直接决定着最终软件产品是否满足客户的要求，即很大程度上决定着项目的成败。在沟通时，双方对需求的认识要一致，不能模棱两可。讨论需求及变更需求时，需求人员与客户及用户应该尽量采取协作的态度，良好的工作氛围也会提高工作效率，很难想象双方在“刁难”与“对付”的态度下是多糟糕的工作场景。确定需求基线的过程也是与客户用户交流的过程，而频繁大量的需求变更在很大程度上也是交流不充分的后果。所以，有效的充分的交流尤为重要，需求人员认真听取客户用户的要求，进行分析和整理，并最终取得用户的确认。
4.6利用需求管理工具
需求变更控制委员会可以采取商业化的需求管理工具，以此来在数据库中存储不同类型的需求。这些工具提供了对每项需求的属性描述、状态跟踪等，并可以在需求与其它的相关工作产品间建立跟踪能力联系链。
5结束语
需求管理是需求分析过程中的一个步骤，是一个持续的不断完善的过程，软件项目开发过程中需求管理的问题有很多，随时都有用户需求变更，需求分析的错误也时常发生，需求质量难以保，针对这些问题，如何采取有效的措施尽可能减少这些问题可能给项目造成的影响也显得尤其重要，另外关于需求的质量问题，怎样结合CMM标准进行需求的质量管理，有效提高软件的总体质量水平也是需要关注的问题。