需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向用户最终、比较全面的需求靠拢，从根本上减少需求过多变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制较为管用。通常情况下，原型之后的需求沟通就实际得多，双方的理解迅速向一个全面折衷的方案贴近，一个可以指导研发过程、有针对性的需求说明书就可起到重要作用。
通过合同约束，建立有效的解决冲突机制。用户、开发商在实施、验收软件项目过程中难免会发生冲突，而需求变更给软件项目建设带来的影响也是有目共睹，从而可能让项目建设偏离轨道。关键是事先是否有明确的项目目标和项目要求，是否建立起有效的冲突解决机制。所以双方在签订合同时，可以增加一些相关条款，主要是要明确今后双方责权利关系，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程，否则自担变更的代价;而企业用户，也可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使信息化项目从一开始就按双方预定的规道行驶，互为制约、协调，避免再发意外。
如ERP系统能做到平稳运行一两个月以上，能够准确导出各类月度报表的时候，系统应用和各项业务操作基本正常、顺畅，通常而言，可认为系统已达到的效果或者是达到了先前预定的目标，也说明企业不再有管理流程、业务流程新需求与变更了，系统项目可算上线成功了，可以放心验收、签案了。
验收与发现、检验需求并举。大型的ERP项目不少是边实施边验收，然后再发现新问题新需求，再进一步返工完善，一步一步地把项目向前推进，但许多中小型的ERP项目最好是成功切换后，录入一个月以上的企业重要数据，上线运行一个月时间，看看有没有出现新问题、新需求，如没有就可进入验收、签案。毕竟一个月才是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。