- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
处理需求变更的流程 需求变更的目的 控制需求变化引起的开发、测试与需求不一致的情况,约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。 角色与职责 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种情况 一种是客户提出来要进行修改,增加需求等; 一种是公司内部人员提交的建议, 还有就是开发人员自己修改流程(修改后的效果比前面的更加好),另外需求变更可能是比较小的改动; 另外一种就是可能涉及到整个产品流程,这就是比较大的需 求改动。 1、需求变更流程(客户提出需求变更)执行条件:客户提出需求变更 图:需求变更流程(客户提出需求变更) 2,流程说明: 需求来源:客户提交相关需求变更 审核需求变更:评估如果实现该需求,需要的时间、人力成本多少;并评估对项目工期影响有多大?判断那些需求能够目前解决,那些需要留到下一版本解决。最后输出一份审核确认表反馈给客户,和客户进行商讨。参与评审的人员要包含项目经理,项目组长,测试组长,市场人员。 配置管理员:对变更需求进行记录,需求文档进行更新,并通知相关人员 项目组长:负责调整相关开发进度表,评估任务时间,分发给相关开发人员 测试组长:根据变更需求和开发进度,对测试进度进行相对应调整,并修改测试需求分析书,分发需求更新给相关测试人员。测试人员对用例进行补充,修改。 客户提交的变更需求最后必须让客户进行签字确认。 2、需求变更流程(内部提出需求变更)1)执行条件:对项目进度不会影响严重与客户原始需求无偏差 图:需求变更流程(内部提出需求变更) 2)流程说明: 内部需求变更来源:公司内部人员发现逻辑,需求上的问题,或功能上的建议以及开发、测试人员提出的需求不一致内容。 需求变更类型:需求有误、需求有遗漏、需求不明确。 需求变更审核:内部提交的需求应该经过项目经理,项目组长,测试组长,市场人员共同的确认才能确认是否修改。 项目组长:评审需求变更部分的工作量,判断需求变更的内容是否对开发进度有影响,如果需求变更对 开发进度有影响,项目组长可以拒绝变更;将变更内容放入下一版本进行修改,若市场人员认为必须在本版中进行修改,项目组长可以将变更的内容提交给项目经理 进行处理,并决定是否在本版中进行修改。 需求信息发布:经过需求人员和项目组长的沟通、协调确定在本版中进行修改的需求变更,需求人员需要将变更内容的信息,以邮件方式通知相关人员。 配置管理员:对需求变更进行备案。 开发,测试:开发、测试人员接收到需求变更内容后首先审核设计文档和测试文档,修改变更的地方。并根据变更后的文档进行开发和测试。 1、需求变更的原因分析 需求变更的表现形式是多方面的,如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中,变更可能来自方案服务商、客户或产品供应商等,也可能来源于项目组内部。虽然需求变更的表现形式千差万别,但究其根本不外乎以下几种原因: (1)、范围没有圈定就开始细化 细化工作是由需求分析人员完成的,一般是根据用户提出的描述性的、总结性的短短几句话去细化的,提取其中的一个个功能,并给出描述(正常执行时 的描述和意外发生时的描述)。当细化到一定程度后并开始系统设计时,范围会发生变化,那细节用例的描述可能就有很多要改动。如原来是手工添人的数据,要改 成根据信息系统计算出来,而原来的一个属性的描述要变成描述一个实体等。 (2)、没有指定需求的基线 需求的基线是指是否容许需求变更的分界线。随着项目的进展,需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响,比如软件整体结构 已经设计出来是不容许改变需求范围的,因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展,基线将越定越高(容许的变更将越少),其过程如 下:变更请求à比较
您可能关注的文档
最近下载
- 钳工高级理论+技能.doc
- 建筑施工企业全套安全资料(生产责任制、管理制度等).doc
- KW系统集成公司平衡计分卡实施 踏瑞绩效管理智能反馈比赛软件 参考答案.pdf VIP
- 专题二 函数与导数(2020-2024)五年高考《数学》真题分类汇编(解析版).docx VIP
- 西方文学理论 马工程 13.第十二章 英美新批评文论.ppt VIP
- 高考数学五年(2020-2024)真题《函数概念与基本初等函数》分类汇编含答案.docx VIP
- 第9课 隋唐时期的经济、科技与文化(教案)(表格式)【中职专用】《中国历史》(高教版2023基础模块).pdf VIP
- 婴幼儿肥胖管理专家共识(2025).pptx VIP
- 职业生涯规划:物流管理.pptx VIP
- 全程对中心静脉导管尖端位置的质量控制管理题库答案-2025年华医网继续教育.docx VIP
原创力文档


文档评论(0)