软件需求管理

最新推荐文章于 2024-07-31 19:04:44 发布

xu_zh_h

最新推荐文章于 2024-07-31 19:04:44 发布

阅读量8.9k

点赞数 2

分类专栏：软件需求文章标签：工作文档项目管理产品测试活动

本文链接：https://blog.csdn.net/xu_zh_h/article/details/2516813

版权

软件需求专栏收录该内容

13 篇文章 0 订阅

订阅专栏

软件需求管理

这篇文章的目录结构是我拟定的，内容大部分是参考网上和书上资料，也有一部分是我自己总结的

前言需求和需求管理问题

第1节需求和需求问题

需求是项目的基础，只有准确了解客户的需求,以之为基础，我们才能顺利地完成项目，在预算内按时提交高质量的对客户有用的产品。然而，有头无尾的半截子工程，用户不满意的工程，难以投入实际环境使用的工程，经费严重超支和进度被拖延的工程，并不是个别现象，而造成这种项目失败的原因非常多，其中最糟糕的莫过于在需求阶段产生的重大缺陷，缺少来自用户的信息，需求不够完整及需求发生了变化。统计资料显示，返工的成本占总开发成本的30% - 50%，而70%-80%的返工是需求错误引起的。

第2节需求管理和需求管理问题

需求管理是对需求开发的管理，伴随需求开发全过程、软件生命周期全过程。如果不能采取有效手段来实施需求管理活动，由此导致的结果是用户和开发团队对产品需求的理解相去甚远。项目需求获取也许是最困难，最关键，最容易出错和最需要沟通的一个环节，它的模糊性、不确定性、变化性和主观性的特点，使项目需求管理更具复杂性。如果不能有效处理需求变更这个特殊和困难的挑战，项目计划将会一再调整，交付日期一再拖延，项目团队人员的士气必将越来越低落，这将直接导致项目成本增加、质量下降及项目交付日期延迟。因此项目组必须拥有需求管理策略和需求过程。

第1章需求管理目标

需求管理的目的就是要控制和维持需求事先约定，保证项目开发过程的一致性，使用户

得到他们最终想要得产品

Ø 确保需求调研的成功，即需求调研中要从人员、方法、工具方面组织好调研活动

Ø 确保需求文档中描述的需求是用户需要的需求，即要和用户反复确认和商讨需求

Ø 确保需求文档中描述的需求是最新的需求，即不断跟新需求文档版本

Ø 确保需求文档中的需求是可以度量的，即对需求进行详细标识

Ø 确保需求文档中的需求是可跟踪的，即可控制和可管理

第2章需求管理任务

从需求管理目标看，确保得到一份正确的需求，然后对需求进行详细分解，达到度量需求的目的，对需求的每个小项进行跟踪，可以从用户需求追踪到设计、编码、测试、验收；反过来也可以由后面的过程追踪到前面的过程，所以需求管理要包括下面的任务

Ø 需求调研计划：包括客户人员、自己人员、需要的资料、设备、规范、进度

Ø 组织双方对需求进行评审：确保需求的正确、一致

Ø 度量需求文档中的需求，标识需求项（作为需求跟踪的唯一标识）、重要等级。

Ø 对需求变更进行评审，然后对需求变更进行版本维护

Ø 对需求状态跟踪

第3章需求管理组织

从需求管理任务看，需求管理的职责可以分成：

Ø 需求调研计划制定

Ø 需求分解，标识

Ø 需求跟踪

Ø 组织需求变更审核

Ø 客户审核需求变更

Ø 评估需求变更影响

Ø 维护需求文档

　　根据上述职责、根据项目情况设置适当岗位

第4章需求管理周期以及和其他活动关系

Ø 必须与需求工程的其它活动紧密整合

谈需求管理一定不能脱离需求工程。从完整意义上讲，需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理。狭义上，需求管理关心的是需求管理过程的建立，在企业或项目组中需要有一套规范的需求管理过程。而实际上从项目经理的角度上看，可能还有50%甚至更多的精力是用于关注结果的，所以对需求内容的管理与对需求形式的管理是密不可分的。

Ø 与需求开发的关系

组织需求调研活动；组织需求评审活动；分解需求项，标识重要级；对需求变更结果进行维护

Ø 与设计的关系

建立设计和需求关系，使之能追踪

Ø 与编码的关系

建立编码和设计、需求关系，使之能追踪

Ø 与测试的关系

建立测试和编码、设计、需求关系，使之能追踪

第5章需求管理内容

第1节需求质量管理

5.1.1 需求质量属性

功能属性

功能正确性：需求定义的功能是否可以正确执行，并且产生理想的数据

非功能属性：对用户重要属性

有效性：系统故障概率

效率：处理器、磁盘、通信带宽资源占用

灵活性：可扩展性

安全性：防止非法访问和数据丢失

互操作性：和其他系统交互数据的难易程度

可靠性：软件不发生故障的概率

健壮性：系统遭到非法输入、相关软件和硬件缺陷或异常操作时，能继续正

确运行功能的程度

可用性：系统使用的方便性

对开发者重要的属性

可维护性：做一次纠错或者更改的难易程度

可移植性：把软件从一个运行环境移到另一运行环境的难易程度

可重用性：复用

可测试性：查找错误的难易程度

软件度量属性需要根据客户要求进行取舍

5.1.2 需求质量验证

需求验证过程见，W验证模型，模型中验收测试和系统测试属于需求质量验证，集成测试和单元测试属于设计质量验证和编码质量验证

第2节需求风险管理

5.2.1 风险管理

风险管理中先要识别风险，然后分析风险发生条件、可能性、危害、避免方法，最后对系统中所有分析进行计划管理，有效控制风险，降低风险的危害

风险条目跟踪
序号
确定日期：
撤销日期：
描述：描述风险
可能性：发生概率
影响：造成损失
危害值：可能性*影响
降低风险计划：
负责人：解决风险的责任人
截至日期（完成降低风险措施的截止日期）

5.2.2 与需求相关风险

Ø 需求获取：

ü 产品试图与范围：如果开发方和客户没有就项目范围达成一致，适当的意见，会导致

开发范围逐渐扩大

ü 需求开发时间：时间安排不合理，隐藏的工作没有规划出来，开发支持工作配合不及时

ü 需求规格说明书的完整性和正确性：需求说明描述出现问题

ü 明确非功能要求：需要确定肺功能性需求

ü 需求决定权：确保在需求决定权上有正确的人选

ü 未加说明的需求：识别用户隐含的期望要求

ü 从解决方案中找到问题本质：用户推荐的解决方案掩盖了用户实际需求，分析人员要从客户叙说的解决方案中提炼其本质

ü 用户不能正确表达自身的需求：在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求

ü 业务人员配合力度不够：有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用

ü 忽略了用户的特点分析：分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望

ü 客户业务变动：客户业务根据实际情况发生变化

Ø 需求分析

ü 划分需求优先级：

ü 带来技术困难得特性：分析每项需求的可行性以确定是否能按计划实现。

ü 不熟悉的技术、方法、语言、工具和硬件平台：不要低估学习难度

Ø 需求规格说明

ü 需求理解：开发人员和客户对需求不同理解会带来彼此间期望的差异，将导致最终产品

产品无法满足客户要求

ü 时间压力对TBD的影响：如果TBD并未解决对项目后续进行将带来很大影响

ü 具有二义性的术语：

ü 需求说明中包含了设计：

Ø 需求验证：

ü 未经验证的需求：

ü 审查有效性：

Ø 需求管理

变更需求：控制需求变更，减少变更

需求变更过程：当变更发生时需要有效机制和计划管理变更

未实现的需求：需求跟踪可以避免发生为实现需求

扩充项目范围：如果开始没有定义好项目范围，那么过段时间可能要扩充项目范围

需求跟踪：方便管理需求执行、质量

第3节需求范围管理

5.3.1 需求范围

需求范围就是一个项目的需求范围，也就是项目范围。需求范围决定了这个项目或者产

品的客户要求，主要包括功能要求。这个范围是整个系统后续开发的纲领，所以需要特别重视，范围确定和变更要慎重对待。

5.3.2 需求范围管理

Ø 造成范围界定不清的原因：

ü 首先，没有完善的项目管理体系来指导项目的管理。

ü 第二，对项目没能制定出清晰规范的范围变更控制过程。企业有管理体系，但不够完善和规范，对项目组的变更过程的制定没能起到有效的指导作用。变更是不可避免的，只要有效地加以管理、控制，同样可以达到各方满意的结果；

ü 第三，是对范围的定义不够明确，做不到可量化、可验证程度。

Ø 如何管理好项目范围：项目范围管理应该包含下面过程：启动、范围定义、范围核实及范围变更控制。下面将详述如何做好这些过程：

Ø 启动过程：启动过程的一个输出就是项目章程。项目章程是一个重要的文档，这个文件正式承认项目的存在并对项目提供一个概览。项目章程将粗略地规定项目的范围，这也是项目范围管理后续工作的重要依据。项目章程中还将规定项目经理的权利以及项目组中各成员的职责，还有项目其他干系人的职责。

Ø 范围定义过程：范围定义是指将项目主要的可交付成果细分成较小的、更易管理的组分。这个过程中，项目组要建立一个工作分解结构（WBS）。

ü WBS的建立对项目来说意义非常重大，它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来，使得项目管理有依据，项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。

ü 制定好一个WBS的指导思想是逐层深入。先将项目成果框架确定下来，然后每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。

Ø 范围核实过程：范围核实是指对项目范围的正式认定，项目主要干系人，如项目客户和项目发起人等要在这个过程中正式接受项目可交付成果的定义。这个过程是范围确定之后，执行实施之前各方相关人员的承诺问题。一旦承诺则表明你已经接受该事实，那么你就必须根据你的承诺去实现它。这也是确保项目范围能得到很好的管理和控制的有效措施。

Ø 范围变更控制过程：范围变更控制是指对有关项目范围的变更实施控制。变更是不要避免的，关键问题是如何对变更如何进行有效的控制。控制好变更必须有一套规范的变更管理过程，在发生变更时遵循规范的变更程序来管理变更。通常对发生的变更，需要识别是否在既定的项目范围之内。如果是在项目范围之内，那么就需要评估变更所造成的影响，以及如何应对的措施，受影响的各方都应该清楚明了自己所受的影响；如果变更是在项目范围之外，那么就需要商务人员与用户方进行谈判，看是否增加费用，还是放弃变更。因此，项目所在的组织（企业）必须在其项目管理体系中制定一套严格、高效、实用的变更程序。

第4节需求配置管理

对配置知识不了解，所以没有话好说

第5节需求跟踪管理

5.5.1 需求跟踪矩阵

提示：正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系。矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。

＃	需求文档（版本，日期）	设计文档（版本，日期）	代码（版本，日期）	测试用例（版本，日期）
1	标题或标识符，说明	标题或标识符，说明	代码名称，说明	测试用例名称，说明
2	…	…	…	…

5.5.2 需求问题处理

提示：查找工作成果与需求文档之间的不一致性，分析原因，给出解决措施

＃	问题描述	识别人、日期	解决措施	结果
1
2

需求链的概念指的是需求能够上传下达，从客户传达到需求过程，并从需求过程传达到需求过程的下游开发链。而这个传达是可以逆向的。

需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用（ Ramesh 1998）。

在CMM三级中要求软件团体必须具备需求跟踪的能力：“在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测试过程。”

实际上，创建需求跟踪能力是困难的，尤其是在短期之内会造成开发成本的上升，虽然从长远来看可以减少软件生存期的费用，软件团体在实施这项能力的时候应循序渐进，逐步实施。

需求跟踪的一种通用的方法是采用需求能力跟踪矩阵。它的前提条件是将在需求链中各个过程的元素加以编号，例如：需求的实例号，设计的实例号，编码的实例号，测试的实例号。他们的关系都是一对一和一对多的关系。通过编号，你可以使用数据库进行管理，需求的变化能够立刻体现在整条需求链的变化上。

需求跟踪矩阵并没有规定的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能够保证需求链的一致性和状态的跟踪就达到目的了。

第6章需求管理环节

第1节需求调研环节管理

6.1.1 需求调研准备：

Ø 调研前应该将所有项目前期资料进行汇总，与相关的前期销售人员进行交流，以便对项目有一个基本轮廓的认识。

Ø 做好调研前使用资料的准备，如需求调研模板，需求调研问题列表等。

Ø 制定需求调研计划

6.1.2 需求调研过程

Ø 首先提高自己业务知识和熟悉用户的行业，对于人力资源的标准业务应该基本熟悉。

Ø 需求调研中，学会尽量不使用IT行业的术语。

Ø 提高自己的总结能力，书写一份完整的、前后一致的、可追踪的需求报告。

Ø 确定调研方法：根据不同客户的业务特点确定不同调研方法。

Ø 根据调研方法选择对应的调研分析工具

Ø 保持一种和客户平等合作的心态，确定需求调研是为了给客户解决问题，探讨问题，而不是接受问题，更不是来指导工作的。

6.1.3 需求调研总结

Ø 出需求调研报告

Ø 客户确认需求调研报告

第2节需求分析环节管理

Ø 确定分析工具和分析方法

第3节需求编制阶段管理

Ø 确定文档规范

Ø 解决文档编制中出现的问题

Ø 制定编制计划

Ø 出需求文档

第4节需求度量阶段管理

Ø 对需求进行分层，建立层之间的关系，然后对最底层需求进行分解，分解到功能点，然后对各层需求进行编号，度量的目的主要是实现精细化的管理、有效地对项目进行控制，对度量数据的分析用于辅助决策、经验积累、有效评估等。但是度量本身就是双刃剑，一方面度量对于精细化管理是必要的前提，另一方面度量体系、度量的执行需要花费大量的人力成本，而且如果没有明确的目标和有效的方法来分析和利用这些数据，度量就又陷于无谓的劳民伤财，成为组织过程的累赘。

Ø 对需求分级管理，表示需求的优先级：在每一次产品开发过程中，都会遇到这样一个问题：负责产品需求的领域专家罗列了长长的功能列表，每个功能似乎都是不可或缺的，而当排出进度表后，却发现工期是公司不能接受的，没办法，必须裁剪需求。没有需求就不会有产品，而没有产品就没有利润。如果需求过多，反而可能是陷阱——只有投入，没有产出。一个好的项目需求，必须有需求的优先级，便于进行项目的整体平衡。

Ø 需求分类管理：在做工程项目的时候一定要将需求分出层次，不同层次的需求侧重点是不一样的，描述的方式是不同的，管理的方式也是不同的。比如说，在企业里高层领导提出来的是目标性需求，中层管理人员提出来的是具体的业务流程的需求，而作业人员提出来的是更侧重于操作性的需求。对于目标性的需求可能采用简短的几句话就可以描述清楚，但这是项目的决策性需求，需要很稳定，不能轻易更改，在确定的时候需要慎之又慎。

我把需求分成五个等级。五分等级也是工程技术上的常用方式，如同大学的五分制。

　　一级需求（或改变）是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这是必须满足的，否则就意味着否定程序员自已。所以定为Urgent.；这通常是属于补救性的debug类型，要救火。

　　二级需求（或改变）是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续。所以是NECESSARY；一般新模块关键性的基础组件，属于这个级别。

　　三级需求是后续重要的需求，它不能满足会令整体工作价值下降，为了体现项目价值，也是程度员自已的技术价值的证明，所以定为NEEDED；一般性的重大的有价值的全新模块开发，属于这个级别。

　　以上三个等级是应该实施的，但时间性上可以作优先级的排列。

　　四级需求是改良性需求，没有它并不影响已有功能的使用，但实现了，有可信的根据可以是BETTER.界面和使用方式的要求，一般在这个档次。

　　五级需求是可选性需求，没有它没有谁会活不下去，有了它，没有根据一定带来好处，更多是一种设想，以及一种可能；通常只是需求代理人员的一种个人喜好。所以是MAYBE。

　　对于四级需求，工程人员项目有空，不妨做下去；对于五级需求，有兴趣有余力就做，没有兴趣或者没有余力，管他需求不需求，除非额外付大钱，就让提这些外行需求的家为一边凉快去。

很多企业的度量陷于盲目，导致了很多负面的影响，进而影响整个组织对项目管理体系的理解和信任。有如下问题和误区存在：

1. 不清楚组织的需求（到底需要度量什么）；

2. 不清楚度量的用途，认为度量总是有用的；

3. 度量是不需要花费的或者投入是很小的；

4. 直接用于考核，忽视了度量的导向作用的两面性（最常见的就是代码行作为程序员的成绩，导致了代码的重用性差，无效代码增多等负面影响）；

5. 在数据分析时孤立分析数据结果，没有考虑相关的度量指标的结果；

6. 不相信数据，认为数据是没有用的。

在这里不想介绍什么样的度量体系和方法、度量的技术和流程。仅仅结合度量在实际实施过程中的好的实践列举给大家。对于上述误区有以下实践和经验可以借鉴：

1. 需要什么才度量什么，从组织的需要、项目的需要、产品的需要、过程的需要以及管理的需要等分析，根据目标来选择测量指标；

2. 度量必须用于决策并支持决策才有意义，度量必须结合组织的商业目标并为实现这个目标而努力；

3. 度量是耗时耗力的，因此测量不要花费过多的额外工作量，测量结合在工作过程中，而不是需要额外的工作，可以考虑使用工具，减少度量的成本；

4. 不要直接用于考核，从积极和正向激励的角度出发来设置度量考核，如果用于考核要结合多个指标，并将数据处理后使用，不能直接使用；

5. 数据分析要考虑影响因素和相关Metrics；

保证数据的完整正确，并相信数据，如果你不相信它，那它就没有任何意义。

第5节需求评审阶段管理

第6节需求变更阶段管理

需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。

无论需求变化的程度如何，只要需求变化了就必须进行评估，这是基本的原则。此外，在一个项目组中必须明确定义一个需求管理员，由他负责整个项目的需求管理工作，确保在发生需求变更时，受影响的产品能得到修改并与需求的变更保持一致，受影响的其它组也必须与客户协商一致。变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。

这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。

6.6.1 实施需求变更管理需要遵循如下原则：

1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

2.制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。

3.成立项目变更控制委员会（CCB）或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。

4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。

5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。

6.妥善保存变更产生的相关文档。

6.6.2 需求变更管理实践中的对策

需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时还会有取消变更的步骤。变更控制流程如图所示。针对变更控制流程，笔者在实际工作中总结出了软件开发人员在需求变更管理实践中的几点对策：相互协作　很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案

充分交流　需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。

安排专职人员负责需求变更管理　有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。

合同约束　需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。

区别对待　随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。

选用适当的开发模型　采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。

用户参与需求评审　作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。

1、需求变更的原因分析

　　需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因：

　　（1）、范围没有圈定就开始细化

　　细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。当细化到一定程度后并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是手工添人的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。

　　（2）、没有指定需求的基线

　　需求的基线是指是否容许需求变更的分界线。随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少），其过程如下：变更请求à比较基线à变更实现。

　　（3）、没有良好的软件结构适应变化

　　组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。但适应变化必须遵循一些松祸合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。

　　2、如何控制需求变更

　　按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全过程。为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。

　　进行综合变更控制的主要依据是项目计划、变更请求和提供了项目执行状况信息的绩效报告。为保证项目变更的规范和有效实施，通常项目实施组织会有一

　　（1）、项目启动阶段的变更预防

　　对于任何项目，变更都无可避免，也无从逃避，只能积极应对，这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说，基准文件定义的范围越详细清晰，用户跟项目经理扯皮的幌子就越少。如果需求没做好，基准文件里的范围含糊不清，被客户抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。这个时候千万不能手软，这并非要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。相对于需求来说，什么WBS、风险管理、计划进度都是次要的，只要需求做好了就会一帆风顺。

　　（2）、项目实施阶段的需求变更

　　成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念——“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。控制需求渐变需要注意以下几点：

　　需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始，无论是开发方还是出资方都要明确这一条：需求变，软件开发的投人也要变。

需求的变更要经过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

　　小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。但正是由于这种观念才使需求逐渐变为不可控，最终导致项目的失败。

　　精确的需求与范围定义并不会阻止需求的变更。并非对需求定义得越细，就越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非需求写细了，它就不会变化了。

　　注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点间题，但是由于需求的变更可能来自客户方，也可能来自开发方，因此，作为需求管理者，项目经理需要采用各种沟通技巧来使项目的各方各得其所。

　　（3）、项目收尾阶段的总结

　　能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累，即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。

　　事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。

　　3、需求变更的处理流程

　　需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤：提出变更à变更评估à实施变更。

　　需求变更处理流程

　　因为现实世界的软件系统可能有不同的严格程度和复杂性，所以事先预言所有的相关需求是不可能的。系统原计划的操作环境会改变，用户的需求会改变，甚至系统的角色也有可能改变。实现和测试系统的行为可能导致对正解决的问题产生新的理解和洞察，这种新的认识就有可能导致需求变更。CMM提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候再引人相应的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。这个缓冲器允许真实的变更被注意、记录、追踪，同时开发工作又不会因此而被扰乱。开发项目应该周期性地暂停来吸收最新的需求变更积累，此时，所有的计划、设计、行为都根据刚刚吸收的需求变更的影响进行更新。

　　需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关，比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展趋势都是一样，那就是为了使变更管理变得更容易，因此，不论在项目变更控制中采取什么方法、策略，对于项目本身的变化一定要时时洞悉，处处留意，只有这样才能从真正意义上对项目进行很好的变更控制。