需求开发流程管理规定2622.pdf

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