软个项目需求调研的方法以及需求变更分析和解决
（一）软件需求概述
1．软件项目目标的三个要素是什么？
质量 成本 时间
2．理解IEEE对需求的定义。
（1）用户解决问题或达到目标所需要的条件或权能
（2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有条件或权能
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
3．理解需求文档的重要性。
（1）项目交接时不用做重复工作
（2）哪怕需求明确无误并构思准确，如果我们没有编写文档，软件也达不到期望目标。
（3）需求文档恢复设计人员提出的各类问题
4．好的需求特征有哪些？
（1） 深入理解用户的真正的意图和需要
（2） 清晰完整的需求表达
（3） 借助需求分析工具，E-R图、DFD图、DD、UML工具等等
（4） 使用科学的需求管理方法，完善需求变更控制流程
5．软件需求分析的目标是什么？
（1） 软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求
6．需求分析的任务是什么？
借助当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题
（1）通过对现实环境的调查，获得当前系统的物理模型。
（2）去掉具体模型的非本质因素，抽象出当前系统的逻辑模型
（3）分析当前系统与目标系统的差别，简历目标系统的逻辑模型。
7．错误需求的代价有哪些？
（1）错误的需求浪费了人力、物理、浪费金钱
（2）影响软件项目的成功，加大软件项目的风险
（3）影响项目组及开发方形象，对用户满意度埋下祸根
（4）增加开发的成本
8．产生不合格需求的原因有哪些？
（1）无足够的用户参与
（2）用户需求的不断增加，无法控制
（3）许多模棱两可的需求
（4）过于精简的规格说明
（5）忽略了用户分类
（6）不准确的开发计划，往往低谷需求分析的工作时间
9．好的软件需求特性有哪些？理解其含义。
一致性和全面性，又引申为8个因素
【1】无歧义因素【2】完整性因素【3】一致性因素【4】可检验性因素【5】确定性因素【6】可跟踪因素【7】可行性因素【8】必要性因素
10．理解需求层次的构成，能识别业务需求、用户需求、功能需求和非功能需求。
【1】业务需求：反映了组织机构或客户对系统、产品的高层次的目标要求，他们在项目视图与范围文档中予以说明
【2】用户需求：描述了用户使用产品必须要完成的任务，使用用例文档或场景描述予以说明
【3】功能需求：定义了开发人员必须实现的软件功能使得用户能完成他们的任务，从而满足了业务需求和用户需求。
【4】非功能需求：描述了系统展现给用户的行为和执行的操作的特性。
11．什么是需求的路线图，理解特性和涉众的概念。
（二）软件需求分析方法收集
项目需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。
为了保证项目的成功，监理方必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用承建方的软件。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、开发范围上有发言权。
如何进行需求分析
需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。
一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。
S={D1，D2，D3，…Dn}
问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。
Di={P1，P2，P3，…Pm}
问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。
Pj={F1，F2，F3，…Fk}
需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意两个问题：
1.最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。
2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
重点监控需求分析
由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。
客户说不清楚需求
有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的专家和知识。此时，用户就会要求软件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。
需求自身经常变动
根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。
分析人员或客户理解有误
软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”所以分析人员知识的专一性也会造成需求分析的误解和失败。这时，咨询监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度和注重沟通技巧。
需求分析方法论
根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。
第一阶段：“访谈式”（Visitation）
这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。
实现手段：访谈、调查表格
输出成果：调查报告、业务流程报告
第二阶段：“诱导式”（Inducement）
这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。
实现手段：拜访（诱导）、原型演示
输出成果：调研分析报告、原型反馈报告、业务流程报告
第三阶段：“确认式”（Afirm）
这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。
实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统
输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）
整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则基本集中在后两个阶段中。
（三）软件项目需求调研的方法
要想给人做管理软件，首要的事情自然是把人家现在的业务内容、管理方式弄清楚。即使你是这个领域的业务专家，也要明白一点，无论业务内容是否相同，管理方式一定是不同的，业务可以复制，技术可以复制，管理不能复制。例如，要给仓库做管理系统，需要先了解这个仓库是怎么管理的，怎么出库，怎么入库，怎么盘点，怎么核算；需要给采购部做管理系统，需要先了解采购部是怎么运作的，怎么制定采购计划，怎么下采购单，怎么签订采购合同，等等。
开发信息管理系统，首当其冲的需求来源就是如何将现在的手工业务电子化，没有这一步，说什么资源整合，说什么提高效率，说什么降低成本，说什么智能决策，都是浮云。对于管理软件来说，需求获取重点在如何理解客户业务，这是需求获取阶段最重要，也是最困难的事情，当然，对于需求分析者来说，理解业务与需求获取往往是交错进行的，很难割裂开来。
需求分析
需求获取一般包括这几种方式：观察法、体验法、单据分析法、报表分析法、问卷调查法、访谈法、需求调研会法。这是需求调研的“七种武器”，它们各有优缺点，无论你想要了解的是什么需求，都需要将这些方式组合应用，针对你想要了解的内容，以及需要了解的对象的工作特点，采用不同的方式。学会并坚持使用这七种武器后，我想你很快就会成为需求调研的真正高手。
观察法
观察法，就是你自己跑到工作现场，看！这个看上去相当简单，貌似走马观花，有些不在行的兄弟会弄得跟公费旅游一般，车间里走走散散心，撩撩HR妹子，就认为是观察法调研了，其实不然。这种方法，关键是要看人家是怎么工作的，拿了什么，干了什么，用了什么工具，送出去什么，什么时候填写了什么单据，制作了什么报表，等等。
体验法
体验法，就是你自己亲自到相关部门去顶岗，做一段时间的业务工作，有了亲身体验自然更容易理解这个岗位的工作。这种方法，最大的优点就是理解业务比较深刻。一旦你几乎成了某岗位的一员后，想想，还有什么比自己帮自己做软件更能够把握需求呢？要给超市收银员写个软件，先到超市卖几天东西，要给仓库做软件，先到仓库发两天货，你的软件偏离用户需求的可能性会大幅度降低。
问卷调查法
问卷调查法，通过编写调查问卷收集需求。通过调查问卷进行需求收集是个效率非常高的方法。对于调研者，不必跑到工作现场，不必跟一个又一个用户一遍又一遍地沟通，只要编写调查问卷、分析回答的内容就可以获得大量的有用信息；对于被调研者，不需要打断自己的工作，可以合理安排回答的时间，还可以更仔细地思考。越是大规模的调研，越能体验这种方法的优越性。
访谈法
访谈法，通过交谈的方式获取需求。需求调研最常见的入手方式是访谈，用得最多的也是访谈。你看电视里经常有谈话节目，两个人或一堆人在一起穷聊，这里所说的访谈跟这种节目有些类似，当然形式、内容比电视中的访谈要丰富得多。访谈可以非常正式，提前约好访谈对象、访谈时间、访谈地点，准备好访谈话题、访谈提纲等；也可以非常随意，电梯上，餐桌上，车上，都可以进行一次偶遇访谈。访谈也未必都需要面对面，通过电话、QQ、邮件、视频聊天等方式进行的沟通咨询，都可以归入访谈的范畴。
单据分析法
单据分析法，分析用户当前使用的纸质或电子单据，通过研究这些单据所承载的信息，分析其产生、流动的方式，从而熟悉业务，挖掘需求。一个组织，在没有信息化管理系统时，它的单据体系其实就是它的信息体系，填写单据的过程就是信息录入的过程，单据传递的过程就是信息流转的过程，最终单据进入的档案室就是数据库。因此，通过分析单据来获得关于信息管理的需求可以收到事半功倍之效。单据分析法是获取需求过程中使用得相当普遍的方法，值得仔细研究下。
报表分析法
报表分析法，通过分析用户使用的报表获取需求。报表跟单据是有本质区别的。单据是在业务处理过程中用户填写的纸质文件，往往是一个信息采集、传递的过程，而报表则是根据一定的规则对批量数据进行检索、统计、汇总，是一个信息加工、分析的过程。分析好现在使用的这些报表，可以深入到管理者的管理神经，弄清楚当前公司管理者感兴趣的信息，最终给各级管理者带来真正的价值。报表是一个信息系统的集大成者，提前做好报表分析，可以加深理解管理脉络，理解信息系统的最终需求。
需求调研会法
需求调研会法，召集相关人员开会了解需求。当需要讨论的问题牵涉到的相关人员较多时，可以组织需求调研会。相对于需求访谈，需求调研会参与的人员较多，需要做的准备也更麻烦，对会谈过程的把握也更困难，我们并不推荐滥用这个方法。如果人员太多，而你又没有足够的主持能力，或者准备得不够充分，对会议的进程把握不力，很容易把事情搞砸，不但得不到你需要的结论，还会把自己弄得威信扫地，真是大大的划不来啊。
（四）软件开发项目中的需求变更分析和解决之道
“需求变更”，一旦提到软件开发项目进程中的需求变更，无论是项目经理还是程序开发人员都感觉到头疼。而且，在一些项目管理顾问的PPT课件中，以及一些软件项目管理的技术图书和教程中，也把“需求变更”作为单独的一项来研究。本文中，与您共同探讨软件开发项目中的需求变更发生的原因、需求变更控制，以及当发生需求变更的时候如何应对解决。
一、令人烦恼的需求变更
作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。甚至要重新设计现有的架构。
而面对这种情况，作为项目经理的你是否会说：“我们无法拒绝客户, 但也无法立即满足他的新需求,所以只好是推到以后再进行完善。”或者，更极端些的想法：客户总是在异想天开，客户的需求在技术上根本无法实现……
在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。因为在一开始已经多次和客户沟通,也在没有任何异议的情况下得到了明确的答复,但当开发项目在不断演进,客户对系统的理解逐步加深之时, 他们最终还是推翻以前自己想要的需求。而这时你会认为对于需求,只有获取,没有确认。
而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。你还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求变更只会令项目组中的开发人员疲于奔命，无所适从。
在你的软件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次软件项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更？
首先，这种想法和认识是错误的，软件项目开发中的需求变更是不能被完全消除的。无论是项目经理还是项目开发人员，最好在项目开始之前就消除这种想法。需求变更是不可能被消除的，而“消除需求变更”的想法却需要被消除。消除需求变更的所有的努力和想法，在项目开发进行中通常都是费力不讨好。
项目开发过程中，需求的变更是不可避免的。
虽然一般情况下，项目经理花费了大量的心力和气力去避免需求变更，可最后需求变更总是会出现。但这并不意味着项目不应该做这方面的工作，无论是项目经理，还是开发人员对于需求变更的正确态度应该和对待软件测试的态度一样，在需求变更发生之前尽量减少需求变更发生的情况，以将需求变更带来的风险降到最低。
二、需求变更的产生原因
在软件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也可能来源于项目组内部。
对于需求变更发生的原因，细细追究起来无外乎以下几种原因：
1、范围没有圈定就开始细化
细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。
当细化到一定程度并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是人工手动添加的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。
2、没有指定需求的基线
需求的基线是指是否容许需求变更的分界线。
随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来，是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少）。
3、没有良好的软件结构适应变化
组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。
但适应变化必须遵循一些松耦合合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。
三、需求变更控制
前面已经说过了，在软件开发项目开始之前，就要消除“绝不允许发生需求变更”的思想。在项目进行，一旦发生需求变更，更不要不一味的抱怨，也不要去一味地迎合客户的“新需求”，而是要管理和控制需求变更。
1、 分级管理客户需求
软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全的正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到了客户的投入收益，所以有的时候项目经理反倒应该为客户着想。
对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。
•一级需求（或变更）是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这个级别的需求是必须满足的，否则就意味着否定自已的项目成员和成员的所有努力，所以定为“Urgent”。 这通常是属于补救性的debug类型，要救火。
• 二级需求（或变更）是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续，所以是“Necessary”。一般新模块关键性的基础组件，属于这个级别。
•三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明，所以定为“Needed”。一般性的重大的有价值的全新模块开发，属于这个级别。
以上三个等级是应该实施的，但时间性上可以作优先级的排列。
•四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好，定级为“Better”。界面和使用方式的需求，一般在这个档次。
•五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已，定级为“Maybe”。
对于四级需求，如果时间和资源条件都允许的话，不妨做下去。对于五级需求，正如对它的描述一样，做与不做是“Maybe”。
2、全生命周期的需求变更管理
各种规模和类型的软件项目的生命周期大致可以分为三个阶段，即项目启动、项目实施、项目收尾。不要以为需求变更的管理和控制只是发生在项目实施阶段，而是要贯穿在整个项目生命周期的全过程中。
站在全局角度的需求变更管理，需要采用综合变更控制的方法。
（1） 项目启动阶段的变更预防
正如前面强调的，对于任何软件项目，需求变更都无可避免，也无从逃避，无论是项目经理还是开发人员只能积极应对，而这个应对应该是从项目启动的需求分析阶段就开始了。
对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理提出需求变更的几率就越小。如果需求没做好，基准文件里的范围含糊不清，被客户发现还有很大的“新需求空间”，这时候项目组往往要付出许多无谓的牺牲。
如果需求分析做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候，项目经理一定要据理力争，此时这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。
（2） 项目实施阶段的需求变更
成功的软件项目和失败项目的区别就在于项目的整个过程是否是可控的。
项目经理应该树立一个理念，即“需求变更是必然的、可控的，并且是有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
控制需求渐变需要注意以下几点：
•需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。
•需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。
•小的需求变更也要经过正规的需求管理流程，否则会积少成多。
在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。
•精确的需求与范围定义并不会阻止需求的变更。
并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。
•注意沟通的技巧。
项目开发过程中的实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。
（3）、项目收尾阶段的总结
能力的提高往往不是从成功的经验中来，而是从失败的教训中得来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。
事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。
3、 需求变更管理原则
虽然需求变更的内容和类型有各种各样，但需求变更管理的原则却是万变不离其宗。实施需求变更管理需要遵循如下原则：
（1） 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
（2） 制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。
（3） 成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。
（4） 需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。
（5） 需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
（6） 妥善保存变更产生的相关文档。
四、需求变更应对之道
需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。针对变更控制流程，有几点应对之道。
•相互协作——很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。
•充分交流——需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。
•安排专职人员负责需求变更管理——有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。
•合同约束——需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。
•区别对待——随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。
•选用适当的开发模型——采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。
•用户参与需求评审——作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。