[摘 要] 需求分析是软件生命周期中的重要阶段，决定软件项目的成败；需求变更会严重影响软件项目的质量、成本和工期。本文分析了需求变更的原因和影响，并给出了对需求变更进行有效控制的对策。

[关键词] 需求分析；需求变更；需求控制

一、问题的提出

什么是需求分析？

要知道需求变更是什么，首先要知道什么是需求分析。

需求分析是指理解客户需求，就软件功能与客户达成一致，估计软件风险和评估项目成本代价，最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。

什么是需求变更？

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

二、需求变更的原因及影响

1、需求变更原因

一方面是用户：他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后，在软件开发过程中用户改变了需求，这只能迫使开发工作返工，丢弃一些无法修正的部分。无疑这会造成一定的损失，但又无法完全避免。要求用户一次性把需求讲清楚，并且不允许此后需求有任何变更，这是不现实的。只能尽量减少需求变更，降低它所造成的影响。

二是系统因素：在系统内部，如计算机硬件、系统软件或数据的变更要求与其相适应。

三是外部环境因素：与软件运行相关的工作制度或法规、政策的变更，或是业务要求变更导致的需求变更。

四是需求分析阶段工作缺陷：需求调研、分析、定义和评审工作不够充分，致使需求规格说明中隐含着问题，在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分，如未能如实获得用户的潜在需求等。

软件需求一旦出现变更，它可能要涉及到一些相关的代码和文档的修改，为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段，并且随着项目的进展，越晚的需求变更引起的损失越大。

2、需求变更给软件的开发工作带来的影响

需求变更对软件开发的影响是多方面的，概括的看，包括以下三个方面：

（1）增加项目的人员、费用开支，影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差，需要进行需求变更。这无疑要增加项目的人员、费用的开支，并对开发进度造成影响。更有甚者，如果变更频繁，可能对项目造成较大影响，严重时可能直接导致项目的失败。

（2）影响软件质量。在一个复杂的软件系统中，需求之间具有一定的联系，相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节，就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时，这些错误一般难以被测试人员发现，将直接影响系统质量，严重时可导致系统崩溃。

（3）影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧，如果没有恰当处理，影响双方的互信，从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧，影响合作关系。

三、采取的对策

1、首先是预防

尽量做好需求分析工作，以期减少需求变更的频次，为此在需求分析阶段着重处理好以下问题，力图使需求分析的结果更接近目标。

（1）培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上，而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此，双方的参与者都需要认识到：要想获得成功，自己需要什么，合作方又需要什么。只有这样，才能建立融洽的合作关系。因此，培养正确的需求意识是双方都需要努力的，而开发人员在这个阶段应该发挥更加积极主动的作用。

首先，需求分析人员应该接受一定的正规培训，以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧，以及收集整理资料的能力等。在参与具体项目时，分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识，以更好地理解用户的需求。

其次，开发单位应该对那些不想花时间在需求分析上的用户明确指出：如果用户不能充分地支持并参与，项目很可能会失败；开发单位还可以通过学习一些前车之鉴的真实案例警告用户：低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训，使他们真正理解需求分析的重要性和忽略需求带来的风险，并对计算机系统有一个大体的了解，这样用户才能够主动地参与需求分析。

同时，正因为不可能一次就完全了解用户的需求，而且在系统开发过程中还需要不断地请用户参与，因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此，需求分析人员需要对用户解释一些做法的必要性和合理性，以得到用户最大的支持与合作。

（2）从业务需求入手。用户认识到了需求分析的重要性，但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手，任何企业对自己的经营运作目标应该是比较清楚的，这样的经营背景让用户不仅有话说，也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离，只有当系统真正置身于它的社会和组织环境中，它的需求才能清晰地反映出来。

（3）充分利用需求来源。有了以上需求背景，就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件；观察系统的潜在用户当前的日常工作以获取有价值的信息；系统的使用者可能有很多，可以将他们分类以简化需求；最后一定要与真正的决定者达成协议：对于有冲突的需求如何权衡，对于直接用户的众多需求如何取舍等。

同时，用户往往对计算机期望过高，认为计算机可以解决当前存在的所有问题，因此会提出很多的功能需求，并且希望在很短的时间内看到成效。但是，由于技术、人力等资源的限制，并不一定能够在设定的时间期限内满足用户所有的期望，这时就应该尽早确定出交付的产品应具备的最重要功能，即设定需求的优先级。

在这个阶段，可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发，而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉，容易沟通；而且不会在需求分析的一开始就陷入过于细节化的设计，也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。

（4）提供选择方案。由于用户对软件系统缺乏经验，或者由于用户的运作机制还未完善，或者由于其他种种原因，用户可能仍然不能对一些需求做出明确的说明，收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点，供用户选择或者启发用户确定需求。

如果需求分析做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候，开发方一定要据理力争，此时这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。

2、分级管理客户需求

软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户的投入收益，所以有的时候项目经理反倒应该为客户着想。

对于项目中的需求变更，可以实行分级管理，以达到对需求变更的控制。

一级需求变更是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这个级别的需求是必须满足的，否则就意味着否定自已的项目成员和成员的所有努力，所以定为“Urgent”。

二级需求变更是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续，所以是“Necessary”。一般新模块关键性的基础组件，属于这个级别。

三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明，所以定为“Needed”。一般性的重大的有价值的全新模块开发，属于这个级别。

以上三个等级是应该实施的，但时间性上可以作优先级的排列。

四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好，定级为“Better”。界面和使用方式的需求，一般在这个档次。

五级需求是可选性需求，更多的是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已，定级为“Maybe”。

对于四级需求，如果时间和资源条件都允许的话，不妨做下去。对于五级需求，正如对它的描述一样做与不做是“Maybe”。

3、加强需求变更的控制

在需求分析阶段工作完成后，需求变更仍可以会发生，因此就要加强对需求变更的控制，主要有以下原则：

（1）建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

（2）制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

（3）成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

（4）需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

（5）需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

（6）妥善保存变更产生的相关文档。

这六大原则看起来简单，但真正实施起来有难度，还需要依据理论知识配合开发项目组的实际工作情况，在实践中不断摸索总结。

四、总结

软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理，将需求变更的频次大幅度降低，从而为软件项目的顺利实施打下坚实基础。