软件项目管理中的需求管理与变更管理

龙源期刊网

企业项目管理中的需求变更管理

作者：姜金奎

来源：《商场现代化》2015年第06期

摘 要：对于现如今的项目管理工作来说，这项工作的复杂性比较突出，而且涉及到的内容也是多方面的。相关的工作人员需要根据项目管理工作的需求和变更管理的需要来进行具体的分析，将可能出现变更的因素进行严格地控制。并且将其应用到实际的项目管理工作中，希望能够给相关的工作人员提供借鉴和参考。

关键词：项目管理；需求；变更；管理

在具体的项目管理中，需求变更的主要的形式表现在多方面，其中比较常见的就是老板的临时想法，项目预算程度的变化以及客户需求的改变等等。尤其是在IT项目中，项目需求变更源可能来自服务商，客户等等。所以说，需要根据项目管理工作之间差异的不同来找到不同变更形式和出现变更的原因。

一、需求变更的原因分析

1.范围没有圈定就开始细化。对于项目管理的变更工作来说，对管理工作进行细化是需要专业管理人员来完成的一种比较重要的工作内容。如果仅仅通过客户对项目的需求进行描述就进行具体的细化工作，必然会造成不良的影响。无论是设计的数据还是相关的资料都需要出现一定范围的改变。尤其是现如今计算机系统的不断完善，有些数据需要根据计算机系统来进行计算，才可以对具体的实体来进行描述。也就是说，还没有做好具体的圈定就开始细化。

2.没有指定需求的基线。所谓指定需求的基线就是指能否达到需求变更的分界线，由于各种项目正在不断发展，发展本身就是一个相对比较动态的问题，因此，需求基线也在发生明显的变化。因此，能否对变更条件进行控制主要取决于合同和成本因素。具体来说，就是某个项目整体需求范围已经确定，而且容许改变的范围也得到了明确地规定。但是在实际的工程建设中，如果由于项目的预算无法达标，必须要进行改变的时候，项目的基线就会逐渐增高。所以说，项目需求的基线永远处于不确定的状态。

龙源期刊网

软件项目的需求变更管理

作者：

来源：《计算机世界》2010年第48期

近年来，国内各级政府部门、企事业单位在信息化建设上取得了长足进步，但由于不少组织整体管理水平相对较低，在信息系统建设上缺乏系统、长远的战略规划，没有先进、适用、可行的管理实践理论作为指导，因此很多软件项目没有在预定的范围、投资总额、工期内完成，工期延期、延误成为普遍现象。

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。 龙源期刊网

软件项目需求管理简述

需求的概念

从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。

需求的重要性

需求是整个产品链的源头，需求工作的优劣将直接影响到产品的设计，生产，销售和维护的全过程。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。目前国内很多软件业普遍存在这样一个现象：人们并不真正清楚到底该做什么，却一直忙碌不停地开发。

Frederick Brooks在他的经典文章“No Silver Bullet”是这样描述需求的重要性的：

开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

什么是需求管理

把所有与需求直接相关的活动通称为需求管理。

需求管理中的活动可分为两大类，

需求分析：对用户的需求进行整理、分析和完善，形成文档

需求维护：需求确认，需求跟踪和需求变更

需求工程贯穿产品生命周期的全过程。

需求管理的主要内容

需求分析流程

需求调查

首先需求分析员起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以是层次化的，随着调查的深入，问题表将不断地被细化。问题表应当以“选择题”和“是非题”为主。 其次，需求分析员应当确定需求调查的方式，例如： 与用户交谈，向用户提问题。向用户群体发调查问卷等。

还可以从用户的工作流程，相关文档以及行业标准、规则中提取需求。分析已经存在的同类软件产品，提取需求。

最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，进行需求调查。

细化用户需求

根据用户需求调查，对用户的需求进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析。

软件开发工程需求变更经管及应对之道研究

变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。

需求变更经管的需求

需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。

需求变更的出现主要是因为在工程的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。

随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来经管需求变更，那么很可能造成工程进度拖延、成本不足、人力紧缺，甚至导致整个工程失败。当然，即使按照需求变更控制流程进行经管，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更经管的目的所在。

六大原则

实施需求变更经管需要遵循如下原则：

1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 2.制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的工程开发和其他工程都有借鉴作用。