软件需求的变更是一直伴随着系统的存在而存在的。给我们的往往是这样的经历：一个项目做了很久也总做不完。建设方总是会提出新的需求让项目组实施，在系统上线后，用户总会不断的提出新的需求，每天要求解决新的需求问题。为了满足客户要求，满足组织层面的需求，任何项目的项目组必须接受项目需求变更的这事实。需求变更是软件开发实施过程中较头疼的事情，某些项目因为需求变更太多，变更没有管理好而导致项目失败。

首先，变更的原因是什么，为什么会发生那么多的变更。从个人以往的经验，分析以下几点。

一、业务能力不足，比如有些项目评审过程中心，业务评审人员对自己的业务都不了解。需求分析人员能力不足，往往做成出需求规格说明书质量不高，漏洞百出。

二、需求分析阶段，用户参与不足。需求分析过程中，用户不配合，或者用户还有其他任务在处理，不能全职在配合需求分析。需求分析人员不重视用户的参与，需求分析人员以自己的想法认为是客户的想法，与实际的产品使用者直接联系很困难。

三、需求分析不够彻底，需求分析人员能力不足或者没有得到足够相关知识的培训等。

四、需求评审流于形式，没有起到评审的作用。评审人员在评审前没有详细的阅读评审规格说明书，导致评审过程中往往不能很好的发现问题。

五、评审人员责任心不足，没有做到尽职尽职，疲于应付和形式。四、评审过程中用户对于需求规格说明书听不明白，看不懂相关内容，相关人员能力达不到相关要求，评审过程中抓小放大，对于不重要的问题争论不修导致不能顺利执行评审，评审会议直接失败。

六、项目的实施周期太长。按照当时用户提出需求实施后，随着时间的延长以及相关政策法规的变更等原因，用户会提出新的变更要求。

七、软件工程具有独特性，软件测需求具有不确定性。‘

其次、如何面对软件项目的需求变更？软件实施过程中，需求不可能一直不变，需求变更是项目实施过程中永远不变的规律。如何管理好项目的需求，如何面对项目中的需求变更呢，一下是一些项目管理过程中的经验。

一、需求文档要进行版本控制，文档形式记录，并且需要确认签字。

二、需求分析后形成需求规格说明书，需求规格说明书是客户对于所形成的产品的同需求分析人员达成共识的具体的文档。需要规格说明书一定要客户确认签字。形成需求基线。进行版本控制。

三、需求评审的必要性和及时性

以往经验，需求评审非常必要而且也是必须及时。在阶段性需求完成后，就需要组织砖人进行需求的评审确认，以便后续的工作，少走弯路。在需求完成后必须要进行评审。不同角色人员，从不同的角度确认，验证需求，验证可行性，完善性，一直性，以及需求的正确性。另外，评审的质量决定着后续需求变更的多少。而评审的质量和评审的准备活动密切相关。评审会议前要列出会议提纲，至少在会议前一天分发会议材料。留出存足时间给参会人员消化熟悉。评审材料要经过严格的确认，不要漏洞百出。评审时相关人员参加。评审后相关人员签署相关评审记录。

四、需求分析过程中对于参与需求分析人员及用户相关人员进行相关专业知识技能的培训，分析过程中参照相关成熟案例引导客户对需求的认识及对于分析结果的认可。

五、需求分析期间，对于用户重要干系人镜像需求的讲解。项目方，往往用户方决策者对于需求理解不是很深入透彻，需要需求分析人员进行需求情况的详细解释及系统的引导。在需求分析过程获得建设方决策程的支持。

需求变更不可避免，实施过程中对于需求变更做好控制，按照需求变更控制流程严格执行。需求变更提出，需求变更登记，需求变更分析，需求变更提交变更控制委员会审核，决定需求是否实施。

在软件实施过程中，需求变更会贯穿整个生命周期，建立规范的变更困在流程及制度，严格按照流程及制度应对需求的变更就能够更好的做好项目实施，更好的做项目相关工作。