1、密级：内部公开文档编号：KKCQ-Proc-RDM版本号：V1.0分册名称：第 1 册/共 1 册需求开发与管理说明编制： 胡杨 生效日期：审核： 批准： 文档更改摘要：日期 版本号 修订说明 修订人 审核人 批准人V1.0 创建 胡扬 V1.0 更换变更控制报告的模板 胡扬 V1.0 更换商业需求确认书模板 胡扬V1.0 增加产品流程及输出 胡扬需求开发流程说明第 2 页 共 11 页1. 目的通过此需求开发流程的定义，规范公司内部项目的需求开发和管理活动，提高需求质量，从而提高需求任务处理率，降低开发成本，改进系统质量。通过对业务部提交的需求进行评审，确保需求的正确性和合理性，获得需求的承
2、诺；控制需求的变更，并确保项目工作成果与需求的一致性。2. 范围适用于公司内部开发项目及已经通过商业需求确认书的项目，如未通过商业需求确认书 ，技术中心暂时无法参与需求立项，评审，分析等流程。附件一：商业需求确认书3. 术语术语或缩略语 解释需求 即用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。需求分析 是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。4. 角色与职责角色 职责程序负责人 负责审核需求内容和安排需求任务，并实现对需求任务跟踪和
3、控制需求负责人 1. 负责对需求任务的跟踪和验证；2. 负责业务需求的收集和提交5. 流程图需求开发流程说明第 3 页 共 11 页需 求 管 理 流 程提 出 需 求 需 求 立 项 阶 段 产 品 阶 段 开 发 阶 段技术中心需求评审会产品经理需求受理人需求提出人收 集 需 求需 求 整 理提 交 需 求受 理 需 求N初 审 通 过商 业 价 值 评 审 通 过商 业 价 值 评 审技 术 需 求 评 审技 术 需 求 评 审 通 过NN数 据 分 析原 型 设 计产 品 宣 讲安 排 任 务指 定 负 责 人任 务 进 度 表开 发 流 程图 1：需求开发流程图6. 主要活动需求定义
4、的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析& 定义。需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。 需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。6.1 需求定义由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。在完成需求收集所得到的记录与资料的分析与整理后，产品经理应对需求进行分类、排优先级等。需求开发流程说明第 4 页 共 11 页6.1.1 标识需求与命名规则为了便于
5、需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具体格式为：需求年月-项目类别-用途类别 如， 201310-综合信息项目-活动需求；6.1.2 需求分类由于需求来源广泛，为了便于区别，需要将需求进行分类，分类规则如下：分类规则 具体类别按项目分类 综合信息项目 行业频道项目 其他项目按用途分类 界面需求 程序需求 系统级开发 活动需求 系统功能升级 系统性能优化在需求文档中，一般取二级类别进行标识。6.1.3 需求优先级需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：级别定义 判断标准 采取的措施优先 满足以下任意一条时：） 需求实现的紧急程度为特急或紧
6、急） 国家或行业法律法规、标准要求的，满足正常业务必须的） 能够在短期内实现收益和目标突破的在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，功能才可用和被接受。这类需求在当前版本必须实现。一般 满足以下任意一条时：） 对正常业务影响程度不大） 需求实现的紧急程度为普通） 支持必要的系统操作，实现这些需求将增强系统整体的用户满意度和加大竞争胜算，用户反馈建议添加的此类需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，若有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。延缓 满足以下任意一条时：） 功能或质量上的附加功能；） 实现这些需求，会使系统整体
7、上更显完美，若不实现也不影响系统功能与性能，属于锦上添花，增强用户体验的部分；实现或不实现均可；可以在项目组有足够的时间时考虑这些需求的实现需求开发流程说明第 5 页 共 11 页） 需求实现的紧急程度为建议； 优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，正确地对需求实现的范围或实现的优先程度做出取舍。6.1.4 编写立项需求说明书在需求收集后，需求受理人应根据需求收集得到的记录与资料，整理编写立项需求说明书 ，其主要内容应该包括 但不局限于： 功能介绍：描述需求功能的用途和提出背景； 功能的最终用户（群体）及其特征； 功能需求的商业用途及数据报告；
8、 功能的具体需求说明； UE 图。编写需求说明书应遵循以下规则： 相关的需求都得到了识别与描述，以确保需求的完整性； 正确描述功能需求，引用的资料有正规的出处，以确保需求的正确性； 定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性； 使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于跟踪； 确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； 考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。提醒：编制立项需求说明书应按网站内容进行功能需求的编写；对于页面调整、活动等不需要做过多业务流程更改的需求，采用程序需求表进
9、行填写。6.2 需求评审确认及产品开发流程需求评审是指程序方和需求提出方共同对立项需求说明书进行评审，双方对需求与商业目的达成共识。在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。6.2.1 需求评审评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： 评审组长：CEO、技术总监； 评审成员：产品经理、程序员及其他
10、相关人员； 输入：立项需求说明书初稿 输出：评审结果报告需求开发流程说明第 6 页 共 11 页当需求文档评审通过后，程序方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属界定：A. 因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现的功能与预期需求不一致，由需求方承担主要责任。B. 因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现的功
11、能与预期需求不一致的，由程序方承担主要责任。6.2.2 产品宣讲产品宣讲的目的在于：按开发规范并保证需求功能白皮书及产品原型技术人员能理解、可实现、可验证、无歧义。产品经理（分为地方站产品经理与十度产品经理）对业务部门提出的需求按现有数据进行需求转化，并分辨优先级及开发级别，形成需求白皮书及产品原型后，由产品经理发起宣讲会议，安排宣讲时间、地点、程序负责人与其他相关人员参加，至少应包含以下成员： 程序负责人、程序员与需求发起人 输入：需求功能白皮书及产品原型 输出：任务进度表6.3 需求变更对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原
12、因：1. 系统所应用的外部环境发生变化；2. 随着对软件的熟悉和应用，又提出新的需求；3. 进行需求分析时未能彻底分析原始需求，或分析错误；4.在开始时不能很全面的知道所需软件的功能。需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请审批执行；如果需求变更带来的坏处大于好处，则应拒绝变更。需求受理人应适当 拒绝一些不合理的变更。如：提出的变更不是由于程序方的过错引起的，此变更可能造成程序方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行
13、处理等。变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。需求开发流程说明第 7 页 共 11 页申 请 变 更 变 更 评 审 及 审 批 执 行 变 更终 止 变 更Y E SN O6.3.1 变更申请在开发过程中，所有人员均可提出变更申请，但必须说明“变更内容和原因” ；然后打印出纸质档交由相关项目的经理核实。6.3.2 变更评审及审批将经过项目经理核实的申请依次提交给需求受理部门经理/总监进行审批。年度重点任务的页面设计需求需要由总裁确认，以确保需求的正确性、完整性和合理性。对于项目的技术方案、进度、质量、成本会产生重大影响的变更申请，需求受理人无法单独做出决定时，应
14、召开变更评审会议，并由评审人员填写评审意见，上级领导审批。6.3.3 执行变更经审批同意变更后，由部门经理根据情况安排人员和时间执行变更工作，并调整任务计划表，通知项目成员和受变更影响的相关人员，将变更申请表纸质档和电子档提交至技术中心存档备案。变更申请表的模板如下：变更申请标题 申请部门变更类型 【】需求/任务增加 【】需求/任务修改 【】需求取消 【】任务延期 【】任务中断变更原因提示：（关于需求内容的增加、修改、取消、延期、中断等都需要进行变更申请）1. 说明变更的原由2. 此变更可能对原计划任务造成的影响3. 此变更可能带来的利益重要级别： 【】重要紧急 【】重要不紧急 【】紧急不重要
15、 【】不重要不紧急变更内容提示：1. 需要变更的具体内容2. 若此变更对原计划任务有影响，必须说明计划任务处理顺序的调整（如：取消或者延期一部分非重要和非紧急的需求任务）变更申请人签字 日期： 需求开发流程说明第 8 页 共 11 页变更审核部门总监意见签字： 日期： IT 总监意见（月度重点、季度重点）签字： 日期： 总裁意见（年度重点）签字： 日期： 7. 输出立项阶段输出： 立项需求说明书 需求任务表产品阶段输出： 任务时间计划表 产品原型设计 需求功能白皮书8. 使用模板 立项需求说明书 需求任务表9. 附件：商业需求确认书商业需求确认书标题 合同编号类型 【】新增资讯类频道 【】新增
16、垂直化频道 【】新增个性化频道 需求开发流程说明第 9 页 共 11 页需求原因提示：1.此需求原因2.此需求跟现有网站的不同与影响3.此需求可能带来的利益重要级别： 【】重要紧急 【】重要不紧急 【】紧急不重要 【】不重要不紧急需求内容 提示：3. 需求的具体内容4. 若此需求对原计划任务有影响，必须说明计划任务处理顺序的调整需求申请人签字 日期： 变更审核市场总监意见签字： 日期： 总裁意见签字： 日期： 程序需求表的模板如下：程序需求表标题 申请部门需求原因提示：1.此需求原因2.此需求跟现有网站的不同与影响3.此需求可能带来的利益重要级别： 【】重要紧急 【】重要不紧急 【】紧急不重要 【】不重要不紧急需求内容 提示：1.需要修改的具体内容2.若此变更对原计划任务有影响，必须说明计划任务处理顺序的调整需求申请人签字 日期： 变更审核部门总监意见签字： 日期： 需求开发流程说明第 10 页 共 11 页IT 总监意见（月度重点、季度重点）签字： 日期： 总裁意见（年度重点）签字： 日期：
