如何看待软件需求变更

A. 什么是需求变更

这对于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）确认客户是否接受变更的代价 要让客户认识到变更都是有代价的，要和客 户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户 认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果，通过与客户的协商，项目组可能会得到回报或者即使没有回报也不会招致公司和客户双方 的埋怨。 如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会 取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更，更不是所有的需求变更都需要立刻修改。客户一般对ERP不甚了解，他们认为很 简单的事情，但可能解决起来会很复杂。以笔者的经验来看，一般来说用户的镀金需求可以延期解决甚至不考虑。用户的新增需求如果不是影响到核心业务的实现， 也可以安排在现有功能的完善之后。 （6）每月变更记录上报双方领导 最后，实施顾问要将有关变更措施和记录随时抄报双方最 高层留档备案，可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权，逐步让不合理的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常 的项目执行氛围和良好的工作习惯，也为可能受到变更所带来的责任问题留下伏笔。

B. 如何有效控制需求变更

需求变更对软件开发项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。 （1）明确合同约束，建立需求基线 需求变更给软件开发带来的影响有目共睹，所以在与客户签订合同时，可以增加一些相关条款，如限定客户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。虽然软件开发合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。 明确和树立需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（客户参与评审），建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线，做到小需求可以变更，但大方向要力保不频繁变更。例如，对于项目中的需求，可以实行分级管理，以达到对需求变更的控制和管理。 （2）建立变更审批流程 在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低开发效率，浪费时间。正是这种观念才使需求变更变得不可控，最终导致项目的失败。因此，小的需求变更也要经过正规的需求管理流程，否则会积少成多，积重难返。 明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变更不予受理。 （3）分级管理变更，定时批量处理 软件开发项目中，“客户永远是对的”和“客户是上帝”并不完全正确，因为在已经签定的项目合同中，任何新需求的变更和增加除了影响项目的正常进行以外，还影响到客户的成本投入收益。因此，用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。 当遇到客户提出需求，不及时处理可能会使项目不能验收通过时，也不能一味拒绝不予开发。因此，当客户坚持变更新需求时，可以建议客户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。例如，每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目进度。针对会议结果可向客户正式提交一份需求变更计划，注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划，确定变更时限，控制变更规模，过时变更不候，离谱变更不做，保大局弃小变。 （4）安排专职人员负责变更管理 有时开发任务较重，开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此，需要安排一名专职的需求变更联络人员，负责与客户及时交流，跟踪和汇报需求变更完成进度和情况。同时，可以成立项目变更控制小组，负责裁定接受哪些变更，小组由项目所涉及的多方人员共同组成，应该包括客户方和开发方的决策人员在内。 （5）确认客户是否接受变更的代价 要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的（不是其上级领导拍脑袋提出的）就会接受这些后果。通过与客户协商，这样开发团队即使没有回报，也不会招致公司和客户双方的埋怨。 如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止频繁变更，也让客户认识到不是所有的需求都需要变更。

C. 如何正确对待需求的变更

软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。 软件需求变更会给项目带来巨大的风险,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而需求变更在软件开发项目中应该尽量避免。然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更，而这些因素往往不可避免。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。因而，对于需求变更应该正确的对待，尽量将其负面影响降低到最低。 2、减少需求变更 正如前文所说，需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求并更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。 相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。 让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和客户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合客户需求的软件，因此需求分析人员除了记录客户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助客户提出需求。在需求分析时，尽量多的召集需求研讨会，邀请开发人员和客户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。在需求开发时，开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。 虽然需求不可能是完备的，但是在项目开始设计时尽量使得需求完备还是应该的，也是值得的。 3、规范文档 需求文档作为客户和开发人员的接口在整个项目开发过程中起着举足轻重的作用。需求文档应该按照一定的格式和规范书写，而且应该具备完整性、一致性、基线控制、历史记录等特性。文档书写完毕以后应该交给客户审阅，在客户满意的基础上确定基线。一个完整规范的需求文档不仅能够有助于设计人员和编码人员完成项目开发，更重要的是它作为一个阶段性的成果可以供软件需求变更时参考。 需求变更发生后，也应该生成相应的文档，并且这些文档的书写也应该采用规范的形式书写。需求变更文档也应该包含基线以供下一次修改参考，还应包含历史记录以供开发人员和客户清楚当前的文档内容的新旧以及历史文档的情况，以备以后查看。 4、设计良好的体系结构 开发软件就如同建造一座房屋，软件体系结构则如同建房屋时的规划。两层高的家庭住宅和几十层高的商业大厦建造时的规划必然不同，同样，大型软件和小软件采用的体系结构也必然有所区别。因此，设计一个合理的体系结构对于项目的成败也是十分关键的。 体系结构的建立一般位于需求分析结束之后，软件设计之前。软件体系结构的设计是从结构的角度对整个系统进行分析，选择合适的构件，安排构件间的相互作用以及他们之间的约束，形成一个系统框架以满足用户需求。在设计软件体系结构时，不仅应该想到如何完成满足现在已经提出的用户需求，同时也应适当地考虑到需求的变更。 采用有弹性和可扩展的软件体系结构设计可以有效地降低需求变更引起的风险和维护代价，能够在项目范围未发生变化的前提下很好地适应需求的变化。体系结构的灵活和可扩展性设计使得开发者可以在这种体系结构上面进行各个功能层的组合和分离，也可以将各个功能层分布在各个不同的服务器上共同提供服务，因而能够快速的对需求变更作出响应，并且对已经开发好的系统产生尽可能少的影响。 体系结构的设计除了考虑到体系结构的灵活性和可扩展性以外，还应尽量采用松散耦合的结构，使得结构中的各个构件之间的关联程度尽可能的少，这样就能在需求发生变更时一个构件的变化对另一个构件产生尽可能少的影响。 现有的软件体系结构很多，包括管道－过滤器结构、B/S结构（含C/S结构）、解释器/虚拟机结构、黑板系统以及基于中间件技术的体系结构。在设计体系结构时，首先应该选出适合项目需求的系统结构，然后在从中挑选出那些扩展性比较好，构件之间耦合性比较小的体系结构。基于中间件技术的体系结构就是扩展性比较好的体系结构。采用中间件技术，中间件作为用户界面和操作系统以及网络的连接点，向上为用户提供服务，向下屏蔽操作系统和网络的细节。这种分层的思想能够很好的适应操作系统和网络的变化，可扩展性十分的好。同时，可以在中间件中给出容易改变的接口或是为系统将来改变预留接口来实现功能上的需求变更。当然可扩展性比较好的体系结构远不止基于中间件技术的体系结构这一种，具体的选择和运用应该由设计人员根据实际需要考虑。 5、采用面向对象思想 需求是不稳定的，因而没有不变的需求，然而需求之中却有稳定的东西，这就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物、植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。 面向对象（OO）技术的三大特征保证了采用OO技术可以建立易于改变和加强可重用性的软件系统。封装可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单；继承可以使改变基于原有技术基础，很大程度上减少重复开发工作；多态的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为。 显然，OO技术是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。因此，在系统开发过程中应该尽量的采用面向对象的思维方式来构建系统和开发系统。 6、需求变更控制 正如前文所言，需求变更不可避免的会发生，那么当需求变更发生后项目开发人员应该如何应对呢？ 一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理也比较容易。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求的需要的成本，包括时间、人力、资源等等方面，再与客户商讨是否有必要进行变更和如何在最小代价下实现变更。 当客户确实希望进行需求变更时，可以让开发人员开发一个快速原型，让用户体验一下，以确保客户确确实实的希望添加这些需求。在客户和项目开发人员共同确定了需求变更后，项目开发人员应该与客户签订一份新的合同。 当客户提出需求变更并且签订了合同后或是开发人员根据市场和国家政策作出的需求变更得到确证后，项目开发人员应该决定何时实施这些变更。对于那些对系统影响不大和一些优先权十分高的需求变更可以立即在项目中实施，而对于那些对于整个系统现阶段的开发影响很大，而且又不是十分紧急的需求可以放在下一个版本中进行。无论是立即实施还是放在下一个版本中，都应该给新的需求一个充足的开发和测试时间，保证产品质量。 结论 在面对需求变更时，除了通过减少需求变更和规范文档，从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们设计的意识和对需求变更的理解，做好对需求变更的控制和管理，做到对需求变更的灵活应对，在一定程度上降低维护代价和提高用户满意度。

D. 谈谈如何应对软件开发中的需求变更

看软件开发到什么程度, 以及需求变动的大小了
如果需求变动很大, 开发完成度很低, 可以考虑推到重来
如果只能采用"修改"的方式, 一般第一件事一定是背后里使劲骂人....

E. 如何正确对待软件测试需求的变更

软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。 软件需求变更会给项目带来巨大的风险，会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而需求变更在软件开发项目中应该尽量避免。然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更，而这些因素往往不可避免。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。因而，对于需求变更应该正确的对待，尽量将其负面影响降低到最低。 2、减少需求变更 正如前文所说，需求变更往往是不可避免的。通常是项目负责人员花费了大量的气力避免需求变更，可最后需求变更总是会出现。但是这并不意味着项目开发人员不应该做这方面的工作，项目开发人员对于需求变更的正确态度应该和软件测试的态度一样，在需求并更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。项目开发人员切忌在项目设计之前试图消除需求变更，这样做往往费力不讨好。 相比于需求开发人员而言，客户可能对需求变更认识不足，认为他们出钱，程序员或软件开发公司就要为它服务，因此客户对需求变更往往将需求变更视为儿戏，随个人喜好随意变更需求。因此，在需求人员同用户代表或用户部门主管人员接触时，就应该向他们挑明态度，和他们协商好，特别是应该让他们清楚软件的定价应该与软件的功能相关，以及需求随意变更所带来的风险的承担者应该由客户和项目开发者共同承担。通过这样做，让客户在需求分析之前就尽量对他们所需要的功能有个整体的了解和确定的思路，而不是等到程序员开始编码了，才提出以前原本在需求分析时就可以提出的需求。 让客户明白减少需求变更的重要性后，需求分析人员应该采取合适的方法同客户交流，帮助他们明确他们的需求。需求分析人员和客户的关系不应该仅仅是记录人员和需求提供者，他们的关系应该更多的是战略合作伙伴关系。虽然需求分析人员和客户存在着服务商和顾客的关系，但是他们有着一个共同的目标：开发出适合客户需求的软件，因此需求分析人员除了记录客户提出的需求以外，还应和用户讨论，提出一些建议，使用合适的工具帮助客户提出需求。在需求分析时，尽量多的召集需求研讨会，邀请开发人员和客户共同协商探讨，在研讨会上允许任意的提出需求，并将这些需求整理成档后由客户代表和需求分析人员共同商议可选的功能，这样能够尽量使得需求完备。在需求开发时，开发人员采用原型的方法启发客户思考功能需求也不失为一个好办法。 虽然需求不可能是完备的，但是在项目开始设计时尽量使得需求完备还是应该的，也是值得的。 3、规范文档 需求文档作为客户和开发人员的接口在整个项目开发过程中起着举足轻重的作用。需求文档应该按照一定的格式和规范书写，而且应该具备完整性、一致性、基线控制、历史记录等特性。文档书写完毕以后应该交给客户审阅，在客户满意的基础上确定基线。一个完整规范的需求文档不仅能够有助于设计人员和编码人员完成项目开发，更重要的是它作为一个阶段性的成果可以供软件需求变更时参考。 需求变更发生后，也应该生成相应的文档，并且这些文档的书写也应该采用规范的形式书写。需求变更文档也应该包含基线以供下一次修改参考，还应包含历史记录以供开发人员和客户清楚当前的文档内容的新旧以及历史文档的情况，以备以后查看。 4、设计良好的体系结构 开发软件就如同建造一座房屋，软件体系结构则如同建房屋时的规划。两层高的家庭住宅和几十层高的商业大厦建造时的规划必然不同，同样，大型软件和小软件采用的体系结构也必然有所区别。因此，设计一个合理的体系结构对于项目的成败也是十分关键的。 体系结构的建立一般位于需求分析结束之后，软件设计之前。软件体系结构的设计是从结构的角度对整个系统进行分析，选择合适的构件，安排构件间的相互作用以及他们之间的约束，形成一个系统框架以满足用户需求。在设计软件体系结构时，不仅应该想到如何完成满足现在已经提出的用户需求，同时也应适当地考虑到需求的变更。 采用有弹性和可扩展的软件体系结构设计可以有效地降低需求变更引起的风险和维护代价，能够在项目范围未发生变化的前提下很好地适应需求的变化。体系结构的灵活和可扩展性设计使得开发者可以在这种体系结构上面进行各个功能层的组合和分离，也可以将各个功能层分布在各个不同的服务器上共同提供服务，因而能够快速的对需求变更作出响应，并且对已经开发好的系统产生尽可能少的影响。 体系结构的设计除了考虑到体系结构的灵活性和可扩展性以外，还应尽量采用松散耦合的结构，使得结构中的各个构件之间的关联程度尽可能的少，这样就能在需求发生变更时一个构件的变化对另一个构件产生尽可能少的影响。 现有的软件体系结构很多，包括管道-过滤器结构、B/S结构(含C/S结构)、解释器/虚拟机结构、黑板系统以及基于中间件技术的体系结构。在设计体系结构时，首先应该选出适合项目需求的系统结构，然后在从中挑选出那些扩展性比较好，构件之间耦合性比较小的体系结构。基于中间件技术的体系结构就是扩展性比较好的体系结构。采用中间件技术，中间件作为用户界面和操作系统以及网络的连接点，向上为用户提供服务，向下屏蔽操作系统和网络的细节。这种分层的思想能够很好的适应操作系统和网络的变化，可扩展性十分的好。同时，可以在中间件中给出容易改变的接口或是为系统将来改变预留接口来实现功能上的需求变更。当然可扩展性比较好的体系结构远不止基于中间件技术的体系结构这一种，具体的选择和运用应该由设计人员根据实际需要考虑。 5、采用面向对象思想 需求是不稳定的，因而没有不变的需求，然而需求之中却有稳定的东西，这就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物、植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。 面向对象(OO)技术的三大特征保证了采用OO技术可以建立易于改变和加强可重用性的软件系统。封装可以把问题影响的范围缩小，外部的变化要求对系统的影响可以限定到某个类层次或某些类层次中，从而改变系统的一部分相对简单;继承可以使改变基于原有技术基础，很大程度上减少重复开发工作;多态的应用可以使开发和设计人员在相对统一的接口下更改系统的实现细节，从而改变系统的行为。 显然，OO技术是一种增强软件可维护性、健壮性以及保持设计稳定性的一种分析和设计方法，可以在一定程度上快速对需求变更进行反应，并可相对减少需求变更需要的成本。因此，在系统开发过程中应该尽量的采用面向对象的思维方式来构建系统和开发系统。 6、需求变更控制 正如前文所言，需求变更不可避免的会发生，那么当需求变更发生后项目开发人员应该如何应对呢? 一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理也比较容易。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求的需要的成本，包括时间、人力、资源等等方面，再与客户商讨是否有必要进行变更和如何在最小代价下实现变更。 当客户确实希望进行需求变更时，可以让开发人员开发一个快速原型，让用户体验一下，以确保客户确确实实的希望添加这些需求。在客户和项目开发人员共同确定了需求变更后，项目开发人员应该与客户签订一份新的合同。 当客户提出需求变更并且签订了合同后或是开发人员根据市场和国家政策作出的需求变更得到确证后，项目开发人员应该决定何时实施这些变更。对于那些对系统影响不大和一些优先权十分高的需求变更可以立即在项目中实施，而对于那些对于整个系统现阶段的开发影响很大，而且又不是十分紧急的需求可以放在下一个版本中进行。无论是立即实施还是放在下一个版本中，都应该给新的需求一个充足的开发和测试时间，保证产品质量。 结论 在面对需求变更时，除了通过减少需求变更和规范文档，从分析和设计的角度通过采用合理的分析和设计方法适应需求变更以外，还应该改变我们设计的意识和对需求变更的理解，做好对需求变更的控制和管理，做到对需求变更的灵活应对，在一定程度上降低维护代价和提高用户满意度。

F. 软件项目管理实践之如何控制需求变更

需求变更的控制关键在于建立建立相应的控制组织、变更控制和跟踪系统以及规范变更流程，主要有：
1、建立组织。项目启动时，需要尽可能的与客户沟通，建立正式的对变更进行控制的组织，成员包括双方高层（挂名）、甲乙双方的项目负责人、相关的需求负责人等。如果客户认为无需单独设置这样的正式组织，也会要求客户指定项目的负责人，每个相关的业务科室指定一名需求负责人，这样做的目的是如出现变更可以很快的临时组建一个对变更负责的组织，并且可以找到相应的负责人；
2、建立变更控制和跟踪系统。建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流；经比较和选型，可以选用了JIRA作为变更控制和跟踪系统；
3、规范流程。甲乙双方的项目组成立后，根据角色定义，确定变更流程。
1）变更申请。系统界面如按钮的位置、字段的位置的细微调整，不涉及到业务规则，对基线基本没有影响的变更，由测试人员直接在变更控制系统中提出；其他如操作风格的较大变化、业务规则的变化等，均要求客户提出电子和书面的需求变更单；
2）变更评估。由项目组组织人员对变更进行变更的合理性分析，变更替换方案分析，工作量的估算以及涉及什么模块、影响什么模块等影响分析；
3）变更决策。根据上节确定的沟通策略，与客户沟通交流，确定变更的处理方式；
4）变更实施。由测试人员在变更控制系统中填写变更信息（状态：待处理），由系统分析员填写处理方法和影响分析后交由开发人员实施（状态：处理中）；
5）变更验证。测试人员根据变更控制系统的变更状态反馈（状态：已解决），待相应的版本发布后，对变更进行验证测试，这时候特别要注意的是记录该变更的修改是否引起了该模块或其他模块产生缺陷。通常，测试人员根据系统分析员在变更控制系统中标注的影响模块，逐一进行回归测试，以确保不影响原有模块的前提下变更已正确实施；内部测试完毕后，如系统已上线，则由客户相关负责人在模拟生产环境中进行验收测试；
6）沟通归档。变更验证后，测试人员关闭变更（状态：已关闭），项目经理告知客户已测试完毕，沟通发布时间并说明那些模块可能有影响以及发现问题的反馈途径和方式。

通过以上几种手段，如执行实施到位，基本可以有效的把变更置于控制之下。
最后，值得一提的是，变更实施或者系统缺陷修复涉及到多方面的人员，可能牵涉软件系统中的多个模块，处理和验证的流程复杂，沟通等管理成本高昂，如果变更和质量控制不好，会直接影响项目的进度和成本。

G. 如何进行软件需求分析

软件需求分析免费下载

链接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

H. 需求变更对项目的影响及如何降低需求变更管理

1. 需求变更对项目的影响：当客户提出新需求的时候，需求人员应该分析这些需求对项目带来的风险，得出双方实现变更需求需要的成本，包括时间、人力、资源等等方面。变更都是有代价的，在评估代价对于项目的影响中，要让客户了解变更的后果。变更之后面临的最大问题就是项目延期，和客户一起做判断：“我可以做修改，但您能接受后果吗？”。这样会出现三种可能：客户接受延期，项目组按照客户要求进行修改；客户不接受延期，并愿意将变更取消或者延到下个合同处理；客户不接受延期，但要求在合同要求完成时间点完成，这种情况很有可能项目失败。（第三种情况是在软件项目中出现最多，并且最让项目经理头疼，但是由于这个情况的分析很复杂，推荐项目经理参阅林锐博士的《如何管理软件企业》第二版，书中有详细阐述。）2. 需求变更管理不能降低需求变更，但能够控制和管理需求变更，需求变更管理是对变更的需求进行科学的管理，并规范流程。需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增减、客户对功能的需求改变等。在软件项目中，变更可能来自客户方、供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因： 业务不熟悉，范围没有圈定就开始细化； 缺乏需求开发（需求调研、分析）能力； 流程不规范，缺乏需求变更管理流程，没有建立需求基线等； 没有区分好合同外的变更。项目经理必须面对这个现实：需求变更是不可避免的。项目经理应该做的，是如何针对可知的变更的来源进行预防，是如何在发生需求变更的情况下尽量减少其对项目的影响。

I. 为什么在软件开发过程中需求变更是不可避免的

我想说，你知道啥是你说说的需求么？
举个例子说：
某家公司开发一款OA系统，首先他们公司有什么财务部啊，人事部啊，等等。
需求方真的是不可能一下子都想的那么全，他软件要啥功能。这是其一；
其二：在初步的需求上完成以后，需求方对OA 肯定有了更进一步的了解，这时候或许才能在上次的基础上明确需求的。

这个需求变更肯定是不不可避免的。实在想不通的话，你就想想你自己要做一款软件，你能一下把你的所有的需求和开发商说的明明白白的吗？你敢确定你提出需求后永远不变么？

希望可以帮到你！

J. 软件开发，需求变更怎么办

对于开发的时间周期、变更需求的后费用的添加、或者是设备使用等环节加以限定即可。