研发部需求开发规程管理
精心整理
管理目标
1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。
2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。
3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。
执行概述
1、
2、
3、跟踪设计/开发/测试/回归/
4、/跨部门协
调等几个方面。
5、
6、风险识别、风险控制以及风险的预案。
项目管理
1、需求阶段
2
根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。
设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。
该阶段交付成果需要进行评审。
3、执行阶段(开发和测试)
准备开发环境、测试环境。
跟踪，推动项目按计划进行。
项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。
按里程碑对阶段成果进行评估，以确保该阶段完成的质量。
代码审核，包括CS审核、SQL审核、WEB审核等。
对需求变更进行控制管理。
测试阶段BUG响应及改进、收集反馈意见。
对项目风险进行管理。
4、发布阶段
包括制定项目发布计划，用户培训，发布上线。
5、试运行阶段
数据监控(日志、服务器状态)
定情况执行补丁升级。
6、收尾阶段
产品交付，项目总结会。
常见问题
1、开发时间的估算
算，通常单个模块开发时间取决于以下因素：
1
2(包括对框架和应用的熟悉程度)。
3
开发者没有相关的代码可以参考，自己也没有经验，
1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。
2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下：
A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开
发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。
B、技术难度较大的模块由技术水平比较高的人负责。
C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
3、模块分配完成后，开发人员评估自己负责开发的模块所需要的时间。在此过程中应与开发者讨论每个模块的技术实现细节，使时间的估算更加准确。
4、对开发人员估算的时间进行确认。在确认过程中作为，项目管理者将预估时间和开发人员估算时间进行比较。那些差异较大的，与人员探讨其中的缘由。对于时间周期比较长的任务，将任务拆分为更小的子任务，每个任务的完成时间为8-24工时，消除时间周期较长的任务，避免不确定性影响项目的进度。
2、CodeReview
CodeReview是保证项目中代码质量非常重要的一个环节，在这一环控制不严往往是测试后出现大量bug的主因，有时甚至导致返工；关于CodeReview执行，首先应有编码规范和代码审查规范。代码
审核者根据这些标准来CodeReview
CodeReview一般可按以下步骤实施：
1、
2、
3、
bug，对这些bug记录在案。
4、Bug。同
5、
6、
7、中发现的有价值的问题更新到"代码审核规范"的文档中，对于特别
给所有技术人员。
3
需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响项目的成功与否。
对待需求变更的正确态度：
1、需求变更是不可避免的。
2、需求变更要必须被管理。
3、积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。
需求变更管理的目标：
1、相关的干系人必须清楚地了解发生的变更。
2、变更处于有效的管理中。
3、尽量降低变更带来的风险。
通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的目标。需求变更流程：
1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任何需求改变，都需要走需求变更流程。
2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。
3、项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。项目管理者对项目的成功与否负有主要的责任。需求变更的决策应由项目管理者做出。
45、确定
员。
6的相关内
7
及时沟通和处理。
8
4、风险管理
1
人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。
在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。
2、项目目标扩大以及需求变更
在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这
种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求。
前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户)，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、UserCase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。
3、代码质量风险
质量风险主要指开发代码的质量。
合理的开发时间对开发质量的影响很大。
系统设计文档对指导开发非常重要。
4
3天，但一个新手可能就需要7-10天。项目管理者应该在前
的技能培训，以保证项目的顺利实施。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。
5、缺乏良好的团队协作
软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融
为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。
6、项目会议
组织会议是项目执行过程中一项非常重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，不成功的会议会对项目本身造成了不好的影响。
不成功的会议通常表现为如下形式：
1、会议氛围不好，参与者发言不踊跃；
2、会议讨论常常偏离主题；
3、会议没有取得预期的结果；
4、会议时间常常一拖再拖。
都对这样的会议都有抵触情绪，也可看作
1
得成功，这是会议成功的充分条件。
2
议的参与者和你一样，对会议有着如此的期待，
3
1
2
3
4
5
说：
A、再一次强调会议的目标，我们来做什么。
B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要
是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。
C、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，
等别人说完你再说等等。
6、会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良
好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。
7、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。
8、会议要有结论。我们常在会议上听到有人说："大家讨论了这么半天，结论呢？"。没有结论的会议是没有意义的。
9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。
10、会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。
11、按时结束的会议会受到所有人的欢迎。
？·
技术研发中心管理制度样本
技术中心管理制度 为了建立一个良好的激励机制, 更好地调动科技人员的工作积极性, 充分发挥大家的潜能, 科学、合理、高效地完成公司的新产品开发工作。特制订本管理制度, 本制度包括组织机构建设、总则、日常管理制度、课题管理制度、技术秘密管理制度。 一、组织机构的划分及职责 1.1产品市场开发研究室: 具体职能如下 1) 国内外相关产品市场调研与分析 2) 综合产品信息分析与研究 3) 课题( 项目) 可行性研究和咨询论证 4) 行业( 产品应用) 发展水平与趋势调研与分析, 对产品市场应用情况数据进行处理和统计分析 5) 经过市场调查、分析, 挖掘潜在的产品应用领域 6) 收集来自产品应用单位的信息, 提出新产品开发意见和建议 7) 负责编制新产品的研发方案 8) 负责新产品开发的标准化制定 1.2 产品研发行政事务研究室: 1) 负责研发人事管理制度
2) 对新产品试验进度安排及组织协调 3) 协助包装、标签、编码、送样等具体事项 4) 负责日常办公、试验物资的采购管理工作 5) 负责新产品的注册报批相关事项, 应用研究工作的组织联络、督促协调、质量监督、进度追踪等 1.3专利信息研究室: 负责本公司的专利工作。包括专利信息、专利说明书起草、申报等事项。 1) 产品行业政策法规咨询 2) 新产品咨询与评估 3) 文献收集、检索与资料翻译 4) 研发中心局域网的各种数据库的管理和维护等 5) 提出专利工作思路、专利文书的撰写及专利申报工作 6) 专利商标申报 7) 专利、商标权的维持和转让事务 8) 专利战略制定与组织实施 9) 专利、商标侵权监视与诉讼 10) 专利数据资料的管理与维护 11) 图书资料和期刊管理与维护
新产品开发项目管理办法
Q/ZSZDXM01新产品开发项目管理办法 版本号： 标准化： 审定： 批准： 重庆宗申宏立座垫制造有限公司发布 新产品开发项目管理办法 目的
为建立健全公司制度、规范新产品开发流程，使新品项目按计划进行，特制定本管理办法。范围 本办法适用于公司所有的新产品开发项目全过程的管理。 定义 新产品开发是指从研究选择适应市场需要的产品开始到产品设计、工艺制造设计，直到投入正常生产的一系列决策过程。 职责 公司领导 4.1.1对项目立项、项目撤销进行决策； 4.1.2任命项目主管或经理； 4.1.3对项目计划进行评审；对项目进行过程中的重大里程碑、重大变更计划做出决定； 4.1.4对项目的绩效进行考核。 项目部 4.2.1项目立项前期组织各部门对项目进行可行性评价； 4.2.2召集成立项目小组，召开项目阶段性评审会（主要指手工样件、工装样件、小批送样评审）； 4.2.3适时更新项目进度表，确保新项目按照客户的要求顺利投产，有异常情况时向客户报告。4.2.4定期或不定期组织召开以产品工程师、供应商质量工程师、采购工程师、物流工程师、客户质量工程师、生产管理等为主要成员的项目推进会，督促、协调各部门及供应商按时、保质、保量完成各项工作； 4.2.5协调客户与公司内部各部门的沟通，最大程度地满足客户合理的需求。 4.2.6对开发阶段客户提出的座椅交样数量及试验样椅等各种需求的座椅，项目部下达计划到物流计划部（5套以下手工样件下达计划到技术部）。 4.2.7按照《项目管理考核办法》Q/ZS-MSZDRY03，进行考核。 财务部 4.3.1立项前期对产品进行投资回报分析，确定从财务角度出来该项目是否可行； 4.3.2按客户要求对产品进行报价和议价，并对各种费用进行审核。 4.3.3按项目费用预算计划准备资金。 4.3.4对新产品材料提出目标价格。 技术部 4.4.1项目立项前期对该产品进行技术分析，确定从技术角度出发该项目是否可行，能否满足客户
需求管理规范V
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
软件开发流程图.docx
软件开发流程图 项目前期 需 求 变 化项目启动 需 要系统实变现 更系统调测 开始 获取用户需 编制初步方 编制进度 / 跟踪 需求基本确定 编制详细预 配置内部资 分配开发任 系统实现 控制/调 无需变更 技术调测 PM：获取 EU主要的关键性需求 PM：根据 GM安排编制简略 / 详细的建设方案 PM：基于内部预算对 EU提供费用报价 PM：与 EU确认需求变动及方案、费用调整 PM：完成详细内部预算并提交给GM PM：通过内部项目管理系统配置详细人员、进度安排 PM：移交 EU需求给PG，安排 PG开发任务 PG：根据 EU需求及 PM要求，执行开发任务 PM：通过内部项目管理系统审核PG工作日志， 确认 EU需求变动，执行进度控制，必要时变 更人员安排及内部预算 PG：技术调测及修改；根据TE 测试文档调试修改集成测
部署试
TE：进行集成测试，编制测试文档，提交PM，送达PG 未 通 过通过 通过项目后期 系统验收 结束PG：部署至外部服务器 PM：系统初验 EU：试用 PG ： 部署正式上线，编制开发字典，提交PM M 获得试用意见 TE：编制系统操作手册、功能列表，提交PM PM：提交开发字典、操作手册、功能列表给EU,通过内部项目管理系统结项，向 GM汇报 备注： PM (Project Manager)：项目经理PG (Programmer)：程序员EU (End-User)：最终用户TE (Test Engineer)：测试工程师GM (General Manager)：总经理 硬件开发流程图
产品调研 / 新产品立设计开发执行子项目分支执 首样评审业务部主导 研发部 研发部主导 业务部 研发部主导 研发部主导 业务部 采购部 研发部主导 业务部 工程部 1、资料搜集并拟定产品需求表 ① 预期的用途，特定的功能、性能和安全要求； ② 类似产品的名称，型号或参考实物样板； ③ 细化客户对产品的外观、功能、价格等要求； ④拟定《产品需求表》展开评审会议 , 并形成《技术可行性分 析报告》同时交总经理审批。 2、研发经理组织结构、电子与ID 协调定义，进行3D 图形设计 与修改，形成《产品外观效果图》《产品3D 图》、《产品规 格书》会同业务、总经理展开评审会议，若评审通过，由业 务形成《立案通知书》和《产品研发任务书》交总经 理审批，输出交研发部进行设计开发工作。 注： B 类项目可直接评估形成《产品研发任务书》 3、研发部签收《产品研发任务书》 , 项目负责人根据《产品外 观效果图》、《产品 3D 图》、《产品规格书》、《产品研发 任务书》的要求对设计工作进行策划形成《项目进度表》，包括： ① 设计过程中各阶段时间和工作内容的安排； ② 设计评审、设计验证、设计确认的安排； ③ 设计过程中各项工作的分工及各小组之间的接口及工 作顺序等； 4、项目负责人根据《项目进度表》推进设计，每设计阶段 必须与研发部经理进行设计评审，设计评审完成后研发部 完成硬件打样，首样制作由该项目各负责工程师共同制作， 并完成《样机测试记录表》、《操作说明》、《首样评审表》， 并填写《线路板通知书》、《开模申请表》交研发经理审核。研发 部根据设计评审结论编制 BOM、电路原理图、贴片图的PDF电子 版、结构爆炸图、《样机测试记录表》、《软件测试 记录表》、《样机测试记录表》并存档。 5、结构电子依《首样评审表》内容，对需要做设计变更的 尤其产品外观改动的，需经总经理批准的《设计变更表》， 才能对其模具设计修改，并填写《改模记录表》。首样评审完 成修改通过后，发放至工程部由工程部汇总完成《工程 样机测试汇总表》，3 个工作日后由项目负责人组织电子、 结构、工程、品质、业务进行项目首样评审。
公司研发部管理制度(最新版)
研发部管理制度 2017年2月
目录 第一章研发部组织结构与责权 (3) 一、研发部组织结构 (3) 二、研发部职责与权力 (3) 三、研发部岗位职责 (4) 第二章研发部工作流程 (10) 第三章产品研发管理制度 (11) 第四章研发部人员绩效考核制度 (14) 第五章研发部人员培训管理制度 (14) 第六章研发部人员保密协议 (14)
第一章研发部组织结构与责权 一、研发部组织结构 根据我公司实际情况且结合产品研发设计特点，制定研发部组织结构示例如图1-1所示。 图1-1 二、研发部职责与权力 2.1、研发部职责 2.1.1、建立、健全企业产品技术研发管理体系及管理制度，并组织实施。 2.1.2、根据企业总体战略规划及年度经营目标，制定新产品开发、工艺技术开发的中长期发展规划和年度计划，报董事长审定、批准实施。 2.1.3、对现有产品进行跟踪，根据生产、销售、技术反馈的情报资料，及时在设计上进行改良。 2.1.4、组织并协同技术部进行新产品开发、老产品改进过程中的设计评审、小批试制、产品试验和技术确认等技术管理工作。
2.1.5、负责新产品试制过程中的工艺技术质量信息的收集、处理、整改和验证。 2.1.6、组织收集、整理与研发有关的新理念、新技术、新工艺、新材料等资料，并进行归档。 2.1.7、负责相关技术文件（含各种电子资料）的制定、审批、归档和保管。 2.2、研发部权力 2.2.1、对生产政策的制订有参与权。 2.2.2、对产品研发战略、新产品项目有审核权。 2.2.3、对新产品开发、老产品改进工作的开展有决策权。 2.2.4、对技术工艺标准、质量标准有决策权。 2.2.5、对不遵守技术工艺规程、质量标准的个人有提请处罚的权力。 2.2.6、对生产计划以及产品能否上市销售工作有建议权。 三、研发部岗位职责 3.1、研发总监岗位职责 研发总监的岗位职责是在总经理的授权下，全面负责产品研发管理工作，规划公司的技术发展路线与新产品开发，对技术研究、产品开发、分析测试、中试研究等过程进行监督和控制。其具体职责如下： 1、组织、指导制定企业技术研究、产品开发、分析测试、中试
需求管理规范
目录 2 1.前言......................................................................................................................... 3 2.需求管理背景......................................................................................................... 3 3.需求管理流程......................................................................................................... 4 4.指导规范................................................................................................................. 6 5.需求管理体系......................................................................................................... 6 5.1.制度 .............................................................................................................. 7（一）总则 .............................................................................................................. 7（二）机构职责 ...................................................................................................... （三）总体工作流程 ............................................................................................ 10 10（四）需求提出 .................................................................................................... 10（五）需求分析 .................................................................................................... 11（六）需求评审 .................................................................................................... 12（七）需求跟踪 .................................................................................................... 12（八）需求实现 .................................................................................................... 12（九）附则 ............................................................................................................ 13 5.2.细则 ............................................................................................................ 13 5.3.流程图 ........................................................................................................ 14 5.4.评审细则 .................................................................................................... 15 5.5.模板 ............................................................................................................ 5.6.编写指南 .................................................................................................... 16 16 6.合理性评价...........................................................................................................
新产品开发部门工作流程图
新产品开发部门工作流程图 新产品开发策略 要紧方式 呈 报 时期性工作总结 新产品样品开发 新产品开发过程
附件一：内部治理制度 新产品开发工作，是指运用国内外在基础研究与应用研究中所发觉的科学知识及其成果，转变为新产品、新材料、新生产过程等一切特不规性质的技术工作。新产品开发是企业在激励的技术竞争中赖以生存和进展的命脉，是实现“生产一代，试制一代，研究一代和构思一代”的产品升级换代宗旨的重要时期，它对企业产品进展方向，产品优势，开拓新市场，提高经济效益等方面起着决定性的作用。因此，新产品开发必须严格遵循产品开发的科学治理程序，即选题（构思。调研和方案论证）样（模）试批试正式投产前的预备这些重要步骤。 一、调查研究与分析决策 新产品的可行性分析是新产品开发中不可缺少的前期工作，必须在进行充分的技术和市场调查后，对产品的社会需求、市场占有率、技术现状和进展趋势以及资源效益等五个方面进行科学预测及技术经济的分析论证。 （一）调查研究： 1、调查国内市场和重要用户以及国际重点市场同 类产品的技术现状和改进要求；
2、以国内同类产品市场占有率的前三名以及国际 名牌产品为对象，调查同类产品的质量、价格、 市场及使用情况； 3、广泛收集国内部外有关情报和专刊，然后进行 可行性分析研究。 （二）可行性分析： 1、论证该类产品的技术进展方向和动向。 2、论证市场动态及进展该产品具备的技术优势。 3、论证进展该产品的资源条件的可行性。（含物 资、设备、能源及外购外协件配套等）。 （三）决策： 1、制定产品进展规划： （1）企业依照国家和地点经济进展的需要、从企业产吕进展方向、进展规模，进展水平和技 术改造方向、赶超目标以及企业现有条件进 行综合调查研究和可行性分析，制定企业产 品进展规划。 （2）由研究所提出草拟规划，经厂总师办初步审查，由总工程师组织有关部门人员进行慎密
银行产品研发项目组管理细则
中国ⅩⅩ银行产品研发项目组管理细则 第一章总则 第一条为提高产品创新工作质量和效率，明确产品研发项目组工作职责，规范中国ⅩⅩ银行产品研发项目组工作流程，依据《中国ⅩⅩ银行产品创新与管理委员会工作规则》、《中国ⅩⅩ银行产品创新与管理办法》等制度，制定本细则。 第二条本细则所称项目工作是指根据《中国ⅩⅩ银行产品创新与管理办法》立项并审批通过后进行的产品研发活动。产品研发项目组是具体实施项目的业务团队，具体任务为完成业务需求和制度办法的编制、需求解释与变更、业务测试、验收试点等工作。 第三条本细则适用于项目实施过程中所组建的产品研发项目组。 第二章产品研发项目组构成 第四条总行各部门、分行(分中心)在申请立项时提出项目组组建方案，包括项目组人数、项目组成员来源部门/分行、具体职责及工作任务、技能要求、到位时间等建议。 第五条项目组人员构成 根据项目需要，项目组由总行各部门、分行或外部合作伙伴委派专业人员构成。项目组成员须具备项目所需专业知识，项目经理还需具备组织协调能力和项目经验。 （一）产品研发部是产品研发的综合管理部门，需派出产品经
理或产品经理组参加所有的产品研发项目组，全程参与项目实施。产品经理服从项目组管理，重点进行产品概要设计与把关、对需求说明书规范的应用进行指导和讲解、参与需求说明书编写工作。 （二）项目牵头部门是产品研发的组织实施部门，负责组建项目组，派项目经理和专职人员参加产品研发项目组，负责和参与项目实施全流程的管理工作和相关具体工作。 （三）业务主管部门需派专职人员参加产品研发项目组，参加需求编写，负责制度办法、产品宣传培训方案、广告设计方案的制定，并为接手产品上线后的相关工作做好准备。 （四）科技部门需派专职人员参加需技术开发的项目组，参加需求讨论与技术实现可行性的评估，保证项目进入技术开发阶段的工作效能。 第六条项目实施期间，各部门应保持项目组成员的稳定，不得随意抽调或变更，项目组成员需服从项目组调配。如需调整，各部门应提前与项目牵头部门沟通，在不影响项目组工作进展的前提下，酌情予以变更。如需更换项目经理，项目牵头部门需报产品研发部核准后进行。 第三章产品研发项目组工作职责 第七条项目组职责 （一）负责拟定需求工作计划，报项目牵头部门批准后予以实施； （二）负责分析讨论产品创意，按照需求说明书规范完成业务需求编写工作，完成《XXX产品需求说明书》；具体要求参见《关于规范我行产品需求说明书编写工作的通知》（农银办发【2009】259
技术研发中心档案管理制度
合资 电器有限公司 技术研发中心档案管理制度 编辑日期:二零一零年十月 技术研发中心档案管理制度 一、适用范围 本制度规定了技术研发中心档案管理人员的职责,以及技术档案的建立、维护要求,规定了公司技术挡案的审查、批准、复审、借阅及消毁的程序与规则。 本制度适用于技术研发中心关于技术档案管理工作。 二、档案管理岗位责任制 1、分管领导(技术研发中心)职责 1、1、组织宣传、贯彻、执行《中华人民共与国档案法》与公司关于档案工作各项规章制度。 1、2、加强对公司档案工作的领导,将档案工作纳入整体发展计划,列入议事日程,督促各相关技术研发项目组按要求做好应做的工作。 1、3、关心档案工作与档案(室)的建设与发展,及时解决工作中的重大问题与困难,改善工作条件,使档案工作与公司各项工作协调发展。 2、档案员职责 2、1、贯彻实施《档案法》等档案工作的法律、法规,贯彻公司档案管理制度。 2、2、对技术研发中心工作过程形成的各种挡案材料,负责收集、整理、立卷与归档,同时负责进行指导与监督。 2、3、负责维护档案的完整、准确与安全,并为技术研发中心的各项工作需要提供服务。 2、4、按年度向公司挡案部门报送完整且备于查询的各类档案统计材料。 3、技术研发项目(小组)分管领导职责 3、1、技术研发项目确定后,负责配备兼职档案管理人员,用于技术研发执行过程中,各类档案的收集、整理与立卷工作。 3、2、帮助兼职档案人员解决工作中的实际困难,并不定期进行抽查。 3、3、组织项目小组人员学习档案法规,执行公司档案工作的规章制度。
3、4、积极配合兼职档案人员做好项目档案的归档工作,对归挡材料的完整性、正确性与及时性负责。 3、5、协同兼职档案人员监督、检查项目执行过程各类文件材料的立卷、整理组卷与归档验收等工作。 3、6、负责检查本项项兼职档案人员履行档案岗位职责。 4、技术研发项目兼职档案人员职责 4、1、根据项目不同种类文件材料的形成特征,制定案卷类目,合理分类存放,同时便于日常应用,坚持日常整理。 4、2、负责项目文件材料的形成、积累、保管与整理归档工作,保证归档文件材料完整、准确、系统。 4、3、需要归档的项目案卷,做到组卷合理,页号编写准确,案卷目录清楚,案卷标题简明扼要。 4、4、保管好项目应归档的案卷,注意文件材料的安全与保密。 4、5、主动接受公司档案人员对项目挡案的业务指导与督促检查,按规定时间向公司档案室移交相关档案材料。 4、6、积极参加业务学习,不断提高档案工作水平。 4、7、按公司档案室的要求,对项目档案归挡时再次整理,并编制检索工具。 三、档案文件材料收集与归档制度 收集归档范围:本公司在技术研发过程中,形成的具有保存价值的,与本公司关系密切的各类文件材料(包括公文、书信、会议记录、图纸、登记表、奖品(奖状)、照片、录音带与录像资料等),都属于技术研发中心工作过程应收集归档的材料范围。 1、项目研发中心文件材料 1、1、各种技术研发项目的专业会议记录或会议纪要。 1、2、技术研发项目工作计划、规定、方案、总结与汇报材料。 1、3、针对技术研发工作形成的各种调查、检查、考察报告。 1、4、向公司请示工作形成的文书。 1、5、各项决定、决议、规定、标准、规范、制度、守则等。 1、6、科研设备、技术/工艺原图、蓝图及文字材料。 1、7、技术研发过程中重要活动的照片、录音/录像资料。 1、8、上级针对公司技术研发而颁发的奖状、奖旗及奖品等。 1、9、电报与重要的研发工作日记。
业务需求管理制度
业务需求管理制度 第一条总则 规范各部门有关业务需求的提出、变更及维护，为整体业务系统建立统一的需求管理机制和跟踪机制，从而提高沟通效率及需求反馈的响应速度和透明度，保障产品开发结果与需求的一致性，特制定本细则。 第二条适用范围 本规定适用于管理所有业务部门提交到本部的所有需求。 第三条定义 1、业务需求：对需要在整体业务系统中实现或调整的业务功能的说明或描述； 2、业务需求方：为公司整体业务系统提出所要实现或调整功能的部门，包括无线运营部、销售服务部和财务结算部等； 3、业务需求承接方：负责承接业务需求，目前由产品技术部的产品专员对接各部门的需求。 第四条需求的重要程度 需求部门所需功能对整体业务系统的影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a)非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节； b)重要：业务系统所需的该项功能对整体业务系统影响大； 页脚内容1
c)一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。第五条需求的紧急程度 需求部门所需功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。 a)非常紧急：所提业务需求非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施； b)紧急：所提业务需求比较急迫，如不尽快实现，业务流程不能被正确执行，但存在可替代措施或方法； c)一般：所提业务需求急迫性一般，不会对现有流程存在较大影响。 第六条需求提交 各部门通过JIRA填写详细需求信息，向需求承接方发起需求任务，在需求提出时需注意以下几个方面： 1、详细描述需求背景、需求内容，包含需求介绍、功能性需求详细描述及数据需求描述，明确本部门需求对接人； 2、提出需求时应说明需求的重要程度和紧急程度； 3、提出需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理； 4、为更加清楚地说明业务需求变更情况，可附带附件、附图等文档。 第七条需求分析 1、需求承接方就接受到的需求进行需求分析，需求不明确的地方与需求方及时进行沟通，并在 页脚内容2
产品开发项目管理规程(V0.1)2007
产品开发项目管理规程 1目的 本规程基于产品开发系统CPD流程，用于规范产品开发团队在产品开发过程中的管理。目的是保证产品开发的顺利实施，为PDT团队进行项目管理操作提供快捷帮助，统一项目管理步调，提高项目管理效率。 本规程整体上将项目管理各要素按项目启动、项目计划制定、项目执行、项目控制及变更、项目结束过程进行有机融合；各要素的相关详细操作均以模板和附件形式出现；本规程也涵盖了项目依赖管理、对外合作项目管理和项目管理IT指南。 2适用范围 本规程适用于所有产品和技术开发项目过程管理。 3 项目启动 项目概念阶段开工会作为项目管理活动起点。如图1所示：
图1 项目计划制定与CPD流程阶段对应关系 4 项目计划制定 项目计划包括主项目计划（进度计划）、人力资源计划、物料计划、风险计划、质量计划、项目预算。项目计划制定须严格按照对应的模板和规范进行。项目计划归档在IT管理系统中，作为项目过程管理和项目控制的基线。 4.1 主项目计划制定 如图1所示，PDT经理和PDT核心组在CPD主流程相应阶段共同制定主项目计划。
主项目计划由概念阶段项目计划（WBS）、端到端项目计划（WBS）构成，计划一旦经过评审就形成基线，并以此作为项目度量计算进度偏差的基线。 其中，端到端项目计划（WBS）与人力资源计划、项目预算在计划DCP完成后基线化。 主项目计划各基线确定一周内，PDT须在产品开发项目管理IT系统上发布。 计划评审通过后须及时发布，具体操作说明见表1： 表1 项目计划发布操作
4.1.1 主项目计划（进度计划）制定操作指导 项目计划制定的流程图、步骤和方法分别如图2： 图2 项目计划制定流程图 4.1.2 概念阶段项目计划（WBS）制定 计划制定前提：完成概念阶段项目开工会 计划制定责任人：PDT经理（LPDT） 计划制定参与者：PDT核心组成员 输出：《概念阶段项目计划（WBS）》 模板：《概念阶段项目计划（WBS）》模板 计划制定步骤： 1）获取《概念阶段项目计划（WBS）》模板； 2） PDT经理组织PDT核心组成员进行概念阶段的活动分解（WBS）、确定概念阶段主要活动/里程碑和重要的依赖关系； 3） PDT经理分析关键路径，并和PDT核心组成员共同确定主要活动/里程碑的时间； 4）各PDT核心组成员分别制定各功能领域的工作计划。步骤如下： 根据活动分解（WBS）的结果对项目计划模板中的任务进行裁剪；
技术研发部管理制度
技术研发部管理制度 一、总则 技术研发部的主要职能是负责实验室、化验室管理、辅料的研究开发，技术参数的研究及配比优化、配合市场开发部进行对外市场推广等。 二、工作职责 1、技术研发部办公室管理制度 1）、部门职工每日上班前五分钟需打扫自己办公区域卫生，保持办公桌清洁。办公区公共卫生由部门人员轮流值日，要求一天一打扫，一周进行一次大扫除，必须保证摆放整齐、地面清洁、墙壁无污迹。 2）、值日人员下班后在确保办公室门窗锁好、一切电源切断的情况下方可离开。 3）、每日在岗人数不少于两人，准时签到、签退，不得补签及代签。 4）、爱护办公室内所有办公设施，如人为损坏，照原价赔偿。 2、技术研发部部长岗位责任制 1）、坚决服从上级领导的统一指挥，认真执行其工作指令，如有问题需及时汇报。 2）、负责制定实验计划，并组织对计划的拟定、修改、补充、实施等一系列技术组织和管理工作。 3）、及时指导并处理实验过程中出现的技术问题，确保试验的正常进行。 4）、做好与王台铺矿、天地公司的对接工作，使双方最大限度实现数据互通、优势互补。 5）、考核每天的试验结果，从而决定次日充填的材料配比，并向王台铺矿出具料浆合格证书。 6）、审核每批次原材料的化验结果，确保原材料的合格后联系安全调度部进行充填。 7）、每月组织技术人员进行技术成果及经济效益的评价工作，并对技术员的每月工作进行考评。 8）、负责编制项目部技术开发计划，并有计划的引进、培养专业技术人员，
从而进一步搞好技术研发部的工作。 9）、积极与北京科技大学等科研院所进行技术交流，做好技术对接工作。 10)、按时完成项目部领导交办的其他有关事项。 3、试验室工作职责 1）、贯彻执行党和国家有关方针政策及上级有关工程检测试验方面的条例、制度和指示。 2）、在项目部的领导下，负责充填浆液质量检测工作，配合化验室对原材料质量进行检测和试验。 3）、根据项目部工作目标和规划，制订试验室各阶段的工作计划。 4）、负责新配方的研发工作，并对新配方的膨胀率、泌水率、抗压强度等技术指标进行全面检测，建立健全相关台账。 5）、对每批次的充填料浆进行事前试验，试验各项数据符合充填要求后，出具充填配比验收单，并由技术研发部、安全调度部、现场操作员三方签字确认。 6）、对每批次的充填浆液进行现场取样，并对其膨胀率、泌水率、抗压强度等技术指标进行全面检测，建立健全相关台账。 7）、在充填过程中，对各种原材料的用量、机械设备转动参数进行不定期检查，全力保证充填料浆配比符合要求。 8）、负责试验室仪器设备的管理及制订重要仪器设备选购、使用、保养制度。 9）、建常用检测试验项目的操作规程，定期进行检测仪器设备送检、标定，确保仪器的完好率。 10）、定期检查仪器设备准确度，提高检测试验人员思想素质和职业道德，以数据为依据，不弄虚作假。 11）、积极与天地公司联系，经常性进行经验和工作方法的交流，做到双方数据互通。 12）、参与相关技术培训考核。 13）、完成项目部交办的其他有关事项。 4、试验员岗位责任制 1）、试验员必须及时完成试验室下达的试验和检测任务。 2）、认真做好试验前的准备工作，即按要求正确取样、校对仪器、设备量值、
需求管理规范 (2)
需求管理体系改进方法研究 需求管理过程 当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下： 1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。 2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。 3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。 4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。 5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。 6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。 7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。 8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
产品委外合作研发管理规范
产品委外合作研发管理 规范 SANY GROUP system office room 【SANYUA16H-
产品委外合作研发管理规范 XX有限公司 2015年8月 {项目名称} 项 目 合 同
目录 1.合同介绍 (3) 2.开发内容 (3) 3.乙方开发计划 (4) 4.甲方监控计划 (5) 5.甲方验收计划 (6) 6.乙方维护计划 (7) 7.禁止转委托开发 (7) 8.保密 (7) 9.知识产权归属 (7) 10.第三方知识产权 (8) 11.风险责任的承担 (8) 12.报酬及支付方式 (8) 13.违约与赔偿 (9) 14.不可抗力 (9) 15.解除合同 (9) 16.争议解决 (10) 17.一般条款 (10) 18.合同确认 (11) 附件 (11)
1.合同介绍 1.1甲方 1.2乙方 1.3合同目的 甲、乙双方经友好协商,一致达成本协议。双方申明，双方都已理解并认可了本合同的所有内容，同意承担各自应承担的权利和义务，忠实地履行本合同。 2.开发内容 2.1开发内容 （此处将简单描述项目开发内容，详细内容将在附件中包含。） 2.2技术指标和质量要求 （此处为甲方填写，对项目的具体指标和质量要求） 2.3应当遵循的标准和规范 1、此项目将严格按照软件开发标准和规范进行研发。
3.乙方开发计划 3.1开发期限和开发地点 本项目的开发期限为个月，自年月日至年月 日为止。 本项目的开发地点是。 3.2任务与进度 1、甲、乙双方将根据甲方为其业务开发项目及其所需功能的描述和甲方所提供的资料与信息共同制作项目需求分析。甲方在提交有关需求说明、资料和信息时，可以就其中所涉及的软件功能、目标、需求构成及相关技术问题向乙方咨询或征求意见，乙方应当及时予以解释和答复。 2、乙方在获取上述需求信息和资料后，应及时完成需求分析书。该需求分析书经甲方认可，并由甲、乙双方签字后作为本合同的附件。 3、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成需求说明书， 4、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成概要设计说明书， 5、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成详细设计说明书。 需求说明书、概要设计说明书以及详细设计说明书在完成后，均应提交甲方审核。 3.3开发进度报告
研发部管理规章制度
新产品新技术新工艺的开发工作是指运用国内外在基础研究与应用研究中所发现的科学知识及其成果转变为新产品、新材料、新生产过程等一切非常规性质的技术工作. 新产品开发是企业在激烈的技术竞争中赖以生存和发展的命脉, 是我公司实现“生产一代, 试制一代, 研究一代和构思一代”的产品升级换代宗旨的重要阶段,它对企业发展方向,产品优势,开拓新市场,提高经济效益等方面起着决定性的影响.因此, 产品开发必须严格遵循产品开发的科学管理程序、即选题（构思、调研和方案论证）、样（模）试、批试、正式投产前的准备这些重要步骤. 一、调查研究与分析决策新产品新技术的可行性分析是新产品新技术开发中不可缺少的前期工作, 必须在进行充分的技术和市场调查后, 对产品的社会需要、市场占有率、技术现状和发展趋势以及资源效益五个方面进行科学预测及技术经济的分析论证. （一）调查研究: 1. 调查国内市场和重要用户以及国际重点市场同类产品的技术现状和改进要求; 2. 以国内同类产品市场占有率高的前三名以及国际名牌产品为对象, 调查同 类产品的质量、价格、市场及使用情况; 3. 广泛收集国内外有关情报和专刊, 然后进行可行性分析研究. （二）可行性分析: 1. 论证该类产品的技术发展方向和动向. 2. 论证市场动态及发展该产品具备的技术优势. 3. 论证发展该产品的资源条件的可行性.（含物资、设备、能源及外购外协件配套等）. 4. 初步论证技术经济效益. 5. 写出该产品批量投产的可行性分析报告. （三）决策: 1. 制定产品发展规划: （1.）公司根据自身发展的需要, 从公司产品发展方向,发展规模,发展水平和技术改造方向, 赶超目标以及公司现有条件进行综合研究和可行性分析, 制定公司产品发展规划. （2）由研发部提出草拟规划，公司总经理办公室初步审查, 由总经理组织有关部门人员进行慎密的研究定稿后, 报董事长批准, 由生产技术部下达执行. 2. 瞄准世界先进水平和赶超目标,为提高产品质量进行新技术、新材料、新工艺、新装备方面的应用研究:
需求开发流程管理规定
需求开发流程管理规定 1. 目的 通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。 ，
4. 流程图 图1：需求开发流程图
5. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 在需求文档中，一般取二级类别进行标识。 5.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：
●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； ●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。 提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。 5.2 需求评审确认及开发流程 需求评审是指程序开发方和需求提出方共同对《立项需求说明书》进行评审，双方对需求与商业目的达成共识。
在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。 5.2.1 需求评审 评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。 需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由信息技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： ●评审组长：总裁及总裁办相关领导、信息技术总监； ●评审成员：项目经理、程序员及其他相关人员； ●输入：《立项需求说明书》初稿 ●输出：《评审结果报告》 当需求文档评审通过后，程序开发方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。 未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。 经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属 界定： A.因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现 的功能与预期需求不一致，由需求方承担主要责任。 B.因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现 的功能与预期需求不一致的，由程序开发方承担主要责任。 5.3 需求变更 对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原因： 1. 系统所应用的外部环境发生变化； 2. 随着对软件的熟悉和应用，又提出新的需求； 3. 进行需求分析时未能彻底分析原始需求，或分析错误； 4.在开始时不能很全面的知道所需软件的功能。 需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。 只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。 需求受理人应适当拒绝一些不合理的变更。如：提出的变更不是由于程序开发方的过错引起的，此变更可能造成程序开发方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。 变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。