软件开发项目的需求变更管理
摘要：本文讨论了软件开发项目的需求变更管理的知识，指出了需求变更管理在项目实施管理中的重要作用，并根据作者的项目实施经验，探讨了软件开发中需求变更管理的一些方法和经验。
关键词：软件开发项目需求变更管理
不是我不明白，这世界变化太快。计划赶不上变化，变化不可怕，可怕的是跟不上变化的步伐。在项目的实施中，客户的需求变化是常有的事，通过对项目范围的管理，可以有效地控制项目范围的蔓延，防止项目工期与成本、质量的增加。而在软件开发项目的实施中，用户的需求变化更是家常便饭，处理不好就会对项目造成极大的影响。
我在这几年所管理的软件开发项目的实施中，通过不断的实践和摸索，获得了一定的经验，我体会到，虽然在软件开发过程中需求的变更会给项目的实施带来不确定性，但只要把需求变更作为重点、难点小心加以控制、管理，软件开发项目的进度、成本和质量也能在我们的掌控之中。
去年，通过政府采购招标，我公司中标了我市的房产管理信息系统的软件开发项目，我作为该项目的项目经理，参与了该项目的分析、设计以及测试的工作。在项目实施的过程中，随着项目实施的不断推进，客户的需求也不断变化，让我们有点疲于奔命，不知所措，幸好我及时调整了项目实施的策略，注重了需求变更的管理，才使得项目最终能按期完成。
下面我就结合我在该房产管理软件开发项目的经历来说一下在软件开发项目中对需求变更的管理。
一、需求变更管理的需求
需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。
需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。在国内，这很正常，很多用户都不是专业人士，他们对自己的
业务很熟悉，但对计算机信息技术通常都是一知半解。用户常常以为自己对自己的需求很清晰，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改动他们的工作方式；或要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着系统开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的需求进行改动。他们了解得越多，新的需求也就越多，需求变更因此不可避免地一次又一次出现。
这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，或者不按变更控制流程来管理需求的变更，那么很可能造成项目进度拖延、成本上升、人力紧缺，更有甚者可能导致整个项目的失败。当然，即使按照需求变更控制流程进行管理，由于受项目进度、成本等因素的制约，软件系统的质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。
二、实施需求变更管理的六大原则
实施需求变更管理需要遵循如下原则：
1.建立需求基线。需求基线是需求变更的依据。在研发过程中，需求确定并经过评审后（用户参和评审），能建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
2.制订简单、有效的变更控制流程，并形成文件。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目研发和其他项目都有借鉴作用。
3.成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员一起组成，应该包括用户方和研发方的决策人员在内。
4.需求变更一定要先申请然后再评估，最后经过和变更大小相当级别的评审确认。
5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
6.妥善保存变更产生的相关文件。
三、应对之道
需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程，笔者在实际工作中总结出了软件研发人员在需求变更管理实践中的几点对策：
相互协作非常难想像遭到用户抵制的项目能够成功。在讨论需求时，研发人员和用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在研发人员看来"过分"的需求，也应该仔细分析原因，积极提出可行的替代方案。
充分交流需求变更管理的过程非常大程度上就是用户和研发人员的交流过程。软件研发人员必须学会认真听取用户的需求、考虑和设想，并加以分析和整理。同时，软件研发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个研发工作带来什么样的冲击和不良后果。
安排专职人员负责需求变更管理有时研发任务较重，研发人员容易陷入研发工作中而忽略了和用户的随时沟通，因此需要一名专职的需求变更管理人员负责和用户及时交流。
合同约束需求变更给软件研发带来的影响有目共睹，所以在和用户签订合同时，能增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更能接受、拒绝接受或部分接受，还能规定发生需求变更时必须执行变更控制流程。
差别对待随着研发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇见这种情况，研发人员能向用户说明，项目的启动是以最初的基本需求作为研发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。如果用户坚持实施新需求，能建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。
选用适当的研发模型采用建立原型的研发模型比较适合需求不明确的研发项目。研发人员先根据用户对需求的说明建立一个系统原型，再和用户沟通。
一般用户看到一些实际的东西后，对需求会有更为周详的解释，研发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式研发方法对工期紧迫的项目的需求变更控制非常有成效。
用户参和需求评审作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，能有效减少需求变更的发生。
四、项目经验
根据以上所述，我及时调整了项目实施的策略，按照项目范围管理的要求和步骤，与用户方进行沟通，根据合同条款，召集其单位领导及项目的其他干系人，认真详细地讨论了软件系统的功能需求，确定了功能子模块等，最终编制了范围说明书，并且双方签字确认。然后制定了范围管理的计划，在实施过程中对范围的变更进行严格的控制，用户提出的变更需求，需要经过双方讨论，对项目实施的进度及成本影响进行评估，经双方沟通确认后才能进行，而不是像原来那样用户想改什么都按其要求随时修改。
经过调整，项目改变了原来拖延的现状，在大家的努力下，终于按期完成了软件系统的开发和上线实施，效果很好，得到了用户的好评。
--------------------
参考文献：
柳纯录.信息系统项目管理师教程(第二版).北京:清华大学出版社，2008.1 张友生.陈志风.信息系统项目管理师考试全程指导.北京:清华大学出版社，2009.8
邓世忠等.IT项目管理（原书第二版）.北京：机械工业出版社，2004.11
E-Storage Management System Software Requirements Specification 电子化仓储管理系统软件需求规格说明书 版权所有不得复制 Copyright ? BroadenGate Technologies, Co., Ltd. All Rights Reserved
Revision Record 修订记录
Catalog 目录
错误!未找到引用源。 Keywords 关键词：仓储管理 Abstract 摘要：本文主要描述电子化仓储管理系统的设计需求，包括功能需求和性能需求，以及其他设计约束等。 List of abbreviations 缩略语清单：
1Introduction 简介 1.1Purpose 目的 1.2Scope 范围 本文档包含电子化仓储管理系统V1.0的对外接口和功能描述，以及和外部的约束关系。2General description 总体概述 2.1Software perspective 软件概述 2.1.1About the Project 项目介绍 2.1.2Environment of Pruduct 产品环境介绍 2.2User characteristics 用户特征 2.3Software function 软件功能 2.4Assumptions & Dependencies 假设和依赖关系 3Specific Requirements 具体需求
3.1Functional Requirements 功能需求 我们采用面向对象分析的方法来作为主要的系统建模方法，使用UML(Unified Modeling Language)作为建模语言。UML为建模活动提供了从不同角度观察和展示系统的各种特征的方法。在UML中，从任何一个角度对系统所作的抽象都可能需要几种模型来描述，而这些来自不同角度的模型图最终组成了系统的映像。 Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成时，该模型将来可 派生出动态对象模型。 设计Use-case时，我们遵循下列步骤： 第一步： 识别出系统的管理员。管理员可以是用户、外部系统，甚至是外部处理，通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能，并指明这些功能的执行者是谁。尽可能地确保所有管理员都被完全识别出来。 第二步： 描述主要的Use Case。可以采取不断地问自己“这个管理员究竟想通过系统做什么？”来准确地描述Use Case。 第三步： 重新审视每个Use Case，为它们下了详尽的定义。 电子化仓库管理系统是通过对入库业务、出库业务、仓库调拨、库存调整业务信息的管理，提高仓库管理信息的实时性和准确性，达到即时库存管理的功能，并有效控制并跟踪业务的物流和成本管理全过程，实现完善的企业仓储信息管理。系统中设计了装箱算法，为客户提供合理有效的装箱方案，保证了货物集装箱的利用。本系统可以提供有关库存情况的准确信息，增强了作业的准确性和快捷性、减少了整个物流中由于商品误置、送错、偷窃、损害和库存、出货错误等造成的损耗，并最大限度减少存储成本。 总体功能时序图：（如图3-1所示）
产品需求管理中的需求 变更 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，冻结时间点
附2: 软件文档编写向导 文档分类 项目包括如下几类文档： 项目管理文档。包括：《软件项目计划》、《项目进度报告》、《项目开发总结报告》 软件开发文档。包括：《需求规格说明》、《概要设计说明》、《详细设计说明》、《测试计划》、《软件测试分析报告》。 产品文档。包括：《用户操作手册》《演示文件》。 软件项目计划 （Software Project Plan） 一?引言 1?编写目的（阐明编写软件计划的目的，指出读者对象。） 2?项目背景（可包括：（1 ）项目委托单位、开发单位和主管部门；（2）该软件系统与 其他系统的关系。） 3?定义（列出本文档中用到的专门术语的定义和缩略词的原文。） 4?参考资料（可包括：文档所引用的资料、规范等；列出资料的作者、标题、编号、发 表日期、出版单位或资料来源。） 二?项目概述 1.工作内容（简要说明项目的各项主要工作，介绍所开发软件的功能性能等?若不编写可行性研究报告，则应在本节给出较详细的介绍。） 2.条件与限制（阐明为完成项目应具备的条件开发单位已具备的条件以及尚需创造的 条件?必要时还应说明用户及分合同承包者承担的工作完成期限及其它条件与限制。） 3.产品 （1）程序（列出应交付的程序名称使用的语言及存储形式。） （2）文档（列出应交付的文档。） （3 ）运行环境（应包括硬件环境软件环境。） 4?服务（阐明开发单位可向用户提供的服务?如人员培训安装保修维护和其他运行支持。 5.验收标准
三.实施计划 1.任务分解（任务的划分及各项任务的负责人。） 2?进度（按阶段完成的项目，用图表说明开始时间完成时间。） 3?预算 4?关键问题（说明可能影响项目的关键问题，如设备条件技术难点或其他风险因素，并说明对策。） 四.人员组织及分工 五.交付期限 六.专题计划要点（如测试计划等。） 项目开发进度报告 一.报告时间及所处的开发阶段 二.给出进度 1.本周的主要活动 2.实际进展与计划比较 三.所用工时（按不同层次人员分别计时。） 四.所有机时 五.工作遇到的问题及采取的对策 六.本周完成的成果 七.下周的工作计划 八.特殊问题 项目开发总结报告 一.引言 1.编写目的（阐明编写总结报告的目的，指明读者对象。） 2.项目背景（说明项目的来源、委托单位、开发单位及主管部门。） 3.定义（列出报告中用到的专门术语定义和缩写词的原意。） 4.参考资料（列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括： （1 ）项目开发计划；（2 ）需求规格说明书；（3 ）概要设计说明书；（4 ）详细设计说明
需求说明书 目录 1. 引 言 ........................................................................................................................................... ...................... 4 1.1 编写的目 的 ........................................................................................................................................... 4 1.2 背 景 ........................................................................................................................................... ............ 4 1.3 项目专用术 语 (4) 1.4 参考资 料 ........................................................................................................................................... . (4) 2. 任务概 述 ........................................................................................................................................... .............. 5 2.1 目 标 ........................................................................................................................................... ............ 5 2.2 运行环 境 ........................................................................................................................................... .... 5 2.3 条件与限 制 (5) 2.4 工作流 程 ........................................................................................................................................... . (5)
需求变更的代价 让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决 定调整所有界面，Steven只好立刻动员大家抓紧时间修改。可后来当听说因修 改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会 让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。对软件需求和需
变更管理流程 1概述 .......................................................................................... 错误!未定义书签。2变更流程 .. (2) 2.1摘要 (2) 2.2提交变更申请 (4) 2.3审核变更申请 (4) 2.4识别变更可行性 (4) 2.5批准变更申请 (4) 2.6实施变更申请 (5) 3变更任务 (5) 3.1变更申请人 (5) 3.2变更经理 (5) 3.3变更可研小组 (5) 3.4变更审批小组 (5) 3.5变更实施小组 (6) 4变更登记 (6) 5变更模板 (6)
1 概述 描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如： 变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。 对项目的变更管理是通过对以下五个关键步骤的实施引入的。，: ?提交和接收变更申请 ?审核和记录变更申请 ?确定变更申请的可行性 ?批准变更申请 ?实施和结束变更申请 2 变更流程 对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project. An example follows: 2.1 概要 下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。
软件系统开发需求分析模板 1. 引言 1.1 编写目的 本系统的开发目的在于更好的管理和经营酒店餐饮行业。本文档的预期读者是酒店管理系统软件开发有关的开发人员。 1.2 项目背景 本项目的名称：酒店管理系统。 随着国民经济的发展，酒店餐饮行业的队伍在全国范围（尤其是在经济发达地区）不断壮大，从事酒店餐饮行业的单位之间竞争愈加激烈。为了提升自身的竞争能力， 各酒店餐饮单位都在尽量定制或购买各项业务的应用软件，运用高科技手段进行经营 和管理。为了让酒店更好的经营，我们组织开发了本软件。 本项目的任务提出者及开发者是酒店管理系统软件开发小组，主要是面向酒店餐饮服务行业。 1.3 定义 酒店管理系统是帮助酒店自身管理和服务酒店客户的软件。 1.4 参考资料 ①《现代软件工程》北京希望电子出版社孙涌等编著 ②《Delphi住宿餐饮管理系统开发实例导航》人民邮电出版社 刘敬严东明马刚编著 ③《软件需求说明书（GB856T——88）.doc》 ④《iso标准之需求分析说明书.doc》 2.任务概述 2.1 目标 开发本软件是为了服务酒店，使得酒店更好的经营。适用于一些大中型酒店，主要用于就餐管理和住宿管理。本软件产品是一项独立的软件，不过功能还可以增加，
完成后可以升级以增加功能和完善系统。 2.2 用户的特点 使用本软件要求用户熟悉Windows 操作，并且有一定的软件操作基础。预计本软件将会在一些大中型酒店中得到广泛使用。 2.3 假定和约束 本软件由我们小组六个人共同开发，几乎不要经费，开发期限一个月左右。3.需求规定 3.1 对功能的规定 ①系统帐号管理 第一次用一个管理员账号（系统给定）登陆，登陆成功后，可以设置其他用户，包括密码、权限等。 ②就餐管理 为就餐客户查询并分配餐桌，纪录客户用餐情况并结帐。 ③住宿管理 为住宿客户查询并分配房间，纪录客户住宿情况并结帐。 3.2 对性能的规定 3.2.1精度 本软件主要用于管理，不是科学计算，要求计算的精度不是很苛刻。所以输入,输出数据精度的要求不是很高，用于计算的数用浮点数就可以了。 3.2.2时间特性要求 本软件运行的响应时间要求不超过1～2秒，基本能实现。 3.2.3灵活性 本软件具有升级功能，以满足用户的需求。 3.3输人输出要求
如何做好需求变更管理——需求变更流程规范 一、引言 由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。 二、目的 控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。 三、角色与职责 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.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
项目变更管理流程举例 1.变更提出人可以为： ●最终用户 ●开发方实施人员 ●开发方设计人员 ●本项目管理人员 2.变更的提出 由变更提出人填写《变更申请单》，并签字，提交给项目经理或项目经理指定的人员（如配置管理人员等） 3.变更的评估 1)由项目经理领导或指导具体人员负责对变更进行评估，评估参与者包括：项目经 理、项目技术总监、相关技术小组组长、相关技术人员、用户方技术人员、用户 代表 评估的方面包括： ?技术影响 ?范围影响 ?费用影响 ?时间影响 ?风险影响 ?资源影响 ?其他相关影响 2)由项目经理和用户方技术人员作出变更批准或不批准的决定，书面签字。并作相 应记录 3)项目经理负责调整变更所涉及的所有项目计划，保证计划的完整性 4)项目经理负责将相关决定通知和计划变更有关人员。对于重大变更就通知所有项
目干系人 5)对于将可能引起项目基线变更的变更申请，应由项目总监签字同意方为有效 项目变更管理流程举例 1.输入 ●客户合同 ●分包合同 ●项目计划 2.目标 保证项目质量满足合同的要求、公司的业务目标和对合同的法律要求 3.步骤 提出并审查变更申请 评估变更 评估变更涉及的范围及决定其对客户、公司业务和技术方面带来的影响 评估变更将会对项目交付物带来的变化 评估变更对项目计划和过程带来的影响 评估需要对项目计划基准和合同文本应作的修改 估算要实施该变更需要的资源和费用以及不作变更所需的费用，公司的分包商应提出一个相关的报价 提出如何处理该变更的建议 由适当的管理层审批该变更申请。审批层次应在项目计划中定义 把变更整合到项目计划中，记录变更 4.输出 项目计划 5.文档 变更申请表 变更记录表
1. 引言 引言是对这份软件系统详细设计报告的概览，是为了帮助阅读者了解这份文档如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件系统详细设计报告是基于哪份软件产品需求分析报告、哪份软件产品概要设计报告和哪份软件产品数据库设计说明书(如果该软件产品需要数据库支持)编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统详细设计报告详尽说明了该软件产品的编码结构，从而对该软件产品的物理组成进行准确的描述。 如果这份软件系统详细设计报告只与整个系统的某一部分有关系，那么只定义软件系统详细设计报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种编写约定。编写约定应该包括：●部件编号方式； ●界面编号方式； ●命名规范： ●等等。 1.4 预期读者和阅读建议 列举本软件系统详细设计报告所针对的各种不同的预期读者，例如，可能的读者包括： ●开发人员； ●项目经理； ●测试人员； ●文档编写人员； ●等等。 描述文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
1.5 参考资料 列举编写软件系统详细设计报告时所用到的参考文献及资料，可能包括： ●本项目的合同书； ●上级机关有关本项目的批文； ●本项目已经批准的计划任务书； ●用户界面风格指导； ●开发本项目时所要用到的标难； ●系统规格需求说明； ●使用实例文档； ●属于本项目的其它己发表文件； ●本软件系统详细设计报告中所引用的文件、资料； ●相关软件系统详细设计报告； ●等等。 为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：●标题名称； ●作者或者合同签约者； ●文件编号或者版本号； ●发表日期或者签约日期； ●出版单位或者资料来源。 2. 支撑环境 2.1 数据库管理系统 描述数据库管理系统、以及安装配置情况，需要描述的内容可能包括： ●产品名称以及发行厂商 这里的产品名称指的是数据库发行厂商发布产品时公布的正式商品名称，不应该使用别名、简称、研发代号等非正式名称，以免混淆；同样的道理，发行厂商的名称也应该使用正式名称。 ●版本号 数据库管理系统的准确版本号，必须按产品的实际情况描述到最细节的版本号。 ●补丁包版本号 描述实际上将要使用的数据库管理系统补丁包的版本号，必须注意，在某些情况下该版本号不一定是最新的版本号。 ●语言或代码集 对于只支持一种语言或者一个代码集的数据库管理系统来说，该项描述不具意义。对于支持多种语言或者多个代码集的数据库管理系统来说，该项描述指的是实际使用的语言或者代码集。 ●安装位置 描述数据库管理系统的实际安装位置，应该分别对管理系统安缺位置和数据存放位置进行描述，应该指明服务器名和安装卷号(盘号)。对于分布式数据库，必须分别描述每一个数据
编者按： 作为软件开发人员或者软件系统客户，相信都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，客户甚至会说：“当时我是那样要求的，不过现在我们的业务调整了”…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要…… 在本期的月刊中，我们将围绕着“需求变更”这个主题展开讨论，希望对各位开发能有所帮助。让我们先来看一个需求变更的典型案例： Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。 但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。 而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。 随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。
QHSE 管理体系程序文件 项目变更管理程序 文件编码： GJXB/QHSE/CX20/2011 修 改 码：
2012-04-28发布2012-05-10实施中国石油天然气股份有限公司管道建设项目经理部 Pipeline Construction Administration Department
1 目的及范围 本程序规定了项目变更管理各部门职责界面、工作流程和管理要求。 本程序适用于项目经理部承建的油气管道建设项目变更管理工作。 2 术语 2.1 变更：是指对合同约定事项的调整。与批复可研和初设不一致的，应签订补充合同。 2.2 变更评估：是指对变更的原因、责任及对项目工期、投资、质量和HSE方面的影响进行分析判断，明确变更的可行性和必要性。 2.3 工程相关第三方：是指工程涉及的第三方，包括地方政府、沿线群众、公路、铁路、电力、军队等中石油外部单位和石化、销售、管道、油气调控中心等中石油内部单位。 3 职责 3.1计划处是项目变更的归口管理部门。负责组织变更评估，审查初设变更投资，综合平衡分析变更投资和工期，接收上级部门或项目业主提出的变更以及工程相关第三方提出的资源、市场和工程界面方面的变更，上报变更和接收变更批复。 3.2 造价与法律事务处负责根据合同条款和有关规定审核费用变更。 3.3 财务处负责审批工程保险变更。 3.4 工程管理处负责审核施工方案和施工工期变更，审批建设组织模式变更，组织开展无损检测变更、监理延期服务及监理派遣计划变更等工作。 3.5 工程技术处负责组织编制、审查设计变更方案，组织开展补充评价工作。 3.6 质量安全环保处负责审核变更引起的HSE风险及应对措施，组织开展物资监造变更及环评、安评、职评和水土保持方案补充评价报批工作。
软件开发需求文档模板
目录
1. 范围 本指南用于指导软件开发者为南京市交通局开发软件项目的过程，通过规范软件项目承担单位的开发过程达到提高软件质量，降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。在本指南的附录A至E中提供了文档的编写模板供开发者参考，在进行具体软件开发时，开发者可根据实际情况采编写，但必须提供双方约定的文档，文档中约定的内容必须描述清楚。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上，选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《南京市交通局信
息化数据库建设规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法，开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法，但建议开发商使用面向对象软件工程的方法，如：采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运行。目前软件平台为： 数据库管理系统： Oracle 9i以上版本 中间件(应用服务器)系统： IBM WebSphere OA系统： Lotus Domino/Notes 网络架构： 完全支持TCP/IP协议 开发工具或技术体系：
为保证软件的上下兼容性，开发者应选择比较通用的开发工具的较新版本进行开发，如Microsoft Visual https://www.doczj.com/doc/9d2003362.html,，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。 2.3 软件项目的开发实施过程管理要求 2.3.1 软件项目实施过程总体要求 （一）开发者提交软件开发工作大纲，交通局组织专家组对工作大纲进行评审，并提出整改意见。 （二）通过评审后，开发者根据整改意见完善工作大纲，经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，开发者需分阶段提交相关文档。 （三）在软件开发工作完成后，开发者应向交通局提交完整的软件文档，交通局组织验收组对软件进行验收审查。 2.3.2 软件项目实施变更要求 在开发过程中，需求或设计不可避免地需要
变更管理流程
文档控制文档分类 版本控制 批准
Method123 Array Management Methodology Version 2.0 December 2000 目录 1概述 ....................................................................................... 错误！未定义书签。2变更流程 .. (3) 2.1摘要 (3) 2.2提交变更申请 (5) 2.3审核变更申请 (5) 2.4识别变更可行性 (5) 2.5批准变更申请 (5) 2.6实施变更申请 (6) 3变更任务 (6) 3.1变更申请人 (6) 3.2变更经理 (6) 3.3变更可研小组 (6) 3.4变更审批小组 (7) 3.5变更实施小组 (7) 4变更登记 (7) 5变更模板 (7)
1 概述 描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如： 变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。 对项目的变更管理是通过对以下五个关键步骤的实施引入的。，: 提交和接收变更申请 审核和记录变更申请 确定变更申请的可行性 批准变更申请 实施和结束变更申请 2 变更流程 对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project. An example follows: 2.1 概要 下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。
需求分析 1.引言 1.1目的 说明编写这份报告的目的，指出预期的读者。 1.2背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网 1.4术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 3.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4.需求规定 4.1软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2对功能的一般性规定 本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。 4.3对性能的一般性规定 4.3.1精度 说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。 4.3.2时间特性要求 说明对于该系统的时间特性要求。 4.3.3灵活性 说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。 4.4输入输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。 对系统的数据输出及必须标明的控制输出量进行解释并举例。
项目实施中的需求变更管理 庞宝勇 【摘要】我们在项目实施过程中，经常会遇到用户所提出的各种各样的需求信息和变更信息，这也是影响我们项目进度重要因素，如何管理和控制这些需求是摆在我们每个项目管理者目前的现实问题。 【关键词】需求变更管理控制 一、问题的提出 用户需求变更，这是每一名项目实施人员感到头痛的事情。对于那种需求变更较少的情况，会增加我们的项目工作量，对项目进度造成一定的延误；对于大量的需求变更，或颠覆性的需求变更，会把项目拖入“绝境”中，项目人员疲惫不堪，用户不满意，最终导致项目无法验收。需求如果管理或控制不好，实际对甲乙双方来讲会造成“两败俱伤”的局面，因为，并不是所有的需求都是可行的，如果不进行科学的评估和合理的规划，那些“危险”的需求会将项目引向“泥潭”，导致双方无法“自拔”，使项目陷入极其被动的局面。 二、原因分析 1．项目合同或协议范围界定模糊 在签订项目合同或技术协议时，没有把实施范围或项目内容描述清楚，为了通过竞争拿到合同，对于用户的很多要求都进行承诺。导致实施过程中用户任意提出各种需求。 2．需求调研不明确和不详细 在项目初期，项目实施方需要进行需求调研。如果需求调研的对象选择有问题，会给调研内容造成较大的偏差。如项目实施方选择对业务了解不全面的人进
行调研，他（她）所提供的需求信息就会不全面，为需求分析提供了不完整或存在偏差的信息，导致后续的设计和开发结果无法满足用户需求。另外，有的情况下为了赶进度，草草进行调研，不对用户的业务需求进行详细的分析，同样会影响后面的设计和开发的质量。 3．对用户需求的理解存在偏差 在项目实施过程中，实施人员对用户所提出的需求并没有完全理解，想当然进行了分析和设计，结果开发出来的功能并不是用户所真正需要的，与用户的想法存在差异性，导致需求变更。 4．用户没有完全了解和掌握系统 在有些情况下，由于用户没有完全理解和掌握系统的各项功能和配置，认为系统缺少某些业务支撑，要求项目人员进行需求变更。 5．缺乏流程控制和管理 在项目实施中，由于没有指定有效的需求变更流程，用户一有想法就对实施人员提出变更，甚至有的需求进行反复变更，大大降低了实施效率和影响工作进度。 三、如何解决 1．明确需求，认真分析 在项目签订时，要和用户方明确“做什么，不做什么”，需求明确了，实施范围就确定了。即使实施过程中出现了需求变更，项目组可根据其工作量、技术难度、现场实际情况来灵活掌握，争取了主动权。 另外，在需求调研阶段，要让项目组有经验的业务顾问进行详细的调研工作，从业务角度对用户的需求进行分析，并编写详细的《需求规格说明书》，文档经
1. 引言 1.1 目的 说明编写这份报告的目的，指出预期的读者。 1.2 背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。 1.4 术语 列出本报告中用到的专门术语的定义。
2. 任务概述 2.1 目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。3. 假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4. 需求规定 4.1 软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2 对功能的一般性规定
一、令人烦恼的需求变更 作为一个软件项目经理，在项目开发进行中，你是否遇到过这样的问题：客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。甚至要重新设计现有的架构。 而面对这种情况，作为项目经理的你是否会说：“我们无法拒绝客户, 但也无法立即满足他的新需求,所以只好是推到以后再进行完善。”或者，更极端些的想法：客户总是在异想天开，客户的需求在技术上根本无法实现…… 在与客户新的需求论证中，你是否会对需求确认的重要性产生怀疑。因为在一开始已经多次和客户沟通,也在没有任何异议的情况下得到了明确的答复,但当开发项目在不断演进, 客户对系统的理解逐步加深之时, 他们最终还是推翻以前自己想要的需求。而这时你会认为对于需求,只有获取,没有确认。 而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。你还是在抱怨客户的需求像天气一样一直变个不停，最终，无论是你的抱怨还是客户的需求变更只会令项目组中的开发人员疲于奔命，无所适从。 在你的软件项目进行开发之前，你和你的项目成员是否有过这样的想法，在这次软件项目开发中，一定要消除需求变更，不让谈论好的需求发生任何的变更？ 首先，这种想法和认识是错误的，软件项目开发中的需求变更是不能被完全消除的。无论是项目经理还是项目开发人员，最好在项目开始之前就消除这种想法。需求变更是不可能被消除的，而“消除需求变更”的想法却需要被消除。消除需求变更的所有的努力和想法，在项目开发进行中通常都是费力不讨好。 项目开发过程中，需求的变更是不可避免的。