需求管理方法论要点
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对产品的功能作出了补充，从不同方面描述了产品的特性 如可用性，可移植性，健壮性等等。
45
影响系统功能的需求信息类型
业务目标 —— 业务需求 使用场景 —— 用例 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
46
场景和用例
用于以下目的的技术：
17
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求变更管理
18
需求的 “沙漏”
19
需求的 “沙漏”
需求开发
标识涉众 收集需求
高度分散、凌乱的 非结构的信息
36
每个涉众都有各自的需求集
业务
最终用户
客户
销售员
安装和维护
管理者，经理 培训和支持
技术支持
运输和装卸
考虑所有可能的用户. 遗漏了他们的任何需求都会导致系统问题的出现 或系统失败
37
标识涉众
Stakeholder: 涉众 涉众是对于系统有利益关系或关注的个人，团队或组织。 [IEEE 1471]
测试方
操作方
信息化部
信息化部
39
捕获需求
我们必须知道哪些信息是从来的——需求的来源 我们必须知道哪些信息是我们需要的——需求的分类
引出系统功能的需求信息 非功能性需求的信息类型
我们必须善于发现需求——捕获需求的技巧
40
用户提供给我们的足够的信息吗？
没有？不知道？ 我们知道要收集哪些信息吗？
突然，国王和护城河承包商发生了激烈 争执，然后，需求管理诞生了。
9
为什么要进行需求管理?
“分析报告指出多达71％的项目失败是因为差劲的需求管理，这个是项目失
败的最主要的原因，比落后的技术，进度失控或者混乱的变更管理还要关键
”
CIO Magazine, 2005/11
10
多米诺骨牌效应
错误的需求会对项目的整个生命周期造成多米 诺骨牌效应 遗漏用户需求将导致遗漏系统功能点,又将导致 遗漏设计模块,最终导致功能失效
系统边界的确定 需求的筛选 需求的演化 正式的需求陈述: 单独的, 唯一的, 清晰的, 准确的, 抽象的, 良好的, 可测试的
问题陈述
正式的结构化的需求
可追踪的
解决方案 设计
22
孙子兵法
23
需求的 “沙漏”
“追求胜利”
选择做正确的事情
“作战”
将事情做对
24
需求管理的困难
需求：
不明确 众多来源 难以用文字表达 关联内容太多 变更 数量巨大
由集装箱卸货
需求管理方法论
1
目的
更深刻的理解需求以及它的价值 更深入的理解需求的层次和类型 为良好的需求管理建立坚实的方法论基础 为更有效的管理需求给出实践和建议
2
大纲
需求管理介绍 需求管理的重要概念 需求跟踪 深入管理需求 编写好的需求 需求变更管理
3
需求管理介绍
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求Hale Waihona Puke Baidu更管理
34
捕获需求
我们必须知道哪些信息是从来的——需求的来源 我们必须知道哪些信息是我们需要的——需求的分类 我们必须善于发现需求——捕获需求的技巧
35
捕获需求
活动:
标识涉众 与涉众交流 收集需求 给需求的重要程度排序 选择需求 记录需求
12
电信业和银行业15个项目统计
Hofmann and Lehner 2001
最成功的项目在需求工程上投入了28%的资源： 需求获取，需求建模，需求确认和验证等 平均每个项目在需求活动上投入了15.7%的工作 量和占了 38.6%的时间
13
需求管理的作用 I —— 提高质量
关于质量，Crosby的定义很简单——与需求一致。
15
第一时间采取措施能降低成本和缩短时间
典型
缩短了 开发时间
工作量
较好
时间
16
需求管理的作用 III —— 支持项目进度的 管理
真实项目进度的反映
例如，多少需求已经被实现，它们的状态如何？ 又如哪些需求已经有对应的测试案例，哪些需求已经测试通过？
需求驱动开发
需求活动在项目正式立项之前就展开 需求分解后的功能点/模块成为项目管理中的需要实现的任务
飞机、汽车、火车、手机……
同义词
目标，规则，规约，约束，要求，特性，标准……
7
需求无处不在
需求
8
什么是“需求管理”？
进行需求管理的目的是在客户 和 ...项目 ...之间建立统一的 认识。 这种与客户一致的认 识是规划和管理 … 项目的基 础。”
卡内基梅隆大学软件工程学院 软件能力成熟度模型（CMM）。 www.sei.cmu.edu/cmm
43
影响系统功能的需求信息类型
业务目标 使用场景 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
44
非功能性需求的信息类型
“真实的现实系统中，在决定系统的成功或者失败的因素 中，满足非功能性需求往往比满足功能性需求更为重要。 ” 性能 软件质量属性
管理层的 支持
15%
14%
17%
5% 7%
用户积极 参与程度
23%的项目在完成 之前被取消
有经验的 项目经理 熟练的员工 敏捷的需求过程
源于: “Chaos Chronicles, III, 2003”. www.standishgroup.com
5
项目规模是关键
60 50 40 less than $750K $750K to $1.5M $1.5M to $3M $3M to $6M $6M to $10M Over $10M
非功能需求
必须被系统满足的潜在的条件. “约束补充了系统的质量但不会作为一个功能存在.” 对于系统而 言，约束不增加任何特殊的工作, 但它起到保证系统满足所需的功 能,保证系统更可靠,更易使用. “音乐点歌系统能够储存15,000,000个在线账号.” 非功能需求能够作为一个重要规则或条件组织和实现.
什么是需求？什么是需求管理？ 常见问题 需求管理的重要性和益处
4
项目成功因素
28%的项目按时并 在预算内完成 49%的项目超出原 先估算
时间平均延迟了 63% 成本超出了45%
可靠的 规范的 估算 方法 标准的 组织结构 最小化范围 清晰的商业目标
6%
5% 5%
12% 14%
不同的产品/系统，不同的公司，对自己的需求体系有自 己的定义
26
典型的需求层次
业务需求
定义一个机构达到的目标和目的。
用户需求(涉众需求)
说明用户需要系统提供什么能力帮助其完成任务。
系统需求
说明系统必需完成什么功能才能提供用户所需的。
27
业务需求
我们为什么要进行这个项目？ 组织的业务目标 提高公司的运营效率——内部信息管理信息系统 提高产品的市场竞争力——对商业软件 通常来自 投资方 管理层 市场部 产品部 常见文档记录方式 工作说明书 前景和范围文档 市场需求文档 项目计划书（可行性报告）
用户的目标，用户希望完成的任务 影响系统的需求信息类型：
业务目标 使用场景 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
用户需求 - 涉众需求的通俗解释
30
系统需求
产品中实现的功能性需求
用户以此完成工作 进而满足业务需求
描述包含多组件的系统的顶级需求
31
如果世界就这么简单……
业务需求
用户需求
系统需求
32
项目中各种信息交织在一起
用户
市场 设计 系统需求 测试 实现 部署 维护 培训 支持
33
业务
客户
法律/ 规章
质量/ 标准
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
25
需求文档的文档反映需求的演变层次
某个银行研发中心的需求演进的层次
业务规格说明书 －> 软件规格说明书 －> 概要设计－>详细设计
某个电信制造厂商的需求演进的层次
市场需求－> 产品包需求 －> 设计需求－>…
某个芯片提供商的需求演进的层次
市场需求－>产品需求－> 系统功能－>…
系统边界的确定 需求的筛选 需求的演化
问题陈述
正式的结构化的需求
需求管理
解决方案 设计
20
需求的 “沙漏”
许多相关人员.
人
定义问题.
一些的需求专家
问题陈述
定义解决方案 工程
工 程
21
需求的 “沙漏”
标识涉众 收集需求.
访谈，调查问卷 观测用户现有系统 改进建议，问题报告 ，创新研究
高度分散、凌乱的 非结构的信息
子目标 子目标 子目标 子目标
子目标
最终目标
子目标
子目标
子目标
实现最终目标 的步骤
子目标
子目标
序
操作顺
48
应用情况举例（一件行李）
交行李 乘客入座 称重
登机
受控 登记 贴标签
测量
装机 就绪 行李拥有人 在目的地 提行李
安全检查 运至登机口
装机
装入集装箱 装机
飞行
飞行 再次装机
卸机
装机
卸机
由飞机卸货
目标正确是第一位的——需求的正确捕获和表达 在项目后期才发现需求的缺陷，修复需要非常高的成 本 需求分析 分析得出带来最大价值的需求 同时得出所需的成本 我们的目标： 合理成本下的效益最佳 需求变化时如何控制成本 洞察变更影响 影响分析:迅速定位需要进行修改的模块
11
常见问题
1. 需求只存在组织中那些“专家”的脑子里，没有被记录 下来 2. 有时客户的需求会被忽略 3. 而有时候开发的功能却不被客户使用 4. 客户签字确认了需求却一直提出修改要求 5. 需求变更对项目影响很大，难以确定变更的影响范围和 成本 6. 市场部门、开发部门、测试部门跨部门的沟通存在问题 ，例如需求变化时不能迅速通知到测试部门去调整测试 计划和案例。 7. 需求规格说明书的要求都实现了，客户却不满意 8. 需求的研发状态，需求变更的状态难以掌握
详细描述涉众需求 研究揭示涉众需求的情形 按照每个目标或状态生成需求
改善与涉众的沟通
用涉众语言表达应用情况
确保需求的完整性
覆盖全部情况的多种应用
结构化编写需求文档
用主场景作为标题结构
导出验收测试
设计覆盖所有应用情况的测试
47
用户场景作为不同层次的目标
水平 2 水平 1
28
业务需求
若对项目预期的范围和目标有不同的理解，就无法对下列 获得一致意见
对哪些用户应该被访谈获取需求 哪些功能应该被纳入
现象
某些特性先被添加，又被删除，又被加入
分布式开发团队尤为重要 决策基础
目标版本 应用的广度和深度 需求变更
29
用户需求（涉众需求）
正确的需求：正确的功能的前提 一致性
与需求保持一致并不仅仅在项目的后期用测试来验证，更 强调的是在项目的每一个阶段都紧紧围绕需求这个主线来 开展工作。 需求跟踪正是保证需求演化的整个过程都是与需求保持一 致，以此保证项目和产品的最终质量
Phil Crosby
14
需求管理的作用 II —— 成本控制
成功率(%)
30 20 10
Project Size ($) $ 项目规模（ Standish Group, ‘99 (www.standishgroup.com) ）
6
0
什么是“需求”？
任何影响产品或系统设计制造方式的信息
功能 性能 安全性 可用性 ……
复杂的产品/项目有数以千计的需求
有哪些涉众角色？ 投资方（系统的投资方） 主管方（批准/管理系统的） 最终用户（用户/系统受益方） 操作方（操作/维护系统的） 监管方（认证系统的） 测试方（负责系统验收） 其它（受系统影响的）
38
概念：涉众角色
涉众角色举例 XXX 系统：
投资方 主管方 用户代表 最终用户 监管方 计划部 信息化部 市场部 营业员 审计部
41
客户不会给你一个清晰全面的需求列表
业务目标 使用场景 业务规则 功能性需求 质量属性 接口需求 约束 数据的要求 等等
42
需求分类
功能需求
系统必须实现的能力. 某些系统必须完成的工作. “系统能够为运输和装卸工作人员提供打印运输标记功能.” 能够作为一个逻辑时序组织和实现的功能是功能需求.
45
影响系统功能的需求信息类型
业务目标 —— 业务需求 使用场景 —— 用例 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
46
场景和用例
用于以下目的的技术：
17
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求变更管理
18
需求的 “沙漏”
19
需求的 “沙漏”
需求开发
标识涉众 收集需求
高度分散、凌乱的 非结构的信息
36
每个涉众都有各自的需求集
业务
最终用户
客户
销售员
安装和维护
管理者，经理 培训和支持
技术支持
运输和装卸
考虑所有可能的用户. 遗漏了他们的任何需求都会导致系统问题的出现 或系统失败
37
标识涉众
Stakeholder: 涉众 涉众是对于系统有利益关系或关注的个人，团队或组织。 [IEEE 1471]
测试方
操作方
信息化部
信息化部
39
捕获需求
我们必须知道哪些信息是从来的——需求的来源 我们必须知道哪些信息是我们需要的——需求的分类
引出系统功能的需求信息 非功能性需求的信息类型
我们必须善于发现需求——捕获需求的技巧
40
用户提供给我们的足够的信息吗？
没有？不知道？ 我们知道要收集哪些信息吗？
突然，国王和护城河承包商发生了激烈 争执，然后，需求管理诞生了。
9
为什么要进行需求管理?
“分析报告指出多达71％的项目失败是因为差劲的需求管理，这个是项目失
败的最主要的原因，比落后的技术，进度失控或者混乱的变更管理还要关键
”
CIO Magazine, 2005/11
10
多米诺骨牌效应
错误的需求会对项目的整个生命周期造成多米 诺骨牌效应 遗漏用户需求将导致遗漏系统功能点,又将导致 遗漏设计模块,最终导致功能失效
系统边界的确定 需求的筛选 需求的演化 正式的需求陈述: 单独的, 唯一的, 清晰的, 准确的, 抽象的, 良好的, 可测试的
问题陈述
正式的结构化的需求
可追踪的
解决方案 设计
22
孙子兵法
23
需求的 “沙漏”
“追求胜利”
选择做正确的事情
“作战”
将事情做对
24
需求管理的困难
需求：
不明确 众多来源 难以用文字表达 关联内容太多 变更 数量巨大
由集装箱卸货
需求管理方法论
1
目的
更深刻的理解需求以及它的价值 更深入的理解需求的层次和类型 为良好的需求管理建立坚实的方法论基础 为更有效的管理需求给出实践和建议
2
大纲
需求管理介绍 需求管理的重要概念 需求跟踪 深入管理需求 编写好的需求 需求变更管理
3
需求管理介绍
需求捕获 需求跟踪 深入管理需求 编写好的需求 需求Hale Waihona Puke Baidu更管理
34
捕获需求
我们必须知道哪些信息是从来的——需求的来源 我们必须知道哪些信息是我们需要的——需求的分类 我们必须善于发现需求——捕获需求的技巧
35
捕获需求
活动:
标识涉众 与涉众交流 收集需求 给需求的重要程度排序 选择需求 记录需求
12
电信业和银行业15个项目统计
Hofmann and Lehner 2001
最成功的项目在需求工程上投入了28%的资源： 需求获取，需求建模，需求确认和验证等 平均每个项目在需求活动上投入了15.7%的工作 量和占了 38.6%的时间
13
需求管理的作用 I —— 提高质量
关于质量，Crosby的定义很简单——与需求一致。
15
第一时间采取措施能降低成本和缩短时间
典型
缩短了 开发时间
工作量
较好
时间
16
需求管理的作用 III —— 支持项目进度的 管理
真实项目进度的反映
例如，多少需求已经被实现，它们的状态如何？ 又如哪些需求已经有对应的测试案例，哪些需求已经测试通过？
需求驱动开发
需求活动在项目正式立项之前就展开 需求分解后的功能点/模块成为项目管理中的需要实现的任务
飞机、汽车、火车、手机……
同义词
目标，规则，规约，约束，要求，特性，标准……
7
需求无处不在
需求
8
什么是“需求管理”？
进行需求管理的目的是在客户 和 ...项目 ...之间建立统一的 认识。 这种与客户一致的认 识是规划和管理 … 项目的基 础。”
卡内基梅隆大学软件工程学院 软件能力成熟度模型（CMM）。 www.sei.cmu.edu/cmm
43
影响系统功能的需求信息类型
业务目标 使用场景 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
44
非功能性需求的信息类型
“真实的现实系统中，在决定系统的成功或者失败的因素 中，满足非功能性需求往往比满足功能性需求更为重要。 ” 性能 软件质量属性
管理层的 支持
15%
14%
17%
5% 7%
用户积极 参与程度
23%的项目在完成 之前被取消
有经验的 项目经理 熟练的员工 敏捷的需求过程
源于: “Chaos Chronicles, III, 2003”. www.standishgroup.com
5
项目规模是关键
60 50 40 less than $750K $750K to $1.5M $1.5M to $3M $3M to $6M $6M to $10M Over $10M
非功能需求
必须被系统满足的潜在的条件. “约束补充了系统的质量但不会作为一个功能存在.” 对于系统而 言，约束不增加任何特殊的工作, 但它起到保证系统满足所需的功 能,保证系统更可靠,更易使用. “音乐点歌系统能够储存15,000,000个在线账号.” 非功能需求能够作为一个重要规则或条件组织和实现.
什么是需求？什么是需求管理？ 常见问题 需求管理的重要性和益处
4
项目成功因素
28%的项目按时并 在预算内完成 49%的项目超出原 先估算
时间平均延迟了 63% 成本超出了45%
可靠的 规范的 估算 方法 标准的 组织结构 最小化范围 清晰的商业目标
6%
5% 5%
12% 14%
不同的产品/系统，不同的公司，对自己的需求体系有自 己的定义
26
典型的需求层次
业务需求
定义一个机构达到的目标和目的。
用户需求(涉众需求)
说明用户需要系统提供什么能力帮助其完成任务。
系统需求
说明系统必需完成什么功能才能提供用户所需的。
27
业务需求
我们为什么要进行这个项目？ 组织的业务目标 提高公司的运营效率——内部信息管理信息系统 提高产品的市场竞争力——对商业软件 通常来自 投资方 管理层 市场部 产品部 常见文档记录方式 工作说明书 前景和范围文档 市场需求文档 项目计划书（可行性报告）
用户的目标，用户希望完成的任务 影响系统的需求信息类型：
业务目标 使用场景 外部约束
用户界面需求 接口需求 环境的约束
业务规则 数据定义
用户需求 - 涉众需求的通俗解释
30
系统需求
产品中实现的功能性需求
用户以此完成工作 进而满足业务需求
描述包含多组件的系统的顶级需求
31
如果世界就这么简单……
业务需求
用户需求
系统需求
32
项目中各种信息交织在一起
用户
市场 设计 系统需求 测试 实现 部署 维护 培训 支持
33
业务
客户
法律/ 规章
质量/ 标准
课程大纲
需求管理介绍 需求管理的重要概念
需求的“沙漏”——我们工作的全景视图 涉众的概念 需求的层次
25
需求文档的文档反映需求的演变层次
某个银行研发中心的需求演进的层次
业务规格说明书 －> 软件规格说明书 －> 概要设计－>详细设计
某个电信制造厂商的需求演进的层次
市场需求－> 产品包需求 －> 设计需求－>…
某个芯片提供商的需求演进的层次
市场需求－>产品需求－> 系统功能－>…
系统边界的确定 需求的筛选 需求的演化
问题陈述
正式的结构化的需求
需求管理
解决方案 设计
20
需求的 “沙漏”
许多相关人员.
人
定义问题.
一些的需求专家
问题陈述
定义解决方案 工程
工 程
21
需求的 “沙漏”
标识涉众 收集需求.
访谈，调查问卷 观测用户现有系统 改进建议，问题报告 ，创新研究
高度分散、凌乱的 非结构的信息
子目标 子目标 子目标 子目标
子目标
最终目标
子目标
子目标
子目标
实现最终目标 的步骤
子目标
子目标
序
操作顺
48
应用情况举例（一件行李）
交行李 乘客入座 称重
登机
受控 登记 贴标签
测量
装机 就绪 行李拥有人 在目的地 提行李
安全检查 运至登机口
装机
装入集装箱 装机
飞行
飞行 再次装机
卸机
装机
卸机
由飞机卸货
目标正确是第一位的——需求的正确捕获和表达 在项目后期才发现需求的缺陷，修复需要非常高的成 本 需求分析 分析得出带来最大价值的需求 同时得出所需的成本 我们的目标： 合理成本下的效益最佳 需求变化时如何控制成本 洞察变更影响 影响分析:迅速定位需要进行修改的模块
11
常见问题
1. 需求只存在组织中那些“专家”的脑子里，没有被记录 下来 2. 有时客户的需求会被忽略 3. 而有时候开发的功能却不被客户使用 4. 客户签字确认了需求却一直提出修改要求 5. 需求变更对项目影响很大，难以确定变更的影响范围和 成本 6. 市场部门、开发部门、测试部门跨部门的沟通存在问题 ，例如需求变化时不能迅速通知到测试部门去调整测试 计划和案例。 7. 需求规格说明书的要求都实现了，客户却不满意 8. 需求的研发状态，需求变更的状态难以掌握
详细描述涉众需求 研究揭示涉众需求的情形 按照每个目标或状态生成需求
改善与涉众的沟通
用涉众语言表达应用情况
确保需求的完整性
覆盖全部情况的多种应用
结构化编写需求文档
用主场景作为标题结构
导出验收测试
设计覆盖所有应用情况的测试
47
用户场景作为不同层次的目标
水平 2 水平 1
28
业务需求
若对项目预期的范围和目标有不同的理解，就无法对下列 获得一致意见
对哪些用户应该被访谈获取需求 哪些功能应该被纳入
现象
某些特性先被添加，又被删除，又被加入
分布式开发团队尤为重要 决策基础
目标版本 应用的广度和深度 需求变更
29
用户需求（涉众需求）
正确的需求：正确的功能的前提 一致性
与需求保持一致并不仅仅在项目的后期用测试来验证，更 强调的是在项目的每一个阶段都紧紧围绕需求这个主线来 开展工作。 需求跟踪正是保证需求演化的整个过程都是与需求保持一 致，以此保证项目和产品的最终质量
Phil Crosby
14
需求管理的作用 II —— 成本控制
成功率(%)
30 20 10
Project Size ($) $ 项目规模（ Standish Group, ‘99 (www.standishgroup.com) ）
6
0
什么是“需求”？
任何影响产品或系统设计制造方式的信息
功能 性能 安全性 可用性 ……
复杂的产品/项目有数以千计的需求
有哪些涉众角色？ 投资方（系统的投资方） 主管方（批准/管理系统的） 最终用户（用户/系统受益方） 操作方（操作/维护系统的） 监管方（认证系统的） 测试方（负责系统验收） 其它（受系统影响的）
38
概念：涉众角色
涉众角色举例 XXX 系统：
投资方 主管方 用户代表 最终用户 监管方 计划部 信息化部 市场部 营业员 审计部
41
客户不会给你一个清晰全面的需求列表
业务目标 使用场景 业务规则 功能性需求 质量属性 接口需求 约束 数据的要求 等等
42
需求分类
功能需求
系统必须实现的能力. 某些系统必须完成的工作. “系统能够为运输和装卸工作人员提供打印运输标记功能.” 能够作为一个逻辑时序组织和实现的功能是功能需求.