产品需求变更申请表
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
研发部门管理制度
系统研发部门管理制度为加强对公司系统研发部门工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高开发效率，加强研发各流程环节的规范性，特制定系统研发部门管理制度。
第一章、总则为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。
1、软件开发总体遵循项目管理和软件工程的基本原则。
2、项目管理涉及产品立项、项目计划和监控、配置管理。
3、软件工程涉及需求分析、系统设计、编码实现、系统测试、产品发布、产品维护、项目总结。
第二章、阶段成果根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。
1.立项：项目立项报告、市场需求文档（MRD）。
2.需求分析：产品需求文档（PRD）、产品Backlog、项目开发计划、项目风险分析清单。
3.系统设计：系统架构设计文档、模块详细设计文档等。
4.软件实现：Sprint Backlog、源代码、单元测试代码、模块测试代码、源代码说明或者注释、复盘报告。
5.系统测试：测试方案、测试用例、测试报告。
6.产品发布：产品使用手册。
7.产品维护：产品维护记录、用户反馈记录。
8.项目总结：提交客户方的项目总结。
软件过程成果表：第三章、岗位设置第四章、项目立项1、产品经理进行市场调查与分析，确认产品的需求，进行产品研发立项，立项需提供《项目立项报告》《市场需求文档》。
2、产品立项通过后，系统研发部门根据项目对资源的需求成立项目开发组，指派研发经理，由部门和研发经理共同来确定具体项目配置、知识技能要求、团队成员及团队的角色等。
第五章、项目计划与监控1、以项目为单位，研发经理负责编写整个项目的《项目开发计划》、《项目风险分析清单》，由测试经理针对项目编写《项目测试计划》。
以上文档需提交部门进行评审。
2、在整个项目研发过程中，研发经理定期检查项目进度和完成情况，调整人员分工和安排，测试经理负责组织人员对项目的质量进行跟踪管控。
需求变更
编者按：作为软件开发人员或者软件系统客户，相信都遭遇过因为需求变更而需要修改系统的情况，一般说来客户会要求改变界面，改变操作方式，甚至改变业务，客户甚至会说：“当时我是那样要求的，不过现在我们的业务调整了”…这时需要中断正在进行的工作，需要查证以往的资料，需要修正计划，需要……在本期的月刊中，我们将围绕着“需求变更”这个主题展开讨论，希望对各位开发能有所帮助。
让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。
公司再三叮咛他一定要尊重客户，充分满足客户需求。
项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。
Steven动员大家加班，保持了项目的正常进度，客户相当满意。
但需求变更却越来越多。
为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。
程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。
很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。
版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。
但在进度压力下，他也只能佯装不知此事。
但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。
而这还只是噩梦的开始。
一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。
虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。
更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。
随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。
Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。
最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。
可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。
需求变更与优化方案
需求变更与优化方案一、需求变更分析在过去的一段时间里，我所负责的项目经历了一些需求的变更。
通过对需求变更的分析，我们可以看到这些变更的原因，以及对项目的影响。
1.1 需求变更的原因需求变更的原因主要有以下几个方面：（1）用户反馈：用户在使用产品过程中提出了一些改进的建议和意见，这些意见有助于提高产品的用户体验和功能完善度。
（2）市场变化：市场需求和竞争环境随时都在发生变化，需要我们及时响应，通过对产品进行调整和优化，以满足市场的需求。
（3）技术更新：随着技术的不断发展，我们也需要不断地进行技术升级和优化，以适应新的技术要求和提高产品的性能和稳定性。
1.2 需求变更的影响需求变更对项目的影响主要表现在以下几个方面：（1）时间成本：需求变更可能导致项目的进度延迟或重新调整，增加了项目的开发时间和成本。
（2）资源调配：需求变更可能需要重新调配项目资源，使得项目团队需要重组或增加新的成员，以满足新需求的开发和测试要求。
（3）风险管理：需求变更也带来了一定的风险，需要对变更进行评估和管理，以避免对项目的不利影响。
二、优化方案提出为了应对需求变更带来的影响，我们需要制定相应的优化方案。
以下是我针对需求变更提出的一些优化方案：2.1 需求管理优化在需求管理方面，我们可以借助一些工具和方法来提高需求的收集、分析和管理效率，以减少需求变更的次数和影响。
（1）需求调研：在产品开发之前，进行充分的市场调研和用户需求分析，确保对用户需求进行准确的把握和理解。
（2）需求评估：对需求进行评估和筛选，判断需求的优先级和可行性，避免不必要的需求变更。
（3）需求管理工具：使用专业的需求管理工具，对需求进行统一的管理和跟踪，及时反馈和处理用户的需求变更。
2.2 项目管理优化在项目管理方面，我们可以优化项目的组织和协调，以适应需求变更带来的挑战。
（1）敏捷开发方法：采用敏捷开发方法，迭代式地开发和交付产品，能够更好地应对需求变更和快速响应用户反馈。
需求变更流程图
各类相关文档
进行详尽的需求调 研
需求调研报告
需求调研报告
用户确认需求调研 报告 用户确认通过后， 需求调研报告发送 产品部
需求调研报告
对需求进行分析，评估开 发工作量和初步版本计划
需求变更申请单
编写需求规格说明书 补充需求变更调研、系 统测试、工程实施/培训 /试运行、项目管理等工 作量，完成《需求变更 申请单》第二部分 用户对整体工 作量进行确认
需求变更流程图
输入 客户代表 项目经理 产品部 高级项目经理 销售代表 输出
项目经理协助客户填写《需求变更申请单》 （第一部分）发给高级项目经理,同时把需求 变更内容填写到《需求-问题跟踪表》（绿 色部分）
需求变更申请单 需求-问题跟踪表
高级项目经理和产品部、销售代表沟通，销售代表判 断需求变更是否要做，产品部判断该需求是否可行
需求规格说明书
需求变更申请单
需求变更申请单 对《需求变更申请单》、《需求 规格说明书》进行设计、编码、单元 测试，开发经理负责填 写《需求-问题跟踪表》 （黄色部分） 需求-问题跟踪表
更新由需求变更引起概要 设计、详细设计、数据库 设计、测试方案、用户手 册、运维手册等相关文档
厂家退场申请书范文
厂家退场申请书范文一、申请原因根据与贵公司的合作协议，我方作为供应商已经履行了所承诺的交付和服务义务。
然而，鉴于以下原因，我们不得不向贵公司提出退场申请：1.产品需求变更：贵公司在合作初期提出的产品需求发生了较大的变动，导致我方供应的产品无法满足新的需求。
2.市场环境变化：经过调研和分析，我方发现贵公司所在的市场环境发生了重大变化，我们的产品在此环境下无法获得竞争优势。
3.合作意见不合：在与贵公司的合作过程中，我们发现双方在合作方式、意见沟通等方面存在较大分歧，这种合作不利于双方长期发展。
基于以上原因，我方决定提出退场申请，希望贵公司能够理解并给予支持。
二、退场计划为确保退场过程的顺利进行，我方制定了以下退场计划：1.产品移交：我方将协助贵公司顺利接收我方供应的产品，并提供相关培训和技术支持，以确保贵公司能够正常使用和维护产品。
2.数据迁移：我方将协助贵公司将在我方系统中存储的数据转移至贵公司自身的系统中，保障数据的安全和完整性。
3.合同解除：双方根据合同规定解除合作关系，并进行结算和清算工作，确保双方权益得到保障。
退场计划的具体实施细节，将由双方共同商定和确认，以确保退场过程的顺利进行。
三、退场效果评估为了了解退场对贵公司的影响，我方愿意进行退场效果评估，主要包括以下几个方面：1.产品使用情况评估：通过对贵公司使用我方产品的情况进行评估，了解产品是否满足了贵公司的需求。
2.业务运营影响评估：对贵公司的业务运营进行评估，了解退场对业务的影响程度，以及能否顺利过渡到新的供应商。
3.客户满意度调查：通过与贵公司的客户进行沟通和调查，了解退场对客户满意度的影响。
通过以上评估，我们将会得出退场对贵公司的影响和建议，以便贵公司能够更好地应对变化。
四、合作结束后的支持尽管我们决定退场，但是我们仍然愿意为贵公司提供一定的支持，以确保贵公司能够顺利过渡到新的供应商。
具体支持内容包括：1.技术支持：我们将提供一定的技术支持，以解决贵公司在产品使用过程中遇到的问题。
需求的变更控制简介
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）流程说明：需求来源：客户提交相关需求变更审核需求变更：评估如果实现该需求，需要的时间、人力成本多少；并评估对项目工期影响有多大？判断那些需求能够目前解决，那些需要留到下一版本解决。