需求开发流程管理规定.docVIP

第 第 PAGE 8 页 共 9页 第 第 PAGE \* MERGEFORMAT 1 页 需求开发流程管理规定 1. 目的 通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。 通过对各业务部门提交的需求进行评审，确保需求的正确性和合理性，获得需求的承诺；控制需求的变更，并确保各应用软件系统工作成果与需求的一致性。 2. 范围 适用于公司各软件开发项目及已经通过《用户需求确认书》的项目，如未通过《用户需求确认书》，技术中心暂时无法参与需求立项，评审，分析等流程。附件一：《用户需求确认书》 3. 释义 术语或缩略语 解释 需求 即用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求分析 是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。 4. 流程图 图1：需求开发流程图 5. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。 需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 5.1需求定义 由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。 在完成需求收集所得到的记录与资料的分析与整理后，信息中心应对需求进行分类、排优先级等。 5.1.1 标识需求与命名规则 为了便于需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具体格式为： [需求年月]-[项目类别]-[用途类别] 如， 201310-TMS项目-运单打印需求； 5.1.2 需求分类 由于需求来源广泛，为了便于区别，需要将需求进行分类，分类规则如下： 分类规则 具体类别 按项目分类 TMS项目 NC项目 OA项目 其他项目 按用途分类 界面需求 二次开发 系统功能升级 系统性能优化 其他功能需求 在需求文档中，一般取二级类别进行标识。 5.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下： 级别定义 判断标准 采取的措施 优先 满足以下任意一条时： 需求实现的紧急程度为特急或紧急 国家或行业法律法规、标准要求的，满足正常业务必须的 能够在短期内实现收益和目标突破的 在项目实施过程中需重点投入资源，优先实现，只有在这些需求上达成一致意见，功能才可用和被接受。 这类需求在当前版本必须实现。 一般 满足以下任意一条时： 对正常业务影响程度不大 需求实现的紧急程度为普通 支持必要的系统操作，实现这些需求将增强系统整体的用户满意度和加大竞争胜算，用户反馈建议添加的 此类需求必须被实现，但如果项目实施中出现进度、资源等方面的冲突时，若有必要，可以延迟到下一版本；需要付出努力，但不必做得太完美。 延缓 满足以下任意一条时： 功能或质量上的附加功能； 实现这些需求，会使系统整体上更显完美，若不实现也不影响系统功能与性能，属于锦上添花，增强用户体验的部分； 需求实现的紧急程度为建议； 实现或不实现均可；可以在项目组有足够的时间时考虑这些需求的实现 优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，正确地对需求实现的范围或实现的优先程度做出取舍。 5.1.4 编写《立项需求说明书》 在需求收集后，需求受理人应根据需求收集得到的记录与资料，整理编写《立项需求说明书》，其主要内容应该包括 但不局限于： 功能介绍：描述需求功能的用途和提出背景； 功能的最终用户（群体）及其特征； 功能的具体需求说明。 编写需求说明书应遵循以下规则： 相关的需求都得到了识别与描述，以确保需求的完整性； 正确描述功能需求，引用的资料有正规的出处，以确保需求的正确性； 定义必要的术语，适当结合图形、结构图等方式进行描述，以确保需求无二义性； 使用较好的文档结构与需求标识，使需求能够方便地与其它工作产品相对应，以确保需求易于跟踪； 确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； 考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。 提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。 5.2 需求评