需求变更管理
在 MES 实施过程中，负责人一方面要好需求的实现，另一个工作重点就是要控制好需求的变更，尤其是在系统上线的前后，业务部门会提出五花八门的变更需求出来，这时候项目负责人要坚信的理念是：“此时的 80％以上的需求变更是可以不用响应的（注意是响应，不是理会）。”原因何在？
此时业务部门所提出的需求所产生的原因往往集中在以下几方面：
对软件操作不熟悉。
操作模式同之前的有较大的区别
业务流程还未理顺，尤其是部门之间的衔接还不顺畅
相关的基础数据不完善，甚至有错误的地方
出于部门利益的考虑（尤其是初期的数据录入等环节）
因此要灌输的思想是：“先固化，再优化“先强力推进应用，即便有问题也要用（很多企
业往往会在这出问题），但同时对业务部门所提出的需求也不是不理会（这样会丧失员工的积极性，根基会虚，对未来的实施应用带来影响），而是要认真的处理。
处理的原则就是：收集，整理，分类，处理。
收集：要广开问题及需求获取的渠道，认真地听。
整理：对所收集的问题，认真地整理，形成清晰的需求（这点非常重要）。
分类：对问题进行分类，通常可以分为不响应，暂时不响应，响应等。
处理：对不同分类的问题，采取不同的处理原则。
如果是涉及到上面所提到的:
“对软件操作不熟悉”等原因的需求，可以不响应，但要做好说明和培训工作;
对于的确是需求的问题，但不涉及全局工作的，可暂时不响应（但对提出者要给予鼓励，说明将在后续的工作中给予响应）;
对于影响了企业全局工作或影响实施效果的工作，经过判断，要响应的，需要同实施方共同提出响应意见。
经过以上的处理原则，可以对需求变更进行较为合理的控制。但要做到这点，负责人除
了做好内部沟通外还要做好外部沟通。
当系统运行半年左右，项目负责人应结合业务应用的情况，对之前所提的变更需求进行彻底的分析，提出真正的变革需求。因为此时业务部门对 MES 系统有了一个熟悉的过程，对操作，流程等已经比较熟悉，此时所提出的变更是相对客观的，富于建设性的。
需求变更及对策
一、问题的提出
什么是需求分析？
要知道需求变更是什么，首先要知道什么是需求分析。
需求分析是指理解客户需求，就软件功能与客户达成一致，估计软件风险和评估项目成本代价，最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。
什么是需求变更？
根据软件工程思想定义，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求，或对原有需求进行修改和削减，均属于需求变更。
二、需求变更的原因及影响
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）妥善保存变更产生的相关文档。
这六大原则看起来简单，但真正实施起来有难度，还需要依据理论知识配合开发项目组的实际工作情况，在实践中不断摸索总结。
四、总结
软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理，将需求变更的频次大幅度降低，从而为软件项目的顺利实施打下坚实基础。
