需求管理制度

零一移动互联需求管理制度(版本2.0，2015 )拟人化绍博日期审计员日期批准者日期修改记录日期版本号作者/修改者说明审计员V2.0绍博修正需求开发管理流程和相关人员的分工目录第一章总则3第二章责任与分工3第三章需求整体说明4第四章需求提交7第五章需求评估7第六章需求开发10第七章系统测试11第八章需求在线13第九章生产问题管理14第十章需求变更控制和管理14第十一章需求进度监测和查询17第十二章附则17第一章总则第一条规范零壹移动互联(以下称“零壹”)需求管理，明确各阶段工作内容、处理流程、参与者及有关人员职责，在保证需求质量的同时，提高需求实现效率，制定本制度。第二条本制度适用于研发部的一切系统开发需求。第三条适用本制度的读者有需求开发责任人、需求提交人、需求评价人、开发人、测试人、生产运输业者、项目管理者等。第二章责任与分工第4条职务分工角色职责需求提交人1、负责需求调查和编辑，编写业务需求申请书，提交业务需求批准。2、根据需求重新评估和评估意见，及时修正业务需求，分发给需求相关人员。3 .根据需求开发，测试人员提供业务知识支持。4 .协助确认需求开发结果。5 .负责需求上线后验证工作；项目管理员1、负责需求审查、评价、技术文件审查、测试、在线等需求管理流程的整体协调工作。2 .组织需求评估会议。3 .处理测试申请-向测试部门提交分发和测试。4 .维护需求信息，跟进需求变更和需求处理进展，定期向相关领导、部门报告需求进展。需求发展主管1 .参加需求评审，从技术角度评价需求实现方式、风险等。2 .制定需求开发计划并分配需求开发人员。3 .负责所有工作需要的沟通、协调管理；4 .负责需求开发进展、成员和变更管理；5 .负责或参与对需求所有成果的审查。需求评估人员1、从结构、业务、技术、风险等方面全面评价业务需求的内容和实现方式，并提出评价意见。2 .审查根据评价意见修正的业务需求；3 .需求评估人包括开发部门、测试部门、产品部门及其他参与具体需求工作的人员。开发者1 .帮助需求提交人分析和确定业务需求。2 .编制与需求有关的技术文件。3、组织实施软件需求、系统设计等文件审核，参与测试计划、测试用例、测试报告审核。4 .负责设计、开发需求，确保代码符合代码规范和代码安全规范。5 .负责系统集成、编译配置和单元测试。6 .提出测试申请，必要时提供技术支持，与必要的测试人员合作完成测试环境的构建。7 .配合需求测试人员处理环境问题，解决测试缺陷。8 .提出在线申请，参加在线审查，配合在线部署，负责在线问题的查询和解决，在线审查。需求测试人员1 .参加需求评审，从业务测试的角度评价需求实现方式、风险等。2 .配备需求测试人员，对需求测试过程的管理负责需求所有工作的沟通、协调管理。3 .参与测试计划的编制/参与、测试用例、测试报告的审查。测试人员1 .参加需求评估，参加技术文件审查。2 .制定测试计划和方案。3 .编制测试用例等相关测试文件；4 .实施技术测试，包括集成测试、功能测试、业务流程测试、易用性测试、用户体验测试、兼容性测试、性能和压力测试、稳定性测试、安全测试等。5 .检查缺陷管理，检查缺陷处理跟进。6 .组织产品经理等人员体验事先发布的产品。7 .测试总结和相关业务知识文件的编制总结。8 .负责生产问题的协调处理。生产承运人1 .负责在线申请的受理、在线需求的审查；2 .负责生产版本的备份、在线和回滚。(预约)(预约)需求提交部门对需求评估小组的评估结果有争议的，由有关部门领导共同协商裁决。第三章需求总体说明第5条需求分类根据需求提交部门分为研发部的内部需求和业务部门的需求。需求类型需求类型定义研究开发部的内部需求研发部内部提出的系统开发、性能优化、软件升级等需求。产品部门的需求研发部提出的系统开发需求，主要指产品部。根据需求的内容分为功能开发需求、平台站点的类别需求、数据需求。需求类型需求类型定义功能开启留头发需求求新业务功能现有系统没有此功能，因此必须向现有系统添加功能增强功能目前的系统已经具有这一功能，由于组织结构、制度规范、业务处理流程等发生了变化，需要对现有系统的部分功能进行最佳调整参数调整现有的系统中已经存在这个参数，研究开发部需要维护参数的内容变更需求在系统功能上线前，必须根据传统需求添加、更改或删除需求，但是更改需求可能导致成本增加，对现有业务产生巨大影响，或者可能存在风险、合规性等问题系统问题系统的现有功能可以正常使用，但性能、安全性、底层处理逻辑和体系结构等将来可能成为业务进一步扩展的瓶颈APP接口类要求1.app首页的设计、开发、更新的变更与维护只有关系，不需要与其他系统对话。2.app首页的设计、开发、更新的变更和维护，需要与其他系统进行对话。数据要求1 .面向客户的数据：适用于客户，与客户直接相关的数据，包括向客户发送邮件、赠送积分、赠送权利礼物等背景数据处理需求。2 .管理数据：用于管理分析或活动效果监视和效果评价的报告和详细数据。根据需求的紧急程度，可以分为紧急需求和普通需求。需求类型需求类型定义紧急需求需求提交人必须事先确定在线时间，如果正常资源分配和时间表不能按期在线，则必须通过领导人的特殊批次增加资源，紧急处理某些流程，才能满足在线需求。一般需求紧急需求以外的需求。根据需求，开发工时的大小可以分为大需求、中型需求、小型需求。需求类型需求类型定义大规模的需求开发工时200工时的需求。中等规模的需求开发工时100工时，=200工时的需求。小规模需求开发工时=100工时的需求。第六条需求开发管理流程图需求开发管理流程包括(建议由项目管理员统一管理需求)需求管理主要包括：需求评估、开发、测试和在线阶段的管理细则遵循本制度的有关规定。 不参与功能开发的平台级的需求和数据需求，可以根据情况裁断需求开发管理过程的一部分工作。各阶段包括的活动和流程请参阅以下各章的详细说明。第四章需求提交第7条需求提交为提高需求质量和处理效率，减少需求变更次数，研发部各组(开发、UI、测试)与产品部门就需求内容和实现方式等达成一致，形成会议记录档案，需求申请表 (或邮件形式)同时提交需求批准。在提交需求之前，您必须确认以下内容(一)与开发人员联系，确定需求类型；(二)需求的可行性分析。 各部门/小组在进行可行性分析时应关注的内容如下1 .研发部对需求的技术可行性进行初步分析，帮助需求提交人识别相关系统。2 .需求相关系统的归属开发者评估需求是否满足业务发展计划以及需求对系统现有业务功能的影响。3 .产品部、开发人员、测试人员对需求的业务逻辑、风险、法规遵从性等进行初步评价。第8条需求会署原则上，中、大型项目和需求需要通过会议签字过程，要求各部门相关同事和领导进行审查，通过审查，进入后续的开发过程。 根据公司的具体情况，灵活运用这个制度。第五章需求评估第9条需求评估程序需求评估流程说明和责任分担：(1)需求调查、需求文件开发完成后，产品管理者需要将需求提交项目管理者进行统一管理，项目管理者需要将需求文件提交研发部想要开展的各部门会议。 会议将签署通过后的组织需求评估会议。(二)项目管理人员审查有关因素； 包括参与会署审查的有关人员是否齐全，各有关人员是否通过审查。附件：紧急需求另行处理(如完善，可分为业务需求、紧急需求、生产QC三类)。(3)需求评估会评估的内容如下：1 .审查需求内容并分析需求合理性：需求开发主管从技术层次初步评估需求的技术可行性、效能等测试部及其他相关产品部门，从业务角度评估需求的业务逻辑、业务流程、业务目的、风险、合规性等内容。2 .初步确认需求的实现方式；3 .初步评估需求的开发工作量。4 .明确需求系统的设计、编码、测试、在线阶段的里程碑和各阶段的交付件和负责人。5 .确定需求评估的结论。(4)需求评估结束后，填写需求评估表 (设计等待表格)，应填写的内容如下1 .不开发或有变更的事项2 .这一需求对其他相关系统的影响3 .需求所需人才、工时、里程碑及总体评价的结论等。(5)完成评价表的填写后，评价者当场签名确认，项目管理者检查需求评价表的信息是否完整正确。第十条需求评估的考虑因素需求评估主要从技术观点和商业观点出发。需求评估通过后，需求提交人根据需求评估的结论更新需求，更新后的需求成为研究开发部开发的最终依据(避免需求多次变更)。发生以下情况之一时，评估组需要在提出意见后，将需求退回产品部更新需求或接受各部门领导的审查。(一)技术水平；1 .系统结构需要大规模改造。2 .涉及系统架构变更。3 .与其他需求重复。4 .需求有不合理事项的；5 .需求不需要明确补充的；6 .目前的技术无法实现。7 .评估时发生重大变更且未通过变更核准的。(二)业务水平；1 .与目前业务操作的流程、运营相矛盾。2 .需要大幅度改变传统业务流程，增加大量人工后续处理成本。3 .业务需求不符合业务目的的；4 .新需求引起的新业务流程未出现在需求内。5 .业务流程不顺利、业务规则不明确或不出现、在线后，业务运营可能无法正常进行或存在运营风险。因以上原因退回的需求，需求提交部门对需求评价小组的评价结果有争议时，可以向各部门领导提交仲裁。第六章需求开发第11条需求开发过程(略、具体流程由开发署规定)第十二条设计开发：需求评估通过后，需求开发负责人安排和调整需求设计和开发工作。(1)开发人员根据需求评估会通过的业务需求进行设计开发，完成需求技术文档。(二)技术文件通过需求开发责任人审核后，开发人员提交项目管理人员。 本技术文件应从结构、环境、安全、性能等层面审查技术文件，并及时提出审查意见。(三)项目管理人员审查有关因素； 包括技术文件是否符合要求、审查员参与度、审查是否合格。 审查通过后的需求进入了开发阶段。 审查失败的，项目管理者将技术文件送回开发人员，由开发人员处理后提交相关人员审查。(4)技术文件审核合格后，开发人员将审核合格的技术文件更新为SVN，开展开发工作。应急需求应通过需求评估后，开展设计开发工作。 设计开发阶段的部分工作，经项目管理人员批准后，可以根据情况进行裁剪。第13条单元测试集成测试(1)代码完成后，开发者需要进行单元测试、系统集成、编译配置以及主要功能测试。 测试通过后，制作单元测试报告、版本导入工作文件，提交需求开发责任人的审查。(二)需求开发责任人通过审核后，开发人员将源代码单元测试报告、版本部署操作文件更新为SVN，需求开发责任人将版本部署操作文件上传到SVN。第七章系统测试第十四条系统测试：通过单元测试(包括系统集成)后进入系统测试阶段以下是系统测试的步骤系统测试流程说明：(1)需求开发负责人向项目管理者提出系统测试申请。(2)项目管理员审核相关要素，如要求是否通过评估、技术文档是否通过审核、单元测试是否通过、单元测试报告、需求技术文档、版本展开操作文档是否上载到SVN等。 审核通过后，项目管理者向研发部质量管理部的测试经理提交系统测试通知书。 如果审计失败，则返回到开发子流程。(3)测试经理分配系统测试人员。(4)系统测试人员验证SVN内的技术文件、版本的部署以及主要功能是否必要。 验证通过后制定测试计划，如果验证不通过，则返回开发子流程。(5)系统测试计划、测试用例、测试报告书应由系统测试人员编写，组织审查，系统测试人员和需求开发人员参加审查。(6)补充：测试计划、测试计划、测试用例等测试文件，设计时间以第6条(需求开发管理流程图)为参考，按照尽快参加测试工作的原则，发生特殊情况时，测试文件也可以在测试开始时执行。第八章需求在线第十五条需求在线：检验检验结束后进入需求在线阶段。 需求线主要分为业务线、技术线。第16条需求在线流程需求联机流程说明：(一)需求在线申请；需求测试通过后，测试经理检查测试人员提交的测试工作，审查通过后，提交项目管理员调整计划开发的在线时间。(二)网上实施后，需求相关人员需要网上验证(3)如在线研究或验证失败，开发人员将从生产环境退回在线版本，需求转移到开发