[需求开发流程.docVIP

密级：内部公开 文档编号：KKCQ-Proc-RDM 版本号：V1.0 分册名称：第1册/共1册 需求开发与管理说明 编制： 胡杨 生效日期： 审核： 批准： 文档更改摘要： 日期 版本号 修订说明 修订人 审核人 批准人 V1.0 创建 胡扬 V1.0 更换变更控制报告的模板 胡扬 V1.0 更换商业需求确认书模板 胡扬 V1.0 增加产品流程及输出 胡扬 1. 目的 通过此需求开发流程的定义，规范公司内部项目的需求开发和管理活动，提高需求质量，从而提高率，降低开发成本，改进质量。 图1：需求开发流程图 6. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。 需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 6.1需求定义 由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。 在完成需求收集所得到的记录与资料的分析与整理后，产品经理应对需求进行分类、排优先级等。 6.1.1 标识需求与命名规则 为了便于需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具体格式为： [需求年月]-[项目类别]-[用途类别] 如， 201310-综合信息项目-活动需求； 6.1.2 需求分类 由于需求来源广泛，为了便于区别，需要将需求进行分类，分类规则如下： 分类规则 具体类别 按项目分类 综合信息项目 行业频道项目 其他项目 按用途分类 界面需求 程序需求 系统级开发 活动需求 系统功能升级 系统性能优化 在需求文档中，一般取二级类别进行标识。 6.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下： 级别定义 判断标准 采取的措施 优先 满足以下任意一条时： 需求实现的紧急程度为特急或紧急 国家或行业法律法规、标准要求的，满足正常业务必须的 能够在短期内实现收益和目标突破的 在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，才被接受支持必要的系统操作，实现这些需求将增强的 此类需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，若有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美 延缓 满足以下任意一条时： 功能或质量上的 实现这些需求会使更完美； 实现或不实现均可； 6.2.1 需求评审 评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。 需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： 评审组长：CEO、技术总监； 评审成员：产品经理、程序员及其他相关人员； 输入：《立项需求说明书》初稿 输出：《评审结果报告》 当需求文档评审通过后，程序方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。 未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。 经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属界定： 因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现的功能与预期需求不一致，由需求方承担主要责任。 因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现的功能与预期需求不一致的，由程序方承担主要责任。 6.2.2 产品宣讲 产品宣讲的目的在于：按开发规范并保证《需求功能白皮书》及《产品原型》技术人员能理解、可实现、可验证、无歧义。 产品经理（分为地方站产品经理与十度产品经理）对业务部门提出的需求按现有数据进行需求转化，并分辨优先级及开发级别，形成《需求白皮书》及《产品原型》后，由产品经理发起宣讲会议，安排宣讲时间、地点、程序负责人与其他相关人员参加，至少应包含以下成员： 程序负责人、程序员与需求发起人 输入：《需求功能白皮书》及《产品原型》 输出：《任务进度表》 6.3 需求变更 对一个软件项目来说，无论最初的需求分析有多么明确，开发