需求管理方法论材料.ppt

目的 更深刻的理解需求以及它的价值 更深入的理解需求的层次和类型 为良好的需求管理建立坚实的方法论基础 为更有效的管理需求给出实践和建议 大纲 需求管理介绍 需求管理的重要概念 需求跟踪 深入管理需求 编写好的需求 需求变更管理 需求管理介绍 什么是需求？什么是需求管理？ 常见问题 需求管理的重要性和益处 项目成功因素 项目规模是关键 什么是“需求”？ 任何影响产品或系统设计制造方式的信息 功能 性能 安全性 可用性 …… 复杂的产品/项目有数以千计的需求 飞机、汽车、火车、手机…… 同义词 目标，规则，规约，约束，要求，特性，标准…… 需求无处不在 什么是“需求管理”？ 为什么要进行需求管理? “分析报告指出多达71％的项目失败是因为差劲的需求管理，这个是项目失败的最主要的原因，比落后的技术，进度失控或者混乱的变更管理还要关键”  CIO Magazine, 2005/11 多米诺骨牌效应 错误的需求会对项目的整个生命周期造成多米诺骨牌效应 遗漏用户需求将导致遗漏系统功能点,又将导致遗漏设计模块,最终导致功能失效 常见问题 需求只存在组织中那些“专家”的脑子里，没有被记录下来 有时客户的需求会被忽略 而有时候开发的功能却不被客户使用 客户签字确认了需求却一直提出修改要求 需求变更对项目影响很大，难以确定变更的影响范围和成本 市场部门、开发部门、测试部门跨部门的沟通存在问题，例如需求变化时不能迅速通知到测试部门去调整测试计划和案例。 需求规格说明书的要求都实现了，客户却不满意 需求的研发状态，需求变更的状态难以掌握 电信业和银行业15个项目统计 Hofmann and Lehner 2001 最成功的项目在需求工程上投入了28%的资源：需求获取，需求建模，需求确认和验证等 平均每个项目在需求活动上投入了15.7%的工作量和占了 38.6%的时间 需求管理的作用 I —— 提高质量 关于质量，Crosby的定义很简单——与需求一致。 正确的需求：正确的功能的前提 一致性 与需求保持一致并不仅仅在项目的后期用测试来验证，更强调的是在项目的每一个阶段都紧紧围绕需求这个主线来开展工作。 需求跟踪正是保证需求演化的整个过程都是与需求保持一致，以此保证项目和产品的最终质量 需求管理的作用 II —— 成本控制 目标正确是第一位的——需求的正确捕获和表达 在项目后期才发现需求的缺陷，修复需要非常高的成本 需求分析 分析得出带来最大价值的需求 同时得出所需的成本 我们的目标： 合理成本下的效益最佳 需求变化时如何控制成本 洞察变更影响 影响分析:迅速定位需要进行修改的模块 第一时间采取措施能降低成本和缩短时间 需求管理的作用 III —— 支持项目进度的管理 真实项目进度的反映 例如，多少需求已经被实现，它们的状态如何？ 又如哪些需求已经有对应的测试案例，哪些需求已经测试通过？ 需求驱动开发 需求活动在项目正式立项之前就展开 需求分解后的功能点/模块成为项目管理中的需要实现的任务 课程大纲 需求管理介绍 需求管理的重要概念 需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次 需求捕获 需求跟踪 深入管理需求 编写好的需求 需求变更管理 需求的 “沙漏” 需求的 “沙漏” 需求的 “沙漏” 需求的 “沙漏” 孙子兵法 需求的 “沙漏” 需求管理的困难 需求文档的文档反映需求的演变层次 某个银行研发中心的需求演进的层次 业务规格说明书 － 软件规格说明书 － 概要设计－详细设计 某个电信制造厂商的需求演进的层次 市场需求－ 产品包需求 － 设计需求－… 某个芯片提供商的需求演进的层次 市场需求－产品需求－ 系统功能－… 不同的产品/系统，不同的公司，对自己的需求体系有自己的定义 典型的需求层次 业务需求 定义一个机构达到的目标和目的。 用户需求(涉众需求) 说明用户需要系统提供什么能力帮助其完成任务。 系统需求 说明系统必需完成什么功能才能提供用户所需的。 业务需求 我们为什么要进行这个项目？ 组织的业务目标 提高公司的运营效率——内部信息管理信息系统 提高产品的市场竞争力——对商业软件 通常来自 投资方 管理层 市场部 产品部 常见文档记录方式 工作说明书 前景和范围文档 市场需求文档 项目计划书（可行性报告） 业务需求 若对项目预期的范围和目标有不同的理解，就无法对下列获得一致意见 对哪些用户应该被访谈获取需求 哪些功能应该被纳入 现象 某些特性先被添加，又被删除，又被加入 分布式开发团队尤为重要 决策基础 目标版本 应用的广度和深度 需求变更 用户需求（涉众需求） 用户的目标，用户希望完成的任务 影响系统的需求信息类型： 业务目标 使用场景 外部约束 用户界面需求 接口需求 环境的约束 业务规则