需求开发流程管理规定

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