[论文]需求开发流程.docVIP

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