论软件项目中需求管理的重要性

需求管理对软件项目的重要性

信息技术革命正以迅猛之势更新着我们生存的社会。信息技术不再仅作为一项独立技术而存在。各行各业中信息化手段与技术的采用越来越突出，软件需求量越来越大，与此蓬勃发展的软件产业前景相反的是，软件行业落后的生产方式无法满足目前信息化时代飞速增长的软件需要，大型信息系统的成功率持续低迷。

以计算机软件、集成电路技术为主导的信息技术革命正以迅猛之势更新着我们生存的社会，信息技术不再仅作为一项高科技技术而存在，而是广泛渗透于各个行业领域的生产、经营、管理等过程，成为它们发展的辅助手段和管理工具。

信息的采集、分析、处理、整合、发布是信息产业的核心内容，它们都离不开软件。软件是计算机的核心，信息社会需要众多功能灵活的软件系统。

但是，自20世纪60年代以后，全球软件行业落后的软件生产方式无法满足目前信息化时代飞速增长的软件需要，传统的软件开发方式与软件产品设计过程已不能满足当今对软件产品多样化的业务需要，从而导致软件开发与生命周期维护过程中出现一系列严重的问题。

所以我认为“软件项目中的需求管理”是软件项目成败的关键，对项目成败具有决定性的作用。以下将阐述软件项目中需求管理的重要性。

现阶段需求管理的问题主要体现在以下几个方面：

1.软件项目中范围、进度、成本估算准确率低。

软件项目开发的实际成本远远高出估算成本高出；同时实际进度比预期进度延后几个月甚至几年。这种现象降低了软件组织的信誉。

2.客户对最终交付产品满意度低。

软件开发人员在对用户需求未有清晰了解的基础上，对所面对的问题领域还没有确切分析与设计的情况下，即着手进行开发、编写程序。造成实际产品与客户期望功能产生偏离，无法解决客户的真实需求而造成客户满意度降低。

3.软件产品质量差强人意。

软件质量保证技术没有贯彻地采用到软件开发的过程中，这必会导致软件产品发生质量问题。缺乏审核、复审和全面测试的软件难免质量低下，出错率高。

4.软件不可维护、生命周期短。

软件程序中错误难以改正，出现新的需求或者需求变更时原有架构不易于维护，不能根据用户的新需求在原有架构中进行改变。造成软件的使用年限缩短，软件成本加深。

5.软件缺乏配套文档资料。

软件产品应具备整套文档资料。然而在进度与成本的制约下，文档的编写与更新工作也使得软件组织疲惫不堪，每个人对文档内容的深度与阐述程度不尽相同。加之企业缺乏与之配合的文档制度、文档模板，更为文档编写带来困难之处。而缺乏相关文档对软件的二

次开发与维护增加许多困难和问题。

6.系统集成项目中软件成本不断上升。

集成电路技术发展日趋成熟、生产自动化水平日益提高，使得硬件采购成本持续下降，但由于人力成本的增加，软件成本随着通货膨胀、软件规模、软件数量的不断扩大而逐年上升。

由此我们不难看出需求管理不善是软件危机的基本原因，这体现在以下几个方面：

1.在软件开发最终交付之前，客户自己也不清楚自身的真实需求；

2.加以需求人员技术有限，采集到存在遗漏、具有歧义性、误解的需求；

3.而在软件开发过程中，需求也在不断地变更；

4.需求管理人员没有更好的把握住需求的变化，造成后期维护成本不断增加，以致项目失败。

软件管理由于是新兴的门类学科，缺乏实践性较高的方法学和理论工具。软件开发不同于传统制造行业，软件开发过程是逻辑思维过程，软件产品的质量依赖于人员。综合性人才的缺乏也造成了现有软件开发模式无法适应现今的软件需求而造成了软件危机。

而现在软件开发规模持续变大，随着互联网时代的到来，软件从桌面走向网络，从小范围使用走向企业管理信息化，软件开发的规模越来越大。软件项目的开发工作不再是个人所能承担，不再是单一角色所能承担，而是需要组织一定的人力、不同的工作角色共

同完成。然而多数项目管理人才不熟悉软件开发方法，而软件开发人员又缺乏管理技能。项目中信息交流延迟、理解偏差、造成对项目最终目标的误解使得软件项目偏离轨道。软件开发项目开发人员不能有效地、独立自主地处理大型软件开发的全部关系和各个分支，因此容易产生疏漏和错误。

软件产品复杂度持续加深，规模的扩大必将带来结构上更为繁多的分支情况。传统的结构式分析方法已不再适用如今信息化的软件产品需求。软件开发工作也无法在一次迭代中完成，而是根据用户需求的优先级程序，客户共同协商，定制产品阶段性的交付周期。产品使用人数、实施规模都在随着信息化的发展而不断增加。这也使得软件使用场景不断增多，软件功能复杂度加深，对需求管理的迫切性也日益提高。

在此软件危机之下，新的软件开发方法不断地被挖掘与探索，以下六点被认为是解决软件危机，为客户研发良好系统的最佳软件实践：

1.迭代式开发：在软件开发的早期阶段就获取完整而精准的用户的真实需求是不可能的。这是因为随着项目的进展，客户对最终产品的需求在整个软件开发阶段会持续改变。现代软件开发所倡导的迭代式开发允许在每个迭代过程中需求可以发生变化，通过不断细化来加深对问题的理解。迭代式开发既可以降低后期交付的风险，也可以支持在每个迭代过程都产生可以交付的版本，提供给客户试用，即缓解了客户的等待性又可以产生积极的反馈信息激励开

发人员。

2.对需求进行管理：对客户业务建模的过程随着整个开发周期都是持续进行的，随着项目进入一个个迭代，新需求与变更需求都使得业务模型在不断的依据最新需求进行修改，指导着开发等后续工作。

3.采用组件式架构开发：组件是软件技术中重大的技术突破。组件使复用成为可能，系统的灵活性大大提高。基于高内聚、低耦合的模块化组件体系结构降低了管理复杂性，提高了代码重用率。

4.建立视觉模型：uml已逐渐成为软件工程师所广泛采纳的建模工具，软件从业者一致认为可视化的建模对需求管理有着重要的作用。客户和开发方都可以从中受益，尽早地获取有关软件结构和行为的信息，可以尽早地发现隐藏的风险。

5.对软件质量进行验证：软件质量测评不再是交付后或单独进行的活动，而是伴随着生命周期，从需求基线定义的那一刻起而持续进行的。

6.控制变更：对需求变更采用控制、跟踪、监控、修改的方式，在变更产生之初，判断其原因并确认涉及范围，进而采用合适的变更处理方法。积极地控制项目中所产生的变更，而不是被变更所控制。

需求管理的对软件项目的影响：

需求管理是随着软件产业的发展而逐渐成熟的，在软件业发展的早期，软件规模不大，软件产品开发所关注的是代码编写，产品

需求分析较少受到重视。在开发技术不再是软件产品的瓶颈时，客户对软件的需求日益复杂，软件产业出现生命周期这一概念，需求分析自然而然成为其初始阶段。

随着软件系统规模与信息化的发展，需求分析作为整个项目的基础，其定义的业务基准在整个软件项目中越来越重要，直接关系到项目的成功与否。

自1995年起的一项美国调查显示，通过对全美境内8000个软件项目的跟踪分析调查，与需求相关原因引起项目失败的比率高达45%，而这其中由于需求不明确，缺乏用户认可的需求基线而导致项目失败的原因占了25%。需求管理是项目范围管理的基础，只有明确的定义了用户需要哪些产品范围，才可以作为后期开发的前提。如果一开始就没有一个清晰的业务范围与业务模型，将会使后期的开发偏离轨道。

需求管理活动分为两部分，一部分属于需求开发，一部分属于需求管理：

1.需求开发是通过对客户及其所处行业进行调查与分析，捕获用户需求，并定义系统需求的过程。

2.需求管理是在客户与承建方之间建立对产品需求的一致认可，对需求管理方法与手段达成一致，并共同控制需求变更的过程。 需求开发又可再分为两个阶段：“业务分析”与“系统分析”。 需求管理又可再分为：需求确认、需求跟踪、需求变更控制。 需求确认是指项目甲方、乙方共同对需求文档进行审核，甲乙方对

需求基线达成一致后作出纸质协议，使得需求文档具有审核验收的作用效力。需求跟踪是指通过比较需求基线与项目最终产品之间的匹配关系，持续维护“需求跟踪矩阵”，确保产品依据客户所提出的需求进行开发。需求变更控制是指根据“变更提出-范围分析-方案选择-审核确认”的流程处理需求变更，确保项目中需求变更处于可控制的流程之下，而不至于失控导致项目失败。

软件项目同样遵循项目管理的一般原则，具有项目范围管理、进度管理、成本管理、质量管理、人力管理、沟通管理、风险管理、采购管理等过程。

需求管理大致上可以被认为是范围管理，需求管理所定义的软件功能基线决定了项目产品范围，明确指出了待开发的系统具有哪些功能，不具有哪些功能。需求管理定义的基线是甲乙双方共同遵守并为后续的工作提供基石。

只有以清晰的需求基线为基础，才可以在此之上制定进度管理计划，进行逐层任务分解。实现对进度的控制，并且可以在时间结点处依据需求基线进行小范围测试工作。在此之上，软件组织中的成本管理小组可以依据进度计划制定成本-绩效管理计划，根据员工的工作完成情况统计人员的绩效信息。这一切都是基于需求管理所定义的明确的需求基准。

实现了范围、进度、成本的动态管理，质量管理、人力管理、沟通管理才具有实际意义。软件质量保证小组可以依据需求基准对已完成的系统部件进行早期的跟踪测试；人力部门也可依据成本、

进度计划随时进行人力资源调整；清晰的需求基准减少了团队成员之间的矛盾，使得沟通变得简单有效。

需求管理所倡导的在早期准确的挖掘客户的需求可以使得项目人员尽早识别与发现项目中隐藏的风险，在项目早期减轻或者避免潜在风险。同时清晰的需求基线可以为组件产品采购带来判断标准。

综上所述，需求管理是有效实现项目管理各部分的基础，只有为项目打好一个坚实的基础，才可以顺利展开后续工作，实现客户与开发方的双赢。

需求管理的方法：

1.业务背景分析：业务背景分析可以通过了解客户的最初需要，提出概念解决方案来实现。它是为找出客户的真实需求而进行的分析、推理。在业务背景分析期间，将对“业务背景”和“项目干系人”等问题达成甲乙双方的一致。

2.初步需求建模：需求来自客户各个层面，比如来自客户决策层、管理层、执行层，第三方等。掌握如何准确判断需求的判断与来源，及如何接近这些来源并从中获取原始需求信息，在此之上，整合提取的原始需求，建立初始需求模型。

3.需求模型完善：进一步根据客户需求，整理待构建信息系统的明确的功能规格说明。在需求阶段对以下内容进行明确的定义与衡量标准：需求基线，文档种类，内容形式，需求描述程度，需求的优先级与可预计工作量，可能存在的技术及管理风险、系统的最

初规模。

4.项目规模：为使项目工作成功地运作，需求管理者应对所有涉众的需求确定优先级，并对需求的范围进行管理，而不是早早将精力投入到大量的开发工作中。为确保尽早发现并降低项目中的风险，软件组织首选递增与迭代的方式开发系统。更加谨慎的对待需求，务求每次增加的内容都能减轻项目中的风险，要达到良好的管理效果，需要需求管理人员和客户共同协商每次迭代的范围。

5.需求变更：不断变更的需求之所以难以管理，不仅是因为一个新特性的需求变更需要花费额外的时间来实现，也是因为某项需求变更极有可能影响到其他已经实现的需求。基于此原因，需求管理者应建立一个有弹性的业务模型结构，使它具有灵活性，能适应变更，并且确保需求源头的可追溯性。管理变更包括建立需求基线，确定需求源关系，建立相关需求项之间的可追溯性，以及不断地开展变更控制等活动。

综上所述，需求管理作为软件工程中的一部分，得到各软件组织越来越多的重视与认可。其重要性与必要性得到了广大计算机从业人员的认同。越来越多的软件组织建立了属于自己的需求管理小组，负责从项目初期进行业务获取与建模，并对需求进行全生命周期的管理。越来越多的软件资深开发人员亦从代码编写工作转型到需求管理与实践方式方法的探索上，深厚的技术基础使得他们更容易掌握判断需求的能力。同样地，越来越多的工程技术人员、领域专家也在不断的加强自身软件方面的知识，实际业务背景与需求管

理方法的结合必将提高需求建模的准确率。在这种双向结合的前景下，相信在不久的将来，软件需求工程理论与实践的相结合将产生出更贴近实际情况运用的技术与方法，软件质量的提高亦指日可待。