需求变更
ERP实施中最恐怖的事情：需求变更
Posted by compsoft on 2009-4-22 14:47:24View 259Comments2
辛辛苦苦熬了几个月的通宵，终于确立了ERP需求，规范了工作流程，系统配置也完成了，正准备按部就班ERP系统上线时，企业用户突然改变了需求，不想这么做了，提出了新的需求。这对于ERP实施顾问来说，正如晴天惊雷，这也是所有ERP顾问最感到恐怖的事情。因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。
一．需求变更：迁就or拒绝？
从ERP项目立项开始，需求就是ERP实施顾问的心头之痛。随着对ERP的深入认识、项目环境的变动，企业内外部多种因素都可能使客户对ERP的需求不断改变。如果不能有效处理这些需求变更，项目实施进度必将一再调整，上线日期也会随之一再拖延，项目成员的士气也将越来越低落，严重的还会直接导致ERP项目失败。
需求变更，本应是客户的权力，但也是实施顾问的为难之处。如果确需变更，当然要满足客户需要。问题是不能让变更权力滥用，把一些无关痛痒的变更宠惯养成堂而皇之的变更。例如，我曾经在某ERP项目中属于“谦虚型”，对于客户提出的变更，无论大小都给予解决，客户对此非常满意。然而，项目进度却拖得很长，项目一再延期。相比之下，在另一个项目上我显得稍有些“盛气凌人”，对于客户提出的需求变更，大多都不予理睬，客户对此不是很满意。不过，该项目的进度控制得较好，基本能按期完成项目。
按后一种“盛气凌人”的做法，对客户的要求一概不理，自顾自地按照最初的需求和计划实施，很可能会由于没有用户的参与，使得ERP系统与用户的需求相差甚远，导致验收通不过，收不回尾款而使公司利益受损。对于客户来说，达不到需求的满足也浪费了投资。事实上，客户不满意，则项目就不算成功，实施顾问辛勤劳动最后就只能落得个“没有功劳，只有苦劳”的份。
但按前一种“谦虚型”做法，完全顺着客户的意见走，客户满意度就一定会高吗？其实也不一定。由于需求变更会带来工作量的大量增加，甚至可能会出现大量的无效劳动。而且，频繁变动的需求也会导致实施质量下降，留下许多隐患。因此，一味的迁就用户将会使进度一拖再拖，实施方案一改再改，变更越来越多，士气越来越疲，公司越来越不满意，用户越来越急。
二．需求变更为什么总是做不完？
在ERP实施过程中，实施顾问所要面对的将是一系列和多方面的考验。经常发生而又最令人头疼的恐怕就是需求变更了。客户变更需求是ERP项目与生俱来的特性，也是一个无法避免的事实。需求变更的表现形式是多方面的，如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。它会导致ERP实施过程中成本增加、进度拖延等风险，而且越往后的变更产生的风险将越大。
以笔者参与的多个ERP实施项目的实际经历来看：需求变更泛滥是非常可怕的事，尤其是到了项目实施后期，客户不断对移交的ERP系统提出修改意见，甚至有时刚刚重新完成的更改，客户又要求改回去或改成另一种模式。需求变更越来越多，实施顾问只能疲于应付。“无底洞”是大部分实施顾问进行ERP项目的共同感觉。
实施顾问作为项目的承担者，在规定时间内利用有限资源保质保量的完成项目，让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗？我们分析一下出现需求变更的根源。
ERP实施最恐怖的事情：需求变更2
（1）合同签订马虎，没有真正明白客户需求
签订合同时缺乏对客户需求认真对待，导致需求描述不清，为后期的实施工作带来困惑。ERP销售顾问为使客户能够快速的签订合同，往往草率决定和片面同意客户提出的需求。当客户提出新的需求时，往往是销售顾问一看“应该”只是一个小小的修改，没有太大的影响，所以直接答应能变更。
该问题的关键是合同签署的太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚，后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围，可以为以后各项实施工作的开展奠定深厚的基础。
（2）调研时没有深入理解客户需求
在ERP上线前的需求调研分析阶段，项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进行。更严重的是，实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案，没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导一拍脑袋提出新的需求时，实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分，双方对需求的理解就会产生差异，就会导致移交 ERP系统时才使问题暴露出来，客户只能频繁的提出需求变更。
（3）没有明确的需求变更管理流程
没有明确的需求变更管理流程，就会使需求变更变得泛滥。并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。比如ERP界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改没有严格把关流程，有些小需求看起来工作量不大，但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。
（4）没有让客户知道需求变更的代价
对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对实施顾问的辛苦就会难以体会。在评估代价过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。
三．如何有效控制需求变更？
需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。例如授权、审核、评估和确认，在实施过程还要进行跟踪和验证。有句通俗的话说得非常好：“需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”
用户需求的变更总是不可避免的，所以我们要以积极的心态去接受和控制用户的需求，而不仅仅是埋怨。对待客户频繁的需求变更，应采取有效办法应对，避免事态蔓延，不
让客户养成随意变更的毛病。
（1）合同约束
需求变更给ERP实施带来的影响是有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。
虽然ERP项目合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。有一个笑话，就是许多销售顾问都开玩笑说他们都是清政府。为什么是清政府？清政府的特点之一就是丧权辱国的条约太多。
（2）建立需求变更审批流程
明确需求变更审批环节、审批人员、审批事项、审批流程等。目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。
有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响，以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有书面材料，当用户发现由于业务变化而引起的需求变更，需要提出书面申请。这样对所有的变更，双方的项目负责人都能做到心里有数。而且用户在递交书面变更申请时比较慎重，一般都在内部经过讨论后进行，这样减少了因用户内部看法不同导致的反复变更。
ERP实施最恐怖的事情：需求变更3
（3）对于零星变更，集中研究、批量处理
每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目运行的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划，注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱的变更不做，保大局弃小变。
（4）评估各种需求变更的影响
客户的需求是永远不会满足的，可能一天一个样,为了达到控制频繁的需求变更。需要将需求变更后产生的成本进行评估与量化，形成分析报告提交双方领导。否则，一味的妥协只会让项目进一步恶化，实施顾问需要掌控客户及公司的进度成本，把客户的每一次需求变更进行成本分析。确认哪些需要收费变更，哪些可以免费配合客户。这样既可以维护客户关系，又不致造成公司无谓的损失。
（5）确认客户是否接受变更的代价
让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果，通过与客户的协商，项目组可能会得到回报或者即使没有回报也不会招致公司和客户双方的埋怨。
如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户
认识到不是所有的需求都需要变更，更不是所有的需求变更都需要立刻修改。客户一般对E RP不甚了解，他们认为很简单的事情，但可能解决起来会很复杂。以笔者的经验来看，一般来说用户的镀金需求可以延期解决甚至不考虑。用户的新增需求如果不是影响到核心业务的实现，也可以安排在现有功能的完善之后。
（6）每月变更记录上报双方领导
最后，实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案，可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权，逐步让不合理的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常的项目执行氛围和良好的工作习惯，也为可能受到变更所带来的责任问题留下伏笔。
最后，要特别提醒，要在ERP项目开始就对项目组和客户进行宣传和培训，让所有成员都理解变更控制的重要意义。
产品需求管理中的需求变更
产品需求管理中的需求 变更 LG GROUP system office room 【LGA16H-LGYY-LGUA8Q8-LGA162】
产品需求管理中的需求变更 IT行业中失败项目的比例可以说明“项目管理”是很难做好的事情，项目失败的原因千千万，我认为需求管理、需求变更管理是个很重要的因素。恰恰PM的工作缺不了项目管理，更缺不了对于需求的管理，偶然的原因，和团队分享了我对于项目进行中“需求变更”的理解和管理方法。忽然发现之前写过很多产品思考和细节思考的东西，但从没有整理出方法论，后续应该多整理下方法论。 我认为对需求变更这件事是需要无限关心的，它的目的在于两点： 1，管理需求变更的过程，实际上是不断明确项目目标的过程，是自我完善的过程。 2，需求变更对虚拟团队的打击是PM需要避免的，无论是对PM的信任度，还是对于自身的挫折感，都很重要。 我整理的需求变更循环如下： 1，需求质量 需求包含调研过程、沟通过程、文档产出等内容，PM前期需要尽可能的想清楚、表达清楚，包括大局、节奏和细节。需求质量的高低能够对后续的变更起到决定性的作用，杂乱无章、漏洞百出的需求必然会导致无尽的需求变更。但需求质量也并不是绝对的，要看项目，看开放方案，对于敏捷开发来说，质量要求也许70分就够了，快速迭代才是硬道理。对于重大项目，也许要80分才能过各级的评审。但无论如何60分是必须的，需求达到一定质量才能立项进入开发阶段，这也是一般情况下采取的项目评审方式。 2，团队理解一致 PM团队、项目虚拟团队的沟通效果最重要，要明确每个人的理解一致。PM把自己的调研、设想、预期描述清楚是第一步，这也是PM的必须课。但更重要的是要明确每个人的理解是一致的。要知道很多时候不同的人对于同一句话，同一个描述段落，理解很有可能是不一致的，这必然会导致后续的发展不一致。因此团队成员每一个人的理解是一致的这件事很重要，不光是为了给大家洗脑，更重要的是让大家做同一件事。 3，越早发现问题越好 问题发现的越早，产生的破坏力越小，对项目进度的影响也越小。可行的方法有很多，随时关注开发进度、进行每日例行站会都是好方法。PM的责任当然不是启动开发后把所有的事情交由项目经理(或者开发负责人，或者什么人)去管理，正确的方式应该是要不自己就是项目经理，要不自己也参与项目的管理工作，最低自己也得随时关注项目的进度。 4，积极面对 发现问题后不能等待，要么变更要么放弃，必须做出选择。事实上经常会遇到一些情况，让我们很难去积极面对，比如资源紧张，比如时间紧张，比如麻烦太大，比如无法向老板交代，比如无法向同学们解释，比如会让同学们鄙视等等。但不作为永远都是下下策，积极面对是解决问题的唯一出路，也是必须要使用的方式。 5，及时更新文档 文档虽然不是最重要的，但记录变更非常重要。无论是对团队成员来说，还是对自己来说，记录变更内容都是非常重要的。每个人的记忆力都是有限的，每次评审都是没有记录的，每次邮件都是杂乱无章的，每次会议纪要都是不正式的。唯一正式、可靠的就是需求文档，将变更内容及时更新不但是良好的工作习惯，也是对项目团队负责人的表现，任何人这样做都会获得别人的尊重。 6，冻结时间点
需求变更的代价
需求变更的代价 让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决 定调整所有界面，Steven只好立刻动员大家抓紧时间修改。可后来当听说因修 改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会 让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。对软件需求和需
如何做好需求变更管理——需求变更流程规范
如何做好需求变更管理——需求变更流程规范 一、引言 由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。 二、目的 控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。 三、角色与职责 1、市场人员 1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2）负责与客户的沟通确认，并及时反馈客户最新需求。 3）负责与项目经理的沟通 4）负责与客户协调沟通需求变更中需求部分存在的差异 5）负责将需求变更中的需求提供给客户签字确认 2、项目组长 1）负责协调变更的需求并对变更的需求有拒绝的权利 2）负责对变更的需求部分设计的修改 3）保证项目的开发与需求的一致性 4）确定开发进度是否需要进行变更 5）分配新需求给相关开发人员 3、测试组长 1）负责相应测试需求分析书的修改 2）负责把最新需求及时传达到测试人员 3）保证测试进度与开发进度一致性 4）负责与项目组长及时确认最新需求 4、测试人员 1）负责更改测试用例，保证用例与需求同步 2）调控测试进度，保证任务的正常完成 5、项目经理 1）参与需求修改的评审工作 2）最终确认需求是否进行修改 6、配置管理员 1）负责更新需求文档，记录需求更改记录
2）负责需求变更信息的发布与跟踪 四、需求变更处理流程图 需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图： 1、需求变更流程(客户提出需求变更) 1）执行条件： 客户提出需求变更 图：需求变更流程(客户提出需求变更) 2）流程说明： 需求来源：客户提交相关需求变更
软件开发项目需求变更管理及应对之
软件开发工程需求变更经管及应对之道研究 变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。 需求变更经管的需求 需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。 需求变更的出现主要是因为在工程的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。 随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想
到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。 这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来经管需求变更，那么很可能造成工程进度拖延、成本不足、人力紧缺，甚至导致整个工程失败。当然，即使按照需求变更控制流程进行经管，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更经管的目的所在。 六大原则 实施需求变更经管需要遵循如下原则： 1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
IT项目需求变更表申请表(实例)
需求、设计和开发变更表 产品名称龙岗政府在线升级改造项目 项目名称龙岗政府在线升级改造项目项目经理霍军良 变更申请人郭昊申请时间2007年7 月19 日变更类型 □新增需求需求变更□内部改进□产品缺陷 □系统环境变更□其他 变更描述 变更前的描述（若是新需求，则不需填写此栏）： 区长信箱的管理部门（区长专线办）只能指定一个部门处理区长来信。 新需求或变更后的描述： 区长信箱收获的区长来信，区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果要求集中在前台按照各个部门的处理结果按照列表显示。 变更影响的配 置项序号配置项影响描述当前版本需求变更受影响的文档版本号的更新 2.0.1 变更评审方式项目组裁决□召开评审会议□会签评审评审负责人霍军良评审成员宋雷鸣、郭昊、卞兆洋、梁伟 评审意见更改对产品组成部分的影响： 在区长信箱多了一些功能操作。增加了多部门处理方法！ 更改方案描述： 在页面中选择好要分发的部门，然后在后台将部门数据传入到集合内，循环遍历集合中数据属性存入数据库相关表中。并删除原来数据。最后在系统的工作任务中建立任务调度时间设置在每天22：00。 变更对进度的影响 （天） 由于工作量不大，而且通过加班工作，对进度的影响可以 忽略不计。 第1 页共2 页
变更对成本的影响由于工作量不大，而且通过加班工作，对进度的影响可以 忽略不计。 变更对质量的影响添加这个新的需求会对系统测试案例等文档产生影响。对 配置库的影响是：受影响的文档版本号的更新。 变更引起的风险无 技术评审结论可以更改□拒绝变更 是否属不合格□是不是 评审人员签字评审负责人评审人评审人评审人评审人评审人评审人霍军良郭昊宋雷鸣卞兆洋梁伟 CCB意见 立即更改□推迟更改□拒绝变更 签字林文涛日期2007年7 月19 日 项目经理 确认 卞兆洋、郭昊在2007-7-18中午晚上加班修改完成。 签字霍军良日期2007年7 月19 日变更当前状态□已指派□已打开□已更改已验证 更改情况 已经对区长信箱收获的区长来信，区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果集中在前台按照各个部门的处理结果显示在列表中。 更改人签字郭昊、卞兆洋日期2007年7 月19 日 更改验证情况 通过任务调度，已经测试通过，实现了分发给多个部门处理。 验证人签字刘艳君日期2007年7 月19 日变更配置项验证 变更的配置项责任人完成日期版本CMO审核结论 需求变更宋志强2007年7月19 日 1.01 已更改完成 第2 页共2 页
产品需求变更流程
页数1/5 声明: 本文件属贵州富泰集团深圳分公司所有，在规定范围内使用，未经文控中心批准，禁止复制、泄露。 修改记录 序号页次版本修改内容记要制/修订者审核批准生效日期11-5A/0首次发行 文件分发要求 分发部门分发份数分发部门分发份数海外事业中心■深圳□贵州份盛世国泰（深）□深圳□贵州份虹语通讯（深）□深圳□贵州份恒博新金属（贵）□深圳□贵州份创博宇（贵）□深圳□贵州份利盈福电池（贵）□深圳□贵州份冠诚注塑（贵）□深圳□贵州份明晰清听筒（贵）□深圳□贵州份启铭镜片（贵）□深圳□贵州份响达鸣喇叭（贵）□深圳□贵州份蓝宇包材（贵）□深圳□贵州份英杰雄充电器（贵）□深圳□贵州份益丰塑胶制品（贵）□深圳□贵州份发利永摄像头（贵）□深圳□贵州份锐达精密模具（贵）□深圳□贵州份英利荣手机按键（贵）□深圳□贵州份银海电子（贵）□深圳□贵州份PCBA事业部（贵）□深圳□贵州份惟思达（深）□深圳□贵州份 制订审核批准 日期日期日期
页数2/5 1.目的： 规范化海外事业部产品需求变更流程。 2.范围： 适用于海外事业部所有产品。 1.定义 需求变更：立项后因客户或因市场变化而提出的新产品需求，包括产品功能、硬件配置、外观工艺、用户体验等产品需求变更。 2.职责 4.1 市场部：明确变更需求，跟进，推动需求落实，过程中协助对客户事宜的沟通。 4.2 产品部：组织评估产品变更需求的可行性及风险，提交需求变更 4.3 项目部：准备详细的schedule，人力资源配置，提交项目预算。 4.4 研发中心：协助产品部，项目部评估相关工作。 4.5 品控中心：协助产品部，项目部评估相关工作。 4.6 运营中心：协助产品部，项目部评估相关工作。 5．程序内容： 5.1 需求受理 5.1.1市场部和产品部作为客户需求变更受理的主要入口，其他部门若有收到客户需求信息，转发知 会市场部及产品部 5.1.2市场部提交《需求变更申请表》给产品部，由产品部主导组织评估 5.1.3产品部对需求进一步了解，细化，必要时可再与客户Double check，明确具体需求 5.2 需求评估 5.2.1需求明确后，产品部依照需求同相关部门共同评估，明确可实现性、开发成本、相关风险以及 开发周期等。 5.2.2 评估结束后，产品部记录并发出评估会议纪要 5.3 与客户沟通 5.3.1市场部将评估结果反馈客户，产品部可协助进行沟通，确定 5.3.1.1若客户不同意，意见转内部，进行二次评估，直到与客户达成明确共识。 5.3.1.2若客户同意，由产品部给出评估报告与《需求导入核准单》，由产品经理组织公司各单位确认、 完成公司内部确认栏部分，并给与汇签；由市场部确认完成《需求导入核准单》的客户确认栏部分。 5.4 最终核准
需求变更流程规范详细列表
需求变更流程规范 软件工程项目管理经验之一 一、引言 由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。 二、目的 控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。 三、角色与职责 1、市场人员 1、负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2、负责与客户的沟通确认，并及时反馈客户最新需求。
3、负责与项目经理的沟通 4、负责与客户协调沟通需求变更中需求部分存在的差异 5、负责将需求变更中的需求提供给客户签字确认 2、项目组长 1、负责协调变更的需求并对变更的需求有拒绝的权利 2、负责对变更的需求部分设计的修改 3、保证项目的开发与需求的一致性 4、确定开发进度是否需要进行变更 5、分配新需求给相关开发人员 3、测试组长 1、负责相应测试需求分析书的修改 2、负责把最新需求及时传达到测试人员 3、保证测试进度与开发进度一致性 4、负责与项目组长及时确认最新需求
4、测试人员 1、负责更改测试用例，保证用例与需求同步 2、调控测试进度，保证任务的正常完成 5、项目经理 1、参与需求修改的评审工作 2、最终确认需求是否进行修改 1、负责更新需求文档，记录需求更改记录 2、负责需求变更信息的发布与跟踪 四、需求变更处理流程图 需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图：
需求变更申请表模板
项目需求变更申请表 项目需求变更申请表 填表说明 1.变更类型为：增加、删除、修改； 2.变更阶段为：需求阶段、详细设计阶段、开发阶段、测试阶段； 3.变更原因为：业务改变、新增需求、需求取消、其他（需明确原因）； 4.需求确定时间以QC人员收到项目负责人发送的项目需求确认文档的工作邮件时间为标准，项目需求文档 包括但不限于项目需求原型和项目需求说明书。 5.项目需求确认文档必须发送到开发负责人、QC人员、开发部经理邮箱，QC人员做好备案管理。 6.变更优先级为：特级、普通、建议，对于建议级的变更“不参与讨论，不做处理”，仅作为给开发人员的参考， 项目开发不做任何变动，QC人员做备档处理；特级和普通级的任何一个变更一经提出必须有明确的处理结果，QC人员做好全部过程中的备档处理。 7.基线影响只能填写“有”或者“没有”影响； 8.增加工作量：明确增加的具体工时，以“人/天”为标准计量单位，最低为0.5人/天； 9.项目进度影响：明确项目进度受影响的时间，明确项目要延期交付的时间，以天为计量单位，最低为一天； 10.项目性能（功能）影响：明确对某一个功能（性能）产生的影响； 11.QC(quality controller)质量控制员职责：在产品（项目）生产（开发）各个过程的（质量、规范）管理控制， 并协同相关部门开展工作的职责。工作范畴为：原料（需求分析）生产（开发）过程成品产出（项目验收交付）。项目中所有的工作邮件包括但不限于需求变更邮件、人员异动邮件、人员外出支持申请邮件、需求（原型）变化邮件、项目会议记录邮件等必须抄送项目QC人员备案，未抄送邮件视为无效邮件。QC人员对所有的项目邮件进行收集、整理、统计备档。 12.对于无效邮件所有项目人员均可以不予理会，QC人员只对有效邮件做处理。 13.工作邮件的回复必须标准、简洁、明确。邮件第一行必须包括但不限于这行内容“邮件已收到，收到时间： 2011-10-20 12:01。”时间小时采用24小时制，精确到分钟。 14.项目基本信息、变更需求编号、分析者、需求分析日期由QC人员填写； 15.变更类型、变更阶段、变更原因、变更优先级由项目负责人填写； 16.变更申请人、变更申请日期、变更模块、变更前后内容（或者功能、性能、界面展示）描述由产品人员填 写； 17.进度影响分析、功能影响分析由开发负责人填写； 18.审核签字：每位签字人员必须明确表示“同意变更”或者“不同意变更”并签名； 19.分析者包括但不限于产品人员，开发负责人，项目负责人，开发部经理； 20.所有填表处严禁出现语义表述模糊字样，必须明确表态“同意”“不同意”“是”“否”“有”“无”等；
需求变更分析报告书
目录 变更—YH_01 (2) ?需求变更ID (2) ?变更描述 (2) ?变更提出人 (2) ?变更提出时间 (2) ?变更重要程度 (2) ?影响分析 (2) ?对当前项目的影响 (2) ?对项目工时的影响 (3) ?对项目成本的影响 (3) ?对其他需求的影响 (3) ?可能要变更的其他组件 (4)
变更—YH_01 ?需求变更ID ?编号：YH_01 ?标题：可以上传多个课程交流附件 ?变更描述 ?描述：教师用户经过慎重考虑决定提出需求变更，要求在课程交流内可以上传多个附件（1—3个） ?变更提出人 ?教师用户代表 ?变更提出时间 ?2016年12月20日15:30:00 ?变更重要程度 ?较大 ?影响分析 ?对当前项目的影响 该需求用例是公共用例，并且附件上传功能在项目要求中明确提出，此次需求变更由教师用
户代表提出，所以项目小组必须要将这次需求变更与客户代表，学生代表交涉沟通。而且这个需求变更还会涉及多个其他需求，也需要和其他用户代表确认。如果该需求变更通过，将会给项目组增加工作量。增加的工作内容主要是用例文档中的需求用例的删除、修改，界面原型中的相关界面的修改，同时导致用户手册中相应操作介绍的修改，导致测试用例文档中相应测试用例的修改。 ?对项目工时的影响 因为需求变更需要与其他用户代表沟通确认，修改相应的文档、界面原型等，可能会延长项目工时： 沟通确认需求变更——1d 修改用例文档——0.5d 修改界面原型——0.2d 修改需求工程计划——0.3d 修改测试用例文档——0.5d 更新软件需求规格说明书——0.2d 维护需求变更空难告知文档——0.3d 合计——3d ?对项目成本的影响 项目成本的增加成本主要是人员工时增加 ?对其他需求的影响
需求变更记录
需求变更： 用户管理：近期与D公司往来的用户激增，导致需求量变大，濒临入不敷出现象，故需及时做好需求变更操作，以免给D公司带来不必要的损失。 设备管理功能：在需求获取结束后，由于D公司仓库对设备的需求量变大，需要进行一定量的需求变更。又由于仓库配备的人力资源不够，所以需要添加2个人协助管理员一同进行设备号的添加以及设备信息的更新操作。 变更日期：2012-4-24 变更请求：需要添加2个人 审核结果：通过 现有库存：由于近期用户的商品需求量变大，造成现有库存出现了不稳定因素（入不敷出现象），故需要进行适当调整。仓管人员定要注意实时更新现有的设备号、现有数目、总书目、最大库存以及最小库存量，方便近期以及后期仓管人员以及用户的查询操作。 入库管理功能：由于需求量变更（濒临入不敷出现象）的出现，需要增加入库商品量，以维持库存的饱满，以便可继续正常运作。需增添1人仓管人员协助进行实时更新入库信息，观察现有库存量的操作，适当控制出入量平衡。 变更日期：2012-4-24 变更请求：需增添1人 审核结果：通过 还库管理：由于需求量变更的出现，在此期间定要做好还库信息的修改更新，以免造成入不敷出现象的加剧。 出库管理：由于出现需求量变更（濒临入不敷出现象）的出现，需要仓管人员仔细做好出库登记，在入库量还没有得到相应改善之前，需要减少用户零散的商品需求，对此致以歉意。值得注意的是，仓管人员切记要做好出库信息更新以及还库信息的登记。 查询管理功能：由于目前需求量的变更，运作上同样需要进行一定量的调整。在此期间，用户以及D公司的仓管人员对现有库存查询、入库查询、出库查询、紧销商品查询、滞销商品查询量激增，故需要1-2名人员协助参与查询管理，以维护系统，查漏补缺。 变更日期：2012-4-24 变更请求：需要1-2人 审核结果：通过 采购计划管理：由于需求量的变更（濒临入不敷出现象）的出现，需要适度的加大采购量，故需要增添2-4名采购人员，以协助采购管理员获取订单，收货以及入库操作的顺利进行。变更日期：2012-4-24 变更请求：需要增添2-4人 审核结果：通过
项目需求变更分析和解决之道
一、令人烦恼的需求变更 作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。甚至要重新设计现有的架构。 而面对这种情况，作为项目经理的你是否会说：“我们无法拒绝客户，但也无法立即满足他的新需求，所以只好是推到以后再进行完善。”或者，更极端些的想法：客户总是在异想天开，客户的需求在技术上根本无法实现…… 在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。因为在一开始已经多次和客户沟通，也在没有任何异议的情况下得到了明确的答复，但当开发项目在不断演进，客户对系统的理解逐步加深之时，他们最终还是推翻以前自己想要的需求。而这时你会认为对于需求，只有获取，没有确认。 而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。你还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求变更只会令项目组中的开发人员疲于奔命，无所适从。 在你的软件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次软件项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更？ 首先，这种想法和认识是错误的，软件项目开发中的需求变更是不能被完全消除的。无论是项目经理还是项目开发人员，最好在项目开始之前就消除这种想法。需求变更是不可能被消除的，而“消除需求变更”的想法却需要被消除。消除需求变更的所有的努力和想法，在项目开发进行中通常都是费力不讨好。 项目开发过程中，需求的变更是不可避免的 虽然一般情况下，项目经理花费了大量的心力和气力去避免需求变更，可最后需求变更总是会出现。但这并不意味着项目不应该做这方面的工作，无论是项目经理，还是开发人员对于需求变更的正确态度应该和对待软件测试的态度一样，在需求变更发生之前尽量减少需求变更发生的情况，以将需求变更带来的风险降到最低。 二、需求变更的产生原因 在软件开发项目中，需求变更可能来自方案服务商、客户或产品供应商等，当然，也可能来源于项目组内部。 对于需求变更发生的原因，细细追究起来无外乎以下几种原因： 1、范围没有圈定就开始细化 细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。 当细化到一定程度并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是人工手动添加的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。 2、没有指定需求的基线 需求的基线是指是否容许需求变更的分界线。 随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来，是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少）。 3、没有良好的软件结构适应变化 组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻
需求变更流程
需求变更流程
关于本文档 说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
1需求变更 需求变更的提出原因可能是随着对需求的理解越来越到位而增加的需求，或者相关规章制度法律法规发生变化而引起需求变换，对于项目而言提出需求变更都是正常的。 1.1目的 需求发生相应的变更，一般指《需求规格说明书》用户确认，形成需求基线，建立基线后的需求增删改都称为需求变更，即意味着项目组资源要进行调整，工期要推迟，甚至以前的设计要推翻，修改前期的工作成果，如果需求没有管理，没有控制的都被采纳，这个项目永远没有完结，所以一定要进行需求变更管理。 1.2流程 需求的增加、修改、删除统称为需求变更。 1、如果用户需要变更需求，则填写《需求变更申请》，经业务部门和信息技术部门 审核通过后，发邮件给项目组需求负责人； 2、《需求变更申请》的项目组接收者，录入此变更请求到《问题跟踪清单》，并标 识“问题类型”； 3、需求或问题的接收者判断是新增需求或需求变更，不得擅自接受，提交和项目经
理和相关人员进行内部变更评估、审核。 4、内部评审通过的，大的（开发工作量大于3人天）需求形成变更部分的《需求规 格说明书》，小的（代码修改开发工作量小于等于3人天）需求变更记录入《需 求问题跟踪》，（并且修改评审过的《需求规格说明书》），制定开发计划； 5、新的《需求规格说明书》进行评审，进行需求跟踪，直到需求关闭； 6、审核通过的《需求规格说明书》，确定开发时间和纳入的版本，制定开发计划 7、如果没有得到变更批准，则由项目经理，分配人员对《需求问题跟踪》直接修改 状态，解释说明拒绝原因，此需求关闭； 1.3输出 《FI-项目组编码-RM-需求变更申请YYYYMMDD》 《FI-项目组编码-RM-需求问题跟踪》 《FI-项目组编码-SPE-需求规格说明书》 项目组变更流程参考： 提出变更--> 内部变更评审→外部变更评审（可选）→变更批准→执行变更 1.4角色和职责 分公司业务部门： 职责：如申请新增、变更需求，提供原始需求及需求变更申请 入口： 出口：需求的相关信息及业务需求、《需求变更申请.doc》。 总公司业务部门及信息技术部门： 职责：对新需求进行整理、汇总、评审；确定结果返给项目组 入口：原始需求变更、《需求变更申请.doc》 出口：评审通过或评审未通过的变更需求，《需求变更申请.doc》 项目组需求负责人： 职责：1、对业务部门整理的需求变更进行评审；要注意此变更对项目组的项目风险、工作量、影响范围等因素。 2、测试系统实现，反馈评审结果，是否批准。 3、对设计开发组的需求设计文档进行评审。
需求变更分析报告
目录 变更—YH_01 .................................................................................. 错误!未定义书签。 需求变更ID ...................................................................... 错误!未定义书签。 变更描述........................................................................... 错误!未定义书签。 变更提出人....................................................................... 错误!未定义书签。 变更提出时间................................................................... 错误!未定义书签。 变更重要程度................................................................... 错误!未定义书签。 影响分析........................................................................... 错误!未定义书签。 对当前项目的影响.................................................... 错误!未定义书签。 对项目工时的影响.................................................... 错误!未定义书签。 对项目成本的影响.................................................... 错误!未定义书签。 对其他需求的影响.................................................... 错误!未定义书签。 可能要变更的其他组件............................................ 错误!未定义书签。
《××项目软件需求变更说明书》
软件需求变更说明书 项目名称：长益高速收费数据分析系统 一、概述 因湖南省高速公路联网拆分系统软件升级，导致长益下属收费站入口和出
口交易数据、拆分数据、代收拆分数据无法获取。而现阶段省高管局监控中心无法在上报报表日期内提供拆分数据，从而导致长益高速收费数据分析系统无法输出相关报表。经过深入了解和分析，在与业主方多次探讨后，提出以下变更说明。 二、变更内容 MTC实收和流量 原始情况： 人工收费系统出口站收费数据和出口流量的导入，是由收费站工作人员从站级拆帐网下载的“收费数据统计报表”并再录入部分细分数 据，导入长益收费数据分析系统。 变更后： 收费站工作人员在分析系统中MTC实收功能模块中只录入出口各车型实收收入、各车型流量、免费车流量、绿通车流量、系统外收入、 绿通车减免金额、免费车减免金额、手工票金额。 运营部工作人员在分析系统中MTC实收功能模块中导入本路段各站进，其他路段出的代收流量的各车型估算流量。其中包括各车型流量、 绿通车流量、免费车流量。 MTC实得 原始情况： 人工收费系统实得数据的导入，是由收费站工作人员从站级拆帐网下载的“拆帐统计报表”，导入长益收费数据分析系统。 代收实得的导入，是由运营部工作人员从拆帐网下载的“长张高速
公路联网收费实际分配收入统计表”，导入长益数据分析系统。 变更后： 运营部工作人员在分析系统中MTC实得功能模块中导入估算MTC各车型拆分收入。其中包括本路段各车型收入、系统外收入及代收业主各车型收入、系统外收入。 报表输出 由于原始基础数据的变更，所导致从数据模型上的建立发生了变化，从而将导致原长益数据分析系统输出报表无法根据原来基础数据的数据输出，需要转换为估算的数据输出，需要对所有的报表进行修改。 需要修改的报表有以下： ?公司－绿色通道车辆 ?公司－收费站拆帐情况表 ?公司－单车收费标准计算表 ?公司－流量对比表 ?公司－各类车流量收入比重对比图 ?公司－各类车流量收入比重表 ?公司－实征率 ?公司－高速免费车 ?公司－收费车流量统计 ?公司－ETC收费车与免费车 ?公司－月流量分析 ?公司－ETC征费情况 ?公司－月收入图 ?公司－月收费情况总表 ?公司-收费车流量与收入统计 ?路劲-收入影响因素对比表 ?路劲-项目每月输入及车流汇总表 ?路劲-各站每月收入及车流汇总表 ?路劲-历年路费收入图 ?路劲-历年次票车流量图 ?路劲-日报 ?省局-交通流量统计月报表 ?省局-绿色通道和免费车
需求评审规范
需求评审规范 变更记录
目录 一、概要 (3) 1、规范化需求评审的目的 (3) 2、明确需求评审目的 (3) 3 、明确需求评审的与会人员 (3) 4、每周需求评审次数 (3) 二、评审准备 (4) 1、人员职责 (4) 2、材料 (5) 3、内部评审 (6) 4、准评审条件 (6) 三、会议流程 (6) 1、评审中 (6) 2、准出标准 (7) 3、评审后 (7) 四、需求变更 (8) 1、准更时间 (8) 2、需求变更来源 (8) 3、需求变更类型 (8) 4、需求变更审核 (8) 5、需求变更同步 (9) 6、变更申明 (9) 7、特殊说明 (9)
五、声明 (9) 一、概要 1、规范化需求评审的目的 1.1、提升需求质量，保障产品质量； 1.2、提高评审会议效率和质量； 2、明确需求评审目的 2.1、让技术及测试对产品方案有详细的了解，以便后续开发更高效； 2.2、让与会者清晰的知道自己在整个发开过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期； 2.3、需求评审只对本次需求进行讨论，不深入，不发散。 3 、明确需求评审的与会人员 3.1、提前核实和通知本次需求参与的相关人员 4、每周需求评审次数 4.1、提前询问测试本周是否有时间进行需求评审，不要因为需求评审而导致测试计划打乱。 4.2、原则上需求评审每周最多2次。
二、评审准备 1、人员职责 产品： a）准备《产品需求文档》《产品原型文件》《美术需求文档》《美术效果图》。 b）编写《产品需求文档》《产品原型文件》时提前和相关的程序负责人进行沟通，将一些不确定的方案给确定下来，探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，提前将这些工作做好，确保需求评审会议的高效。 c）涉及运营的需要和运营提前进行沟通，确定运营需求细节并明确是否需要运营平台支持。 d）《美术需求文档》要和美术详细描述需求，明确功能。在需求评审前制作出效果图。 f）至少提前一天将资料以邮件形式发出并通知与会人员，让与会者提前查看。 g）会议的发起至少提前半天进行通知，最好是和资料一并提前1天发送，好做好提前的协调，保证都能准时参会。 开发： a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。 b）对技术可行性进行分析，能不能做，成本多大规模，有多大风险。
需求变更分析报告
目录 变更—YH_01 (3) 需求变更ID (3) 变更描述 (3) 变更提出人 (3) 变更提出时间 (3) 变更重要程度 (3) 影响分析 (3) 对当前项目的影响 (3) 对项目工时的影响 (4) 对项目成本的影响 (4) 对其他需求的影响 (5) 可能要变更的其他组件 (6)
变更—YH_01 需求变更ID 编号：YH_01 标题：可以上传多个课程交流附件 变更描述 描述：教师用户经过慎重考虑决定提出需求变更，要求在课程交流内可以上传多个附件（1—3个） 变更提出人 教师用户代表 变更提出时间 2016年12月20日15:30:00 变更重要程度 较大 影响分析 对当前项目的影响 该需求用例是公共用例，并且附件上传功能在项目要求中明确提出，此次需求变更由教师用
户代表提出，所以项目小组必须要将这次需求变更与客户代表，学生代表交涉沟通。而且这个需求变更还会涉及多个其他需求，也需要和其他用户代表确认。如果该需求变更通过，将会给项目组增加工作量。增加的工作内容主要是用例文档中的需求用例的删除、修改，界面原型中的相关界面的修改，同时导致用户手册中相应操作介绍的修改，导致测试用例文档中相应测试用例的修改。 对项目工时的影响 因为需求变更需要与其他用户代表沟通确认，修改相应的文档、界面原型等，可能会延长项目工时： 沟通确认需求变更——1d 修改用例文档——0.5d 修改界面原型——0.2d 修改需求工程计划——0.3d 修改测试用例文档——0.5d 更新软件需求规格说明书——0.2d 维护需求变更空难告知文档——0.3d 合计——3d 对项目成本的影响 项目成本的增加成本主要是人员工时增加
软件开发项目需求变更的管理
软件开发项目需求变更的管理 变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。 需求变更管理的需求 需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。 需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式;或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。 这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚
至导致整个项目失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。 六大原则 实施需求变更管理需要遵循如下原则： 1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 2.制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。 3.成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB 由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。 4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。 5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。 6.妥善保存变更产生的相关文档。 应对之道 需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程，笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策： 相互协作很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。 充分交流需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。 安排专职人员负责需求变更管理有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。 合同约束需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。 区别对待随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 选用适当的开发模型采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。