需求变更的管理流程
前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇需求变更的管理流程范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。
需求变更的管理流程范文第1篇
随着计算机的不断发展，软件开发工程应运而生。影响软件开发的效率因素多种多样，主要包括需求调研过程中理解产生的歧义、需求编写的不完整性、需求表达的二义性、以及需求的频繁变更等都将会影响到软件开发的最终结果。随着软件开发规模的逐渐扩大，软件需求分析与管理成为整体软件开发的关键环节，直接决定着软件开发的成败。在软件的开发过程中，只有设定清晰完善的需求开发与管理方案，才有助于软件设计、开发人员正确理解和确定软件的完整功能，从而达到客户需求的满意度。
本文将以软件需求工程为侧重点、从软件需求变更的原因、影响、原则及管理方案为研究领域进行分析和讨论。
一、软件需求变更的主要原因分析
1、客户需求因素。在软件的开发过程中，客户会随着项目开发的进程逐渐达成对软件系统的深入了解和认识，在不断的思考过后形成了新的需求信息或改进的需求信息，进而会提出满足其新需要的软件变更条款。2、系统内部因素。在软件开发过程中，计算机外部硬件设备、系统软件、系统数据等内部系统之间的相互适应要求都会引起软件需求的变更。这种需求变更将会以硬件设备、操作系统、系统软件等原始系统因素为基础进行更新、升级、换代，以此确定软件设计的安全性、兼容性和准确性。3、业务环境因素。在软件开发过程中，与软件开发相关联的制度、规范、政策等的重新改写与设定，或是软件开发业务要求的不断改变都将会引起软件需求变更。例如，软件的需求会随着保险制度的变化而变更，会随着交通制度的变化而变更等等。4、需求开发缺陷因素。在软件需求开发过程中，需求信息调查研究、需求文档的编写及评审等工作的不足都是影响软件需求变更的主要原因。
二、软件需求变更的主要影响分析
1、影响软件开发的实际进度。频繁的需求变更不仅需要大量项目人员的支持，还需要投入大量的经费，如果投入的力度过大，将会导致软件开发项目超过预期甚至导致失败。
2、影响软件开发质量的优良。在软件开发过程中，需求的不断变更将会导致原有的需求链断裂，对原定需求的部分环节造成影响，而这些影响又将导致软件开发项目设计的改变，最终导致系统质量的下降，开发效率的降低。
3、影响客户与开发者之间的相互合作。软件开发是客户与开发者之间的一种相互信任、相互合作的过程。如果二者之间在软件需求变更上产生不同意见，而且没有得到妥善的处理，将会导致二者之间的合作关系破裂，甚至造成软件开发中断等严重后果。
三、软件需求变更的处理原则
1、完整性原则。完整性是软件安全的基本要点。在软件开发过程中，要保证需求变更信息的采纳收集、汇总整理、评判审核、监视追踪等环节的完整性，保证软件需求变更能够按照规范的流程进行操作。
2、合理性原则。在软件开发过程中，客户与需求分析人员将会以不同的视角、不同的态度评估需求变更条件，要想达成软件开发的精确性，就需要在用户需求、软件技术和整体开发能力的基础上，达成需求变更的合理性，实际性。
四、软件需求变更的有效管理方案
1、达成开发者与客户之间的有效沟通。在发生软件需求变更时，需求分析人员要与客户进行及时有效的沟通和反复的确认，向客户说明开发建议和解决方案并制定相应的合同规范，以此来达成对客户的承诺和软件修改后的满意度。2、制定软件需求变更信息的整理报告。在软件需求变更过程中，要对客户需求的规范、变更后的功能、软件质量目标、变更解决方案等信息进行整理、分析和记录，制定明确的需求分析整理报告，以此来确保需求变更的准确性、实际性与科学性。3、进行明确、合理的人员分工。在需求变更达成协议后，就需要对开发人员进行合理的安排和组织，对操作人员和测试人员进行明确的分工；利用合理的需求变更管理工具，达成整体软件项目开发的高效和优质。4、做好需求和产品特性的评审和测试工作。做好需求变更相关信息的记录后，需求分析人员要组织开发、测试与客户等相关人员对更改后的需求进行评审和测试，筛出掉不符合实际的变更需求，确保需求变更流程的顺利进行。在软件变更实施的最后阶段，要对软件产品系统进行测试，以检验其是否满足客户的原定需求、是否达到了预期的效果和期望，以保证更改后产品系统的基准性和安全性。
总之，在出现软件需求变更状况时，首要的就是与客户做好沟通和协商，其次要做好需求变更信息的详细记录，最后做好软件需求变更后的测试。只要做好这关键的三部，就能够充分确保软件开发的规范化和优质化。
参 考 文 献
需求变更的管理流程范文第2篇
[关键词] 需求分析 需求变更 需求控制
一、问题的提出
什么是需求分析?
要知道需求变更是什么,首先要知道什么是需求分析。
需求分析是指理解客户需求,就软件功能与客户达成一致,估计软件风险和评估项目成本代价,最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。
什么是需求变更?
根据软件工程思想定义,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求,或对原有需求进行修改和削减,均属于需求变更。
二、需求变更的原因及影响
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)妥善保存变更产生的相关文档。
这六大原则看起来简单,但真正实施起来有难度,还需要依据理论知识配合开发项目组的实际工作情况,在实践中不断摸索总结。
四、总结
软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理,将需求变更的频次大幅度降低,从而为软件项目的顺利实施打下坚实基础。
参考文献:
[1]王 莉 吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展,2007,17(1):120～121
[2]王 强:软件开发项目中的需求变更管理[J].电脑知识与技术(学术交流),2007,(11)
需求变更的管理流程范文第3篇
北方工业大学教授
历任北方工业大学软件工程研究所、北方工业大学SEGUE软件测试中心、以及与中国医药设备工程协会合作建立了“中国医药设备工程研究服务中心”负责人。
有人说开发软件比建一幢大楼复杂多了，因为软件行业缺乏准确而又统一的语言来描述相应的工作。有些“需求”实际上存在于人们的头脑中，能否准确无误地用文字描述出来完全取决于客户对计算机软件的灵感和表达能力，而开发人员能否完整、正确地获取和理解客户的需求，取决于开发人员对客户业务的熟悉程度和IT行业经验。
所有的开发商和用户都希望获得高质量的需求，但是有许多因素影响需求的质量，下面我们详细分析影响需求质量的几个主要因素和解决方法。
用户需求不断变更
开发过程中需求不断变化，会使软件的整体结构越来越混乱，补丁代码使得整个程序难以理解和维护，破坏了软件模块高内聚、低耦合的设计原则。如果项目管理工作不完善，带来后果会更加严重。但是用户通常不是计算机专家，对需求变更导致的软件质量问题认识不足，所以，不论开发人员如何强调需求变更的风险，仍然无法阻拦用户需求的变更。
为了减少用户需求变更，可以从两个方面入手:首先，必须从一开始就对软件的范围、目标、规模、接口和成功标准给予明确的定义。其次，在项目管理上要制定需求变更控制流程，一旦用户需求发生变更，严格按照规范的流程进行一系列的分析和审查。通过这两种方法既可以有效地控制用户需求变更的随意性，又能够满足用户需求变更的必要性。
用户不配合
实际工作中，用户的热情参与是项目成功的重要因素。如果用户不热心，项目将无法成功。对待这个问题主要是与用户沟通，引导他们对项目感兴趣，可以将做过的一些成功系统给用户演示，提高用户的信任度也是有效的方法。
过于精简的需求说明
这是开发中最经常犯的错误。尽管开发人员和用户都认为应该花大精力进行需求分析，但在实际项目中仍然很难抵御编程的诱惑。在初始阶段，可将项目组成员分为两部分，一部分做需求工作，另一部分（主要是程序员）熟悉开发环境，攻克开发中可能遇到的技术难题，或者验证项目经理所担心的一些关键问题。在需求审查时，所有项目组成员都参加，由于后者没有参加需求分析，对用户需求了解甚少，他们对过于简单的需求描述往往会提出许多问题，帮助弥补需求说明的不足。
忽略用户分类
需求变更的管理流程范文第4篇
网站项目是以Web服务器为主体、浏览器为客户端作为基本架构的项目。这样的架构项目中包含Web服务器、浏览器和网络三个关键主体。网站项目可能是一个网站，也可能是各种Web应用程序，例如网上商店、虚拟邮局、网络办公管理系统、客户关系管理系统等等。网站项目管理就是围绕着网站项目运用知识、技术、技能、工具和方法进行组织管理。其特点表现在以下几个方面：
1）涉及的领域很多。狭义地讲，网站项目包括了网页制作、美工设计、程序编码、系统及网络管理等专业技术，广义上又包含了企业管理、市场营销、心理学、广告学等更多领域的知识，在项目进行过程中还涉及到项目管理工具、文档和设计开发管理规范、开发及测试环境部署等特殊领域的问题。这对参与项目管理的人员提出了很高的要求。
2）参与项目的角色很多，水平可能参差不齐。对于网站项目管理，最关键的角色是项目经理、业务流程分析师、用户界面工程师、系统分析员、编码人员（程序员）和质量控制工程师等。根据项目的规模和开发的深度，由项目经理进行角色划分。假如严格细分，一个大型项目的角色可能达到50个以上，以确保每个细节都有专业的人员进行负责和管理。其中需求分析过程中主要角色有客户代表、业务员、业务流程分析师、用户界面工程师，另外还有项目经理、数据库工程师、文档工程师等参与。
3）网络应用的开发技术在日新月异地进步，从而使网站应用系统的开发模式具有多种选择性，达到同样的目标可以采用很多不同的方式，现代的应用系统越来越成为一个庞大的集成方案，需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等，项目管理人员必须了解各种技术的利弊，帮助用户选择高效、廉价并富有前瞻性的方案。
2需求分析在网站项目管理中的作用及要求
需求分析是一个项目的开端，也是项目建设的基石。由于以上提出的网站项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，网站项目需求分析的重要性是不言而喻的，在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。
在需求分析流程中，需要有客户代表、业务员、业务流程分析师、用户界面工程师等角色参与，业务员从客户代表那里获得需求，并形成需求报告；业务流程分析员从业务员那里获得需求报告，分析生成项目模型报告；界面工程师得到项目模型后设计制作相应的模板和用户界面原型，最终由客户代表确认。需求分析所形成的文档最终达到如下要求。
1）正确性：每个功能必须清楚描写交付的功能。
2）可行性：确保在当前的开发能力和系统环境下可以实现每个需求。
3）必要性：功能是否必须交付，是否可以推迟实现，是否可以在削减开支情况发生时被“砍”掉。
4）简明性：不要使用专业的网络术语。
5）检测性：如果开发完毕，客户可以根据需求检测。
3网站项目需求分析的一般方法
根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。
第一阶段：“访谈式”。这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况和客观信息，建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。
实现手段：访谈、调查表格。
输出成果：调查报告、业务流程报告。
第二阶段：“诱导式”。这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际和客观信息的基础上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性，界面的便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和改进方法。
实现手段：拜访（诱导）、原型演示。
输出成果：调研分析报告、原型反馈报告、业务流程报告。
第三阶段：“确认式”。这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查报告来提出反馈意见，并对已经可接受的报告、文档签字确认。
实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统。
输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）。
整体来讲，需求分析的三个阶段是需求调研中不可忽视的一个重要部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了项目成功的保证。
4网站项目需求分析的注意事项和技巧
项目的整体风险往往表现在需求分析不明确、业务流程不合理，导致用户不习惯或不愿意去用承建方的软件。承建方和客户方都要重视需求分析的重要性。为更好地把握用户的需求和方向，应该采用必要的手段和方法来进行需求调研。
4.1挖掘用户需求
鼓励用户将所有的想法尽可能地阐述清楚，并把所有的要求罗列出来。这时候不必担心引起客户的潜在需求而增加设计开发的工作量，应直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都放到一边，将用户最原始、最完整的要求准确地记录下来。
很多情况下客户并非专业人士，在他们的描述中很难凸现重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。
比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时需考虑今后增加库存产品进销存统计分析等等；限于时间和财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。
4.2利用自然的语言和图表描述项目模型
在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然语言或形式化语言来描述，还可以添加图形表述方式和模型表征方式。虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。制作示意图可以有很多种方式，关键是利用示意图将客户的需求和即将开始设计的系统体现出来。在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程中。
4.3需求分析要共同参与各施其职
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同讨论，达成一致意见。参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。这样可以尽量避免业务人员与开发人员、承建方和客户方之间发生不必要的纠纷。
例如：项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期；开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；界面设计人员根据项目的性质和定位确定表现方式；测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测。
4.4将需求变更置于可控状态
需求的变更几乎是不可避免的，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的。如何以可控的方式管理网站项目需求的变更，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。
为了将变更及时反馈到项目的各个角色中，做好需求变更日志就显得非常重要。在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。在新版本的需求分析中，将变更部分用特殊方式表示出来，并在日志中记录变更明细。
4.5评审需求文档
需求文档完成后，需要经过正式评审，以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档时用户的意见是第一位的。而同行评审的目的，是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。
需求变更的管理流程范文第5篇
为使软件既能高效又能保质保量的完成，近几年来，软件开发单位采用专门的软件管理团队对软件进行规范管理，与此同时改进软件开发技术。软件规范管理从近年的9001B质量体系认证、GJB5000A软件过程改进以及软件工程化等都对软件开发的各个阶段产品进行了规范管理，地面测控软件的管理日益规范，不断改进。另一方面，为大幅度提高软件的研发效率和质量，可以采用软件复用技术。本文结合测控软件开发实践，对复用技术在测控软件中的有效应用进行初步研究。
2软件复用理论
2.1软件复用的概念
为避免程序开发“从零开始”以及重复相同的工作，采用已有的经验和成果，将开发的重点集中在应用系统的新研部分，提高工作效率和软件质量，这就是软件复用。复用形式包括基于构件的复用和基于过程的复用，基于构件的复用是目前主要的复用形式。
2.2软件构件及基于构件的软件开发
软件构件是软件复用的核心和基本单位，具有独立的功能，是可复用的软件组成部分，可供第三方进行软件组装。构件可以是被封装的对象类、类树、功能模块、软件框架、软件构架(或体系结构)、文档、分析件、设计模式等。基于构件的软件开发与传统的软件开发相比，基于构件的软件开发强调使用软件构件对软件系统进行设计开发。基于构件的软件开发方法需要有相应的软件开发过程作为基础，否则，就不会有与该系统相符合的质量特性要求的软件构件。
2.3软件复用的优点
（1）改善软件质量：经过测试以及经过实践的软件往往缺陷更少。（2）降低开发风险：开发新的组件，如果测试不够充分，轻则有效性不高，重则可能是造成软件失败的原因。（3）支持快速原型开发：快速构建实用可操作系统模型，凭借其与用户进行有效沟通，最终获得用户有效意见反馈。（4）提高软件开发效率，缩短软件开发周期，从而降低软件开发成本。
3软件复用在测控软件开发中的应用
近年来，随着任务数量的增多，测控软件的开发团队越来越小，软件开发周期越来越短，软件的研制要求却不断的提高；随着卫星工作模式的增加，地面接收设备也需增加相应的工作模式完成相应的接收任务。因此，测控软件不但需要完成原有工作模式的监控管理功能，还需完成新增工作模式的监控管理功能。测控软件必须有效继承原有成熟的计划管理、自动标校/测试及自动运行管理技术，同时需要开发适合新增工作模式的计划管理、自动标校/测试及自动运行管理技术，并且要为后续其它型号软件提供高效的功能继承。基于软件复用技术的测控软件开发，使用大量的已经过验证的高效软件，对传统瀑布模型的各个研制阶段的产品（如需求分析、软件设计、软件编码、软件测试）进行优化和简化，节省了人力和时间，提高了软件的可靠性，降低了软件成本和开发周期。在软件的研制过程中，需要对软件的复用架构进行设计，对可复用的构件进行适应性修改设计以适应新的软件需求，还需对新研的部件进行软件设计。测控软件对原有成熟的设备监控、计划管理、自动标校/测试及自动运行管理功能的继承，就成为软件的复用的内容。其中包括四个阶段的复用：需求复用、设计复用、代码复用、测试复用。
3.1需求复用
测控软件的变更原因主要有两种：（1）用户需求变更。（2）软件自身技术升级。其中，用户需求变更是导致软件变更的首要因素；软件技术升级的部分工作往往也是为了更好的适应用户的需求。首先，同类任务的需求是逐渐增加的，并且有一定的可继承性，当增加新的需求时，已验证过的任务需求即可成为后续任务需求的可复用的构件。其次，不同的测控任务需求之间同样存在相同或相似的元素。例如，任何一个任务都有相同或相似的任务流程；根据工作计划及自动运行策略进行站前标校、任务宏配置、启动自动运行流程；监控数据的存储、显示、查询等任务需求存在一定的共性，对其通用的任务需求，是完全可以复用或部分复用的。因此，任务需求变更与软件需求变更为因果关系，直至后续的各个阶段活动都受到任务需求变更的影响。从需求分析、软件设计、软件编码直至软件测试，都会因为任务需求的变更而必须进行相应的更动。
3.2设计复用
多年以来，很多任务的测控软件都有相同或相似的软件结构，因此，这一有利条件，在软件结构设计时，得到了充分的利用。从软件复用的角度来说，在进行软件结构设计时，需将软件中相对稳定的部分（如设备监控、数据库管数据库管理、计划管理、用户管理）与新增加的部分不仅从结构上分开，而且要求其接口相对单一稳定。这样，从软件设计到代码开发都可以复用。
3.3代码复用
对程序代码的复用，以设备的监控线程为例介绍如下：目前，测控站内设备通过局域网进行通信，各个设备与测控软件之间的通信接口都已进行了标准化，因此，对不同设备的监控线程可以进行代码复用；如果重新设计代码，不但要耗费大量的人力和时间，延长软件开发周期，而且重新设计的代码必须进行充分的软件测试，否则难以保证其正确性和健壮性。开发者使用以往可复用的程序代码，或全部吸收或加以优化，大大避免了重复性工作，将精力集中于关键技术的攻关，如此设计更加高效可靠的软件系统。
3.4测试用例复用
软件测试复用主要包括测试流程的复用、测试方法的复用和测试用例的复用。其中，测试用例的复用是测试复用中的关键技术。测试用例的复用对于缩短软件的开发周期和降低软件开发成本具有极其重要的意义。
4结束语
