《需求管理体系20150909》由会员分享，可在线阅读，更多相关《需求管理体系20150909（9页珍藏版）》请在金锄头文库上搜索。
1、运营部需求管理体系目录一 需求管理概述2二 需求管理内容32.1 需求收集32.2 需求初评、编写需求单32.3 需求汇总32.4 需求评估32.5 需求响应32.6 需求验收32.7 需求反馈 4三 需求管理流程4四 需求管理体系的问题分析及规范建立54.1 需求管理过程中的问题 54.2 需求管理规范 5需求管理概述从实践意义上讲，需求是针对用户各类需求经双方（或多方）沟通确认后形成的一种协 议，协议的范围是明确的、可控的。在协议签订后，需求的计划有定制、进度有跟踪、结果 有度量。针对需求的变化，需要明确需求变化的原因及变更内容。需求的紧急程度及严重程 度可评估，以确定需求及其变更的优先级
2、，从而排定切实可行的需求计划。用户对于系统、需求的理解是渐进的过程，因此某种意义上说需求变更存在必然性。如 何有效率和有效果地管理这些新增需求或变更需求是很重要的。如果需求变更控制不当，不 但造成新的需求变更得不到满足，而且对于需求进度的管理、对于系统稳定性的影响都将是 负面的。变更控制，需要追溯变更的缘由，记录变更的原因、内容，并做好变更比例的度量。 保证需求的可追溯性，对于需求变更管理至关重要；在进行需求变更对项目计划、活动及工 作产品的影响评估时尤其需要需求追溯表这些管理工具。需求管理体系规范建立及其优化。在需求管理过程中的各个环节，存在较多的争执点， 这就需要制度进行明确。形成一个系统
3、的、规范的制度，使需求管理过程可细化度量；制度 的形成需要配备对应的资源，比如需求跟踪工具、需求干系人的培训管理。通过制度保证需 求过程可监控、管理者可以跟踪需求的进展情况等。需求管理成本控制。需求开发面临成本投入的现实，需求开发本身、需求管理本身，因 需求开发、管理造成的物力、人力消耗都是现实的成本。在日常系统运作中，对于需求必要 性的评审，对于系统变更的控制，对于人员的培训都是提高效率降低总成本的方式。实际项目管理工作中，需求管理工作占据着重要的内容，下面我们结合需求管理建立一 套规范的需求管理规范。二 需求管理内容2.1需求收集用户在系统运行过程中会不断的有新的或者变更的需求提出。需求采
4、用电话、文档、邮 件等形式采集基础信息，但最终必须由需求提出人员整理。2.2需求初评、编写需求单需求提出人员对需求进行可行性分析，首先应该判断所提需求的内容表达是否清晰，需 求是否全面、是否包含关联性需求；其次还需要判定需求优先等级，给出处理意见和建议； 综合需求后编写需求报告单。2.3 需求汇总对于合理性需求，须将需求提出人员所提交的需求报告单进行统一整合汇总，同时 提交到产品对接部门。且提交需求要编号并纳入到需求管理库中。2.4 需求评估在需求文档提交到研发部门后，会对于需求进行可行性分析，在评审过程中就可能出现 理解的差异需求进行检查，最终形成是否通过该项需求的决定，并对后续需求提交、分
5、析的 质量提出指导意见。对不通过评估的可以直接回复给需求提出人员，沟通解决需求中提出的 问题。对于通过的直接启动开发或变更计划。2.5 需求响应通过评估的需求，由研发部门进行评估开发，并明确完成时间。在完成功能及业务流程 功能后，进入到开发阶段与内部测试阶段。2.6 需求验收研发部门在内部测试完成后，通知需求部门相关人员，进行需求验收测试。需求部门在 提交需求开发申请后至项目验收期间，需求原则上能进行变更。2.7需求反馈需求提出人员得到研发的修复结果的反馈报告后，必须第一时间反馈给用户。三需求管理流程用户收集需求需求初评，形威需求报告表需求汇总需求评怙需求响应需求脸收需求反馈四 需求管理体系的
6、问题分析及规范建立4.1 需求管理过程中的问题4.1.1 需求比较紧急的，直接提交给研发部门。4.1.2 需求提交方式多样，有很多口头或邮件交流内容，存在需求过于简单描述不清等 问题，后续需求管理代价较大。4.1.3 需求提出时，不够细化或后不够完全，没有考虑整体性和关联性需求；有些需求 只适用于个别分支机构；需求上存在理解差异，待功能交付后，造成需求 bug争论不休， 需求变更及 bug 修复频繁，影响系统稳定并造成成本消耗。4.1.4 没有划定需求的优先级，需求进度难以控制，过多的争论造成了临时事务增多， 对于需求开发的支持滞后，项目整体进展缓慢，用户满意度较低。4.1.5 需求提出后，经
7、过一段时间的开发，后续无人跟踪。4.1.6 需求提出者坚持一项对系统并不合理的需求。4.1.7 需求反馈速度慢，用户希望及时了解需求开发进度。4.2 需求管理规范第一条 为了确保功能和业务系统转换及生产环境稳定、最大限度的满足正常业务的开展； 稳定满足业务流程、规则的变更；特制定本管理规范。第二条 本规定约束所有需求提出部门和需求管理部门。第三条 本规范协助提高需求质量、系统开发质量，达到保证系统稳定的目的。第四条 需求必须是纸质或是文档形式需求，口头需求只能作为讨论依据，需求处理时间以 接到书面需求开始。第五条 需求提出人员经过初步评审后填写正式需求报告表，每个工作日 16:00-17:00
8、 之前形成需求打包交由需求管理部门需求接收人员统一整理汇总，需求内容必须清晰、 完整、关联性考虑周到。若需求报告表不符合要求的，重新打回需求提出人员。第六条 所有需求统一整理汇总后，必须在每个工作日下班前抄送给研发部门。第七条 需求报告表中需求标题必须明确，能够概括主要需求内容。需求表中的每一项 必须实事求是的填写（如紧急程度），需求内容描述中也必须要搭配环境图片，以求的 真实性。第八条 所提必须考虑需求间的相关性，如果有相关联的需求，必须说明关联需求的关系。第九条 所提需求必须从业务上考虑对其他小组和部门的影响和关联，如果影响到其他部门 或者小组的，必须说明。第十条 重大需求需要提供市场分析
9、或评估报告，必要时需产品经理批准。第十一条 分公司的需求需逐级上报审批，最后汇总到总公司对应部门，由总公司对应部 门综合考虑是否全面通用，是否与其他分公司有冲突，是否可以优化；综合总公司对应 部门意见后由该部门向需求管理部门正式提交需求。第十二条 需求到达研发部门后，在 2 个工作日内给出需求时间计划及反馈。并在内部测 试完成后通知需求对接人员。第十三条 需求提出人员得到研发的修复结果的反馈报告后，必须第一时间反馈给用户第十四条 需求提出人员是需求的所有者，要负责需求的完整性、关联性分析，负责需求 跟踪和测试。深圳市科盾科技有限公司运营部2015 年 09 月 10 日需求报告单表项目名称发起人产品版本需求方紧急程度需求描述：环境操作环境操作系统版本硬件型号其他重现操作流程：需求提交时间预计解决时间责任研发解决方案：验收时间
