需求分析的要求

软件需求变更处理流程和注意事项

1、需求变更的原因分析

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

(1)、范围没有圈定就开始细化

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

(2)、没有指定需求的基线

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

(3)、没有良好的软件结构适应变化

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

2、如何控制需求变更

按照现代项目管理的概念，一个项目的生命周期分为启动、实施、收尾三个过程。需求变更的控制不应该只是项目实施过程考虑的事情，而是要分布在整个项目生命周期的全

过程。为了将项目变更的影响降低到最小，就需要采用综合变更控制方法。综合变更控制主要内容有找出影响项目变更的因素、判断项目变更范围是否已经发生等。

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

(1)、项目启动阶段的变更预防

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

(2)、项目实施阶段的需求变更

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

需求一定要与投入有联系，如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。

如何做好需求变更管理？——需求变更流程规范

1.流程说明：

需求来源：客户提交相关需求变更

审核需求变更：评估如果实现该需求，需要的时间、人力成本多少；并评估对项目工期影响有多大？判断那些需求能够目前解决，那些需要留到下一版本解决。最后输出一份审核确认表反馈给客户，和客户进行商讨。参与评审的人员要包含项目经理，项目组长，测试组长，市场人员。

配置管理员：对变更需求进行记录，需求文档进行更新，并通知相关人员

项目组长：负责调整相关开发进度表，评估任务时间，分发给相关开发人员

测试组长：根据变更需求和开发进度，对测试进度进行相对应调整，并修改测试需求分析书，分发需求更新给相关测试人员。测试人员对用例进行补充，修改。

客户提交的变更需求最后必须让客户进行签字确认。

2、需求变更流程（内部提出需求变更）

1）执行条件：

对项目进度不会影响严重

与客户原始需求无偏差

图：需求变更流程（内部提出需求变更）

2）流程说明：

内部需求变更来源：公司内部人员发现逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求不一致内容。

需求变更类型：需求有误、需求有遗漏、需求不明确。

需求变更审核：内部提交的需求应该经过项目经理，项目组长，测试组长，市场人员共同的确认才能确认是否修改。

项目组长：评审需求变更部分的工作量，判断需求变更的内容是否对开发进度有影响，如果需求变更对开发进度有影响，项目组长可以拒绝变更；将变更内容放入下一版本进行修改，若市场人员认为必须在本版中进行修改，项目组长可以将变更的内容提交给项目经理进行处理，并决定是否在本版中进行修改。

需求信息发布：经过需求人员和项目组长的沟通、协调确定在本版中进行修改的需求变更，需求人员需要将变更内容的信息，以邮件方式通知相关人员。

配置管理员：对需求变更进行备案。

开发，测试：开发、测试人员接收到需求变更内容后首先审核设计文档和测试文档，修改变更的地方。并根据变更后的文档进行开发和测试。

五、附件

客户需求确认单

文档名称

文档摘要

客户确认

经办人签字：单位公章：确认日期：项目进度控制中的注意事项

项目进度控制是项目管理工作中的重要一环，但现在的软件开发项目进度失控的例子却屡见不鲜，甚至进度的延迟总是在快到计划结束的时刻暴露出来，然后谁也不知道到底什么时候才能够结束项目。所以在制定项目进度计划以及计划控制时需要考虑如下因素：1.面向客户的需求管理需求是项目的基础，项目计划是实现需求的进度安排。我要在需求分析初期把需求变更流程制定好，将客户纳入到流程的环节中。

2.项目团队共同完成项目计划在制定项目计划时，可以将承载着客户需求的用例、特征分配给具体的开发人员，让每个开发人员进行估算，并与项目经理进行协商，达成共识。

3.确保生命周期/里程碑是可验证的最大的问题就在于很多里程碑没有相应的验证标准，在软件开发项目中设立的里程碑，其作用是在项目进行时确认进度用的，因此需要给出一个清晰的验证标准，用来验证是否达到里程碑。而验证的标准可以是事件，也可以是工件，例如:“已完成规格化的软件需求说明书的编辑”、“软件需求说明书通过客户签字确认”可以做为需求分析完成里程碑的验证标准

4.项目的变化动态的更新项目计划拿破仑曾经说过，没有一场战争是按照计划打的，但没有一场战争可以在没有计划的情况下赢得的。这句话深刻地诠释了事情发展的动态性，因此在项目开发过程中，项目计划是不可能保持一成不变的。而是应该根据项目的进展，对一些新的需求、新的变化、突发因素做出响应，动态的更新项目计划