产品需求变更表
需求开发与管理标准化流程说明及表单书写说明全套
需求开发与管理标准化流程说明及表单书写说明1 目的定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。
2 适用范围2.1 机构研发中心技术部门及PMO、技术拓展部。
2.2 业务提供需求工程的过程标准。
3 名词术语3.1 RDM（Request Development and Management）：需求开发与管理。
3.2 SRS(Software Requirement Specification)：软件需求规格说明书。
3.3 客户(Customer)：开发产品订单的付费方3.4 最终用户(End User)：最终真正操作软件的用户3.5 用户需求：指直接来自于客户或者用户的原始需求3.6 产品需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求3.7 CCB(Change Control Board)：变更控制委员会。
CCB的组长一般为适用机构的领导，成员一般为PMO及适用机构领导制定的某些特定人员，对于子部门级别的项目，CCB可直接由子部门的经理担任组长，由PMO担任组员。
4 概述项目在工程活动的开始，首先要进行需求开发。
后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）既需要有过硬的专业知识，还要具备较强的交流、沟通能力，所以需求开发也是最难的。
任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。
5 过程定义5.1 需求开发与管理5.1.1 角色与职责5.1.2 入口准则◆项目已经启动；◆对于合同项目，合同已经签订。
5.1.3 输入◆项目计划5.1.4 过程活动1)、需求调查获取用户（客户和最终用户）的需求信息。
调查需求的方式包括：◆与用户交谈，向用户提问题◆参观用户的工作流程，观察用户的操作◆向用户群体发调查问卷◆与同行。
专家交谈，听取他们的意见◆分析已经存在的同类软件产品，提取需求◆从行业标准、规则中提取需求◆从internet上搜查相关资料在需求调查完成之后，需要生成需求搜集的文档，文档形式可以自定义，但搜集的需求形成的文档需要由项目经理组织进行非正式的评审，要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。
废标原因清单
废标原因清单
1. 产品需求变更：由于市场需求的变化，产品可能不再满足消费者的需求，因此需要废除该标准。
2. 技术进步：新的技术可能使得原有标准变得过时，无法适应现代化的生产或使用需求。
3. 安全隐患：某些产品可能存在安全隐患，需要废除相关的标准以确保消费者的安全。
4. 成本效益：某些标准可能过于繁琐或昂贵，不符合经济效益原则，因此需要废除。
5. 国际标准变更：国际标准组织或其他国家可能对相关标准进行了更新或废除，为了与国际接轨，需要废除相应的标准。
6. 法律法规变更：某些标准可能与最新的法律法规不符合，需要进行废除或修订。
7. 不可行性：某些标准可能在实际应用中无法实施或实现，因此需要废除。
8. 统一管理：为了统一管理和减少冗余，某些相似或重复的标准可能会被废除。
9. 低使用率：某些标准可能使用率较低，不再具有实际意义，因此
需要废除。
10. 不符合行业趋势：某些标准可能与行业发展趋势不符，需要废除或更新以适应行业发展。
需求变更
编者按：作为软件开发人员或者软件系统客户，相信都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，客户甚至会说：“当时我是那样要求的，不过现在我们的业务调整了”…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要……在本期的月刊中，我们将围绕着“需求变更”这个主题展开讨论，希望对各位开发能有所帮助。
让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。
公司再三叮咛他一定要尊重客户，充分满足客户需求。
项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。
Steven动员大家加班，保持了项目的正常进度，客户相当满意。
但需求变更却越来越多。
为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。
程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。
很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。
版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。
但在进度压力下，他也只能佯装不知此事。
但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。
而这还只是噩梦的开始。
一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。
虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。
更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。
随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。
Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。
最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。
可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。
需求变更控制流程
需求变更控制流程1目的确保需求变更被及时、全面、正确的执行。
确保需求变更的有效性。
2适用范围2.1适用于客户发出的需求变更；2.2适用于公司内部发起的需求变更；2.3适用于供应商发起的变更。
3定义需求变更：涉及到客户的产品，服务或者过程需要改变的情况。
4职责4.1业务员和业务助理负责接收客户需求变更，并负责与客户沟通相关信息；4.2业务助理负责组织客户变更的实施和推进；4.3采购负责接收供应商发起的需求变更，并组织公司内部评审和确认；4.4其它相关人员负责实施工程变更事项，并负责变更的落实；4.5总经理负责批准需求变更。
5. 需求变更控制流程5.1客户发起的需求变更控制5.2公司内部发起的需求变更所有变更要求实施事项完成后，变 更提出部门按记录管理程序，存档 工程变更单，结束工程变更。
5.3 供方发起的需求变更 序号 流程控制内容主导人 记录5.3.11. 当供应商发生以下变更时，须提 交变更申请，只有获得我司及我司 客户批准后，才可实施。
1) 产品结构或印刷内容变更； 2) 原材料规格或材质变更；需求提出3) 原材料供应商变更；4) 生产工艺流程变更；5) 场地变更；2. 变更申请须说明变更内容、变更 原因、影响产品、成本变化，加盖 公章后，附上第三方检测报告， MSD ，S 样品保证书和样品，交我司 采购。
采购需求变更申请书5.3.21. 采购接收到供应商变更申请后， 将第三方检测报告、 MSD 、S 样品保 证书给到 QE 确认是否符合环境管 理物质要求。
2. 采购将样品交生产按 5.2.3 进 行验证。
相关部门 需求变更 申请书变更申请3. 当我司品管、生产和采购均评价 变更可接受时，采购将变更申请交 业务助理，按 5.2.5-5.2.7 实施变 更。
5.3.31. 只有当客户批准的变更， 才可回记录存档复供应商可实施变更。
2. 当供应商接收到同意变更回复 后，才可实施变更。
业务/采购 需求变更 申请书变更提 出部相关记录 5.2.6相关文件无7相关记录7.1变更申请单7.2需求变更单7.3受控文件发放 / 回收记录8附件8.1 需求变更申请书8.2需求变更通知书需求变更申请书。
需求变更流程图
各类相关文档
进行详尽的需求调 研
需求调研报告
需求调研报告
用户确认需求调研 报告 用户确认通过后， 需求调研报告发送 产品部
需求调研报告
对需求进行分析，评估开 发工作量和初步版本计划
需求变更申请单
编写需求规格说明书 补充需求变更调研、系 统测试、工程实施/培训 /试运行、项目管理等工 作量，完成《需求变更 申请单》第二部分 用户对整体工 作量进行确认
需求变更流程图
输入 客户代表 项目经理 产品部 高级项目经理 销售代表 输出
项目经理协助客户填写《需求变更申请单》 （第一部分）发给高级项目经理,同时把需求 变更内容填写到《需求-问题跟踪表》（绿 色部分）
需求变更申请单 需求-问题跟踪表
高级项目经理和产品部、销售代表沟通，销售代表判 断需求变更是否要做，产品部判断该需求是否可行
需求规格说明书
需求变更申请单
需求变更申请单 对《需求变更申请单》、《需求 规格说明书》进行设计、编码、单元 测试，开发经理负责填 写《需求-问题跟踪表》 （黄色部分） 需求-问题跟踪表
更新由需求变更引起概要 设计、详细设计、数据库 设计、测试方案、用户手 册、运维手册等相关文档
需求的变更控制简介
22/2结束
未结束 未结束 27/2结束 未结束 未结束 未结束 未结束 未结束 未结束 1/3结束 51
Document NO.:
© Rosary Consultant 2008
11 11
工作量 计划时间 状态
将并入新的CDMA产品包
Document NO.:
© Rosary Consultant 2008
10 10
需求变更累积表
需求变 更号 需求变 更时间 变更说明 工作 量 状态
1
2 3 4 5 6 7 8 9 10 11
18/2
演示期 演示期 18/2 演示期 演示期 演示期 演示期 18/2 23/2 23/2
规定使用情况统计
用户阻塞 用户强迫退出 用户信息归档 关闭窗口 保存扩展数并在需要时恢复 能够在特定节点启动 删除时列出所有节点 注释（建立删除批准修改等） PENETCONFIG――支持netconfig 格式 IS-41分析器――IS-41分析器对CDMA的支持 总计
3
2 2 5 1 10 2 1 10 10 5
需求变更的影响
需求变更对项目的影响（需求增加）
变 更 之 后
原 项 目 计 划
开发进度
Document NO.:
开发资源
开发成本
质量风险
项目规模
1 1
© Rosary Consultant 2008
变更分类
变更分类
PCR
DCR
RCR
ECR
PCN
PCR：项目变更请求：常常是项目周期、资源、成本、范围变更引起的 结果 DCR：设计变更请求：设计方案变更、设计优化 RCR：需求变更请求：客户需求变更（包需求变更）、设计需求变更 （系统需求、分配需求、接口需求）； ECR：工程变更请求：对生产等下游环节的变更 PCN：产品变更通知
如何做好需求变更管理——需求变更流程规范
如何做好需求变更管理——需求变更流程规范一、引言由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。
这样就会导致测试得到的信息不完整，以及后续产品的维护困难。
在这里书写一份规范说明书，希望能得到一些改善。
二、目的控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。
保证每一次的需求改动都能有相关的记录。
三、角色与职责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. 项目名称：____________________2. 项目类别：____________________3. 项目目标：____________________4. 项目意义：____________________二、项目计划1. 项目阶段划分：- 需求分析阶段：____年__月__日至 ____年__月__日 - 设计阶段：____年__月__日至 ____年__月__日- 开发阶段：____年__月__日至 ____年__月__日- 测试阶段：____年__月__日至 ____年__月__日- 上线阶段：____年__月__日至 ____年__月__日2. 项目关键节点：- 需求评审：____年__月__日- 设计评审：____年__月__日- 开发完成：____年__月__日- 测试完成：____年__月__日- 产品上线：____年__月__日三、项目团队1. 项目经理：_______- 负责项目整体进度控制和协调各方资源2. 需求分析师：_______- 负责收集和分析用户需求3. 设计师：_______- 负责产品设计，包括界面和用户体验4. 开发团队：_______- 负责产品开发，包括前端和后端5. 测试团队：_______- 负责产品测试，确保产品质量6. 市场和销售团队：_______- 负责产品市场推广和销售四、项目风险1. 技术风险：_______- 描述可能影响项目开发的技术难题和解决方案2. 需求变更风险：_______- 描述可能引起需求变更的因素和处理方法3. 时间安排风险：_______- 描述可能导致项目延期的时间安排问题4. 资源不足风险：_______- 描述可能出现的资源不足问题及应对措施五、项目预算1. 人力成本：_______- 开发团队、测试团队、项目管理团队等人员成本2. 硬件和软件成本：_______- 服务器、开发工具、软件许可证等成本3. 外包服务成本：_______- 如有外包服务，需详细列出成本4. 其他成本：_______- 如差旅费、培训费等其他可能产生的成本六、项目监控和评估1. 项目进度监控：_______- 定期检查项目进度，确保按计划执行2. 质量控制：_______- 通过测试和评审确保产品质量3. 成本控制：_______- 监控项目成本，控制预算范围内4. 风险管理：_______- 及时识别和处理项目风险5. 项目评估：_______- 项目结束后，进行项目总结和评估七、项目实施步骤1. 启动会：_______- 项目启动，明确项目目标、计划和职责分工2. 需求调研：_______- 收集和分析用户需求，确定产品功能3. 设计评审：_______- 完成产品设计，进行设计评审4. 开发实施：_______- 按设计文档进行产品开发5. 测试和调优：_______- 完成产品测试，修复问题，优化性能6. 用户培训和上线：_______- 培训用户，准备上线，进行上线支持八、项目支持1. 技术支持：_______- 提供技术咨询服务，解决技术问题2. 培训支持：_______- 提供产品使用培训，帮助用户熟悉产品3. 售后服务：_______- 提供产品售后服务，收集用户反馈4. 长期维护：_______- 提供产品更新和升级服务九、项目时间表（此处可附上详细的时间表，包括各阶段的开始和结束时间，以及关键节点的日期）十、项目里程碑（此处可附上项目的关键里程碑，如需求确认、设计完成、开发完成、测试完成、产品上线等）十一、项目评估和反馈（此处可附上项目评估的指标和方法，以及反馈机制）十二、项目签字（此处可附上项目相关责任人的签字，以确认各方的责任和承诺）日期：____年__月__日。