需求上线规范

需求上线规范篇一：需求管理规范目 录 一、上线后缺陷管理流程 . 2 流程示意图 .2 关键环节说明 .2 记录系统缺陷 . 2 确认系统缺陷 . 3 录入 TD 任务 . 3 分析缺陷原因 . 3 回复缺陷报告 . 4 反馈缺陷报告 . 4 确认缺陷更新 . 4 确认 TD 任务 . 4 二、上线后需求变更流程 . 6 流程示意图 .6 关键环节说明 .7 采集需求清单 . 7 确认需求描述 . 7 分发需求清单 . 7 研讨复杂需求 . 8 回复需求清单 . 8 分解 TD 任务 . 8 沟通需求回复 . 9 审核需求回复 . 9 反馈需求回复 . 9 确认需求更新 . 10 需求管理制度鉴于物流产品线目前的产品、队伍情况，为提供更好的后台服务，完善产品质量，特制定上线后缺陷管理流程和上线后需求管理流程。 增补流程中主要涉及四个角色，定义如下： 1）前台项目负责人：一般为该项目的项目经理或者是由项目经理制定的、负责该项目具体执行的前台技术人员；一个项目只会有一个前台项目负责人；主要负责与客户进行需求沟通及需求采集、需求更新确认工作。 2）后台项目负责人：由杭州研发中心产品研发部经理与项目实施部经理协商确定，一般为开发组长或者是对产品足够了解的后台技术人员；一个项目只会有一个后台项目负责人；主要负责衔接前台与后台的职责，是后台面向前台的专一渠道。 3）开发组负责人：一般为领域组长，负责产品组织设计、开发工作；一个项目会有多个开发组负责人，视项目涉及的产品领域不同而不同。 4）产品负责人：产品经理或者产品总监，负责控制产品的整体方向。 一、上线后缺陷管理流程流程示意图 关键环节说明 记录系统缺陷 执行角色：前台项目负责人 相关角色：客户、前台技术人员 环节要点：1）前台人员调查缺陷发生的情况，记录缺陷发生的表现等各种有利于后台重现、诊断的信息； 2）采集缺陷现场的相关日志等有助于后台进行分析的相关材料； 3）紧急情况，根据需要采取适当的措施，降低缺陷的影响，并与后台保持有效沟通； 4）整理形成系统缺陷报告发送给后台项目负责人； 确认系统缺陷 执行角色：后台项目负责人 相关角色：前台项目负责人、后台技术人员 环节要点： 1）后台项目负责人根据前台项目负责人提供的缺陷情况，确认是否属于软件缺陷（排除参数设置、适用不当等方面的非软件缺陷情况） ； 2）后台项目负责人检查前台提供的相关材料以及缺陷描述是否完整准确，调整至完整准确后形成系统缺陷报告后，第一时间联系开发组负责人； 录入 TD 任务 执行角色：前台项目负责人 相关角色： 前台技术人员 环节要点： 1）在确认属于软件缺陷后，由前台项目负责人安排人员录入 TD 形成任务； 分析缺陷原因 执行角色：开发小组负责人 相关角色： 后台项目负责人、后台技术人员 环节要点： 1）开发小组负责人紧急召集后台项目负责人以及相关后台技术人员对缺陷进行分析诊断，确定其发生的原因、临时补救措施、处理方案、更新时间； 2）处理方案确定后，开发小组人安排人员进行开发。回复缺陷报告 执行角色：后台项目负责人 相关角色： 前台项目负责人、产品负责人 环节要点：1）由后台项目负责人根据讨论结果，回复缺陷原因、临时补救措施、处理方法及发布时间，形成系统缺陷报告后，第一时间发送给前台项目负责人、产品负责人，并进行必要沟通； 反馈缺陷报告 执行角色：前台项目负责人 相关角色： 客户 环节要点： 1）由前台项目负责人根据需要向客户反馈缺陷原因、临时补救措施、处理方法及发布时间，并进行必要沟通； 确认缺陷更新 执行角色：前台项目负责人 相关角色： 环节要点： 1）前台项目负责人拿到升级程序后，在测试环境上模拟升级，确认缺陷是否已解决，并未发现派生的新缺陷；2）确认通过后，寻找合适的时间更新到客户生产环境中。 关闭 TD 任务 执行角色：前台项目负责人 相关角色：后台项目负责人、开发组负责人、产品负责人 环节要点： 篇二：系统上线流程规范系统上线流程规范 根据严格管理、规范实施的要求，制定各系统上线流程规范。在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 一、 测试 a) 在系统开发完毕后首先模拟配置生产环境，并将系统部署至模拟环境。 b) 开发人员对各自开发模块功能文档化并制定测试方案，特别注意临界点测试方案。 c) 开发人员相互交换测试方案并对系统进行交叉测试。 d) 记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试方案测试结果报告。 e) 内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 二、 上线过程 a) 经技术开发以及业务需求测试完毕且确认无误后撰写上线方案，并提交相关技术负责人审核。 b) 上线方案须包括旧应用程序、数据备份等等相关原系统的所有信息副本，以便在出现升级失败后能重新恢复至先前状态。制定合理的上线时间以及上线失败的 回退步骤。c) 上线后再交由业务及需求人员进行正式环境测试，并记录测试结果及问题。提交至系统开发人员。如若出现问题不能在计划内时间解决，执行回退方案，并进行迭代改进。 d) 技术开发及相关业务保持对上线后正式生产系统进行有计划地监测，及时发现问题处理问题。 三、 提交相关文档 a) 上线成功后，须开始撰写或总结系统需求、架构以及开发文档进行备案。 附：上线流程图 篇三：产品上线管理办法 产品上线管理办法 目录 一 产品上线前准备 . 2 1、 提交测试（开发、产品部） .4 2、 接收测试（测试部） .4 3、 结束测试（测试部） .5 4、上线条件（产品部） .5 二 Bug 级别分类 . 5 1、严重错误 . 5 2、次要错误 . 5 3、不合理或别扭 . 5 4、微不足道 . 6 5、新特性 . 6 6、歧义问题, .6 三 测试流程图 . 6 1、产品测试流程 . 6 2、日常监测流程 . 8 四 沟通机制 .错误！未定义书签。 一、 目的：为了规范公司开发、产品、测试以及其他与项目相关部门之间流程上更加 合理、规范，保证产品顺利且高质量的上线展现给用户，现制定各个环节的流程且需要 在邮件中必须提供的相关内容。 二、 1. 职责： 产品规划：负责搜集汇总所有需求，形成完善的产品原型及需求文档，认定产品 bug（标准） ，决定产品发布。 2. 产品开发：按照产品需求文档完成产品的开发工作，并完成开发自测， 提交自测报告（李兵+段建功两个 team 出） 。 3. 测试与质量：结合 test case 库及产品需求文档进行产品测试，提交测试 报告。 4. 发布小组：负责对产品更新版本进行发布。 三、 决策机制： 1. 内部：产品部门提交上线报备（至少提前半天） ， 由产品规划总监确认。 涉及到如下功能播放器、后台系统、广告系统、发布系统、搜索功能的情况，由研发副总裁确认。 2. 外部：由网站部总编辑确认。 四、 工作机制 1. 产品立项： i. PRD ii. 资源支持 iii. 项目计划 2. 产品开发与自测 3. 产品规划确认功能实现 4. 产品测试 5. 产品规划确认 bug 6. 产品上线：上线会议 7. 工作流程： 9. 沟通机制： 原则：面对面、及时沟通。 测试人员应尽量把问题描述清楚，并提供图片或问题地址、测试环境等，为开发人员确定问题提供便利，对于双方存在分歧的问题可以采取以下方式： 1：测试人员主动与开发人员电话或面对面沟通，把问题发现的条件，判断问题的依据等与开发人员沟通清楚，也听取开发人员的分析。 2 通过邮件问题报告方式把测试的观点依据发送给开发工程师，并抄送双方领导，以书面形式获得更多的信息。 3 可以邀请开发工程师和相关部门的同事领导共同开会探讨问题的解决方式，以达成共识。 1、 提交测试（开发、产品部） 项目提交测试版本前，尽量请开发或者产品确保相关的文档提供给测试进行提前熟悉，保证测试时间不耽误在熟悉文档上。 （如果时间紧急，可特殊处理） 提交测试版本，邮件内容如下： 项目名称：XXXX 开发或产品负责人：XXXX 项目预估时间：XXXX （例如预计何时上线） 需求文档或说明：（无具体需求文档，则请提交版本说明） 测试环境：例如绑定地址、测试地址等； 项目 bug 指派人：（主要负责人、相关人员） 2、 接收测试（测试部） 测试人员在接到版本测试任务，需要先熟悉邮件相关的内容是否有影响测试的问题存在，如果没有，可发送接收测试邮件，邮件内容如下： 测试项目名称：XXXX 测试负责人：XXXX 测试时间：XXXX （第一轮测试、第二轮测试） 备注说明： 1、测试期间，请不要将修复的 bug，及时更新到测试环境，以免影响测试效率和时间（除了严重影响测试执行工作的问题可及时反馈、及时修改外） ； 2、第一轮结束测试，bug 修改完毕之后，请提交复测申请。 3、项目上线前，无提交复测申请，则测试不随时跟踪改变 bug 修改状态。 确保 bug 已解决的定义为：开发修复并更新 bug 状态提交复测申请。 4、上线前测试报备：测试验证确认并关闭 bug，且严重问题必须解决方可上线。 3、 结束测试（测试部）项目进入测试结束部分，完成最后一轮测试，则请测试负责人，发送邮件给项目所有相关人员。邮件内容如以下： 测试项目名称：XXXX 测试时间：XXXXX 测试负责人：XXXX 测试 bug 问题主要体现：例如：功能未实现、链接错误、设计不合理等； 测试 bug 是否影响上线：（测试角度分析，并说明问题风险，若无风险，则需要说明。 ） 测试提交 bug 列表（严重问题标示红色字体）： 测试报告文档输出。 4、上线条件（产品部） 产品部或者项目负责人，需要根据测试报告分析是否符合上线。无论是否上线均请邮件中说明原因，并及时反馈给此项目所有相关人员知晓。 五、 Bug 认定标准及分级 1、严重错误 出现这种 bug，技术人员需立即放下手头工作，马上解决。例如： A、视频无法正常播放； B、播放器功能无法正常使用（如不能清晰度切换，不能拖拽时间轴观看，不能全普屏