需求管理制度V2.0.docx

- - 1 - 作者 作者 /修 日期 版本 描述 审核人 改者V2.0 肖波 修改需求开发管理流程与相关人员 分工 零壹移动互联 需求管理制度（ 2.0 版， 2015 年） 拟制人 肖波 日期审核人批准人 日期日期 修改记录 目录 第一章 总则 3 第二章 职责与分工 3 第三章 需求总体说明 4 第四章 需求提交 7 第五章 需求评估 7 第六章 需求开发 10 第七章 系统测试 11 第八章 需求上线 13 第九章 生产问题管理 14 第十章 需求变更控制与管理 14 第十一章 需求进度监控及查询 17 第十二章 附则 17 - 2 - - - PAGE 3 - 第一章 总则 第一条 为规范零壹移动互联（以下简称“零壹” ）需求管理，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制 订本制度。 第二条 本制度适用于研发部的所有系统开发需求。 第三条 本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。 第二章 职责与分工 第四条 职责分工 角色 职责 负责需求调研与编辑、编写业务需求申请表、提交业务需求审批。 根据需求评审和评估意见，及时修改业务需求，并发给需求相关干系人。 需求提交人员 项目管理人员 需求开发负责人 需求评估人员 配合需求开发、测试人员提供业务知识的支持。 协助确认需求开发结果。 负责需求上线后验证工作。 负责需求审批、评估、技术文档评审、测试、上线等需求管理流程的整体协调工作。 组织需求评估会议。 处理测试申请 提交测试部门进行分配与测试。 维护需求信息、 跟进需求变更以及需求处理进展， 定期向相关领导、部门汇报需求进展。 参与需求评审，从技术角度对需求实现方式、风险等进行评估。 制定需求开发计划，分配需求开发人员。 负责需求所有工作的沟通、协调管理。 负责需求开发进度、成员、变更管理。 负责或参与需求所有成果的审批。 从架构、业务、技术、风险等方面对业务需求的内容和实现方式进行全面评估，并提出评估意见。 审核根据评估意见修改后的业务需求。 开发人员 需求测试负责人 测试人员 生产运维人员 需求评估人员包括开发部门、测试部门、产品部门以及其他参与具体需求工作的人员。 帮助需求提交人员分析、确定业务需求。 编写需求相关技术文档。 组织实施软件需求、系统设计等文档评审，参与测试计划、测试案例、测试报告文档的评审工作。 负责需求的设计、开发，确保代码符合编码规范和代码安全规范。 负责系统集成、编译部署及单元测试。 提交测试申请，必要时提供技术支持，配合需求测试人员完成测试环境的搭建。 配合需求测试人员处理环境问题，解决测试缺陷。 负责提交上线申请，参加上线评审，配合上线部署，负责上线问题的查询和解决、上线复核。 参与需求评审，从业务测试角度参与对需求实现方式、风险等进行评估。 分配需求测试人员，对需求测试过程管理，负责需求所有工作的沟 通、协调管理。 制定 / 参与制定测试计划，参与测试案例、测试报告文档的评审工作。 参与需求评估，参与技术文档评审。 制定测试计划以及方案。 编写测试案例等相关测试文档。 实施技术测试工作，包括但部限于集成测试、功能测试、业务流程 测试、易用性测试及用户体验测试、 兼容性测试、 性能与压力测试、稳定性测试、安全测试等。 测试缺陷管理，测试缺陷处理跟进。 组织产品经理等人员体验预发布产品。 测试总结与相关业务知识文档编写与汇总。 负责生产问题的协调处理。 负责上线申请受理、组织上线需求评审。 负责生产版本备份、上线、回退。 （预留项） （预留项） 当需求提交部门对需求评估小组的评估结果存在争议时，由相关部门领导共同商议裁决。 第三章 需求总体说明 第五条 需求分类 按需求的提交部门可以分为研发部内部需求和业务部门需求。 需求类型 需求类型定义 研发部内部需求 研发部内部提出的系统开发、性能优化、软件升级等需求。产品部门需求 研发部以为的部门提交的系统开发需求，主要指产品部。 按需求的内容可分为功能开发需求、平台网站类需求、数据需求。需求类型 需求类型定义 新业务功能 已有系统中没有此功能，需要在原有基础上新增功能 功能改进 当前系统已经有此功能，因组织架构、制度规范、业务处理流程等发生功 变化，需要对现有系统的某些功能进行优化调整 能 参数调整 已有系统中已经存在该参数，需研发部对参数内容进行维护开 发 系统功能上线前，要在原有需求的基础上增加、修改或删除需求内容， 需 需求变更 求 系统问题 APP界面类需求 数据需求 但需求内容的变动会引起成本增长过大、对现有业务影响较大、或可能存在风险、合规等问题 系