当前位置:首页 > 工业技术
软件需求管理  统一方法
软件需求管理  统一方法

软件需求管理 统一方法PDF电子书下载

工业技术

  • 电子书积分:12 积分如何计算积分?
  • 作 者:(美)Dean Leffingwell,(美)Don Widrig著;蒋慧,林东译
  • 出 版 社:北京:机械工业出版社
  • 出版年份:2002
  • ISBN:7111096932
  • 页数:315 页
图书介绍:
《软件需求管理 统一方法》目录

第一部分 引言 3

第1章 需求问题 3

1.1 目标 3

1.2 有关数据 3

1.3 项目成功和失败的根本原因 4

1.3.1 需求错误的频率 5

1.3.2 需求错误的高昂代价 6

1.3.3 结论 7

第2章 需求管理简介 9

2.1 定义 9

2.1.1 什么是需求 9

2.1.2 什么是需求管理 9

2.2 需求管理技术的应用 10

2.2.1 软件应用程序的类型 10

2.2.2 系统应用程序 10

2.3 路线图 11

2.3.1 问题领域 11

2.3.2 风险承担人的需要 11

2.3.3 向解决方案领域前进 12

2.3.4 系统的特征 12

2.3.5 软件需求 12

2.3.6 用例介绍 12

2.4 小结 13

第3章 软件团队 14

3.1 把软件开发作为一种团队活动 14

3.1.1 有效需求管理所需要的团队技能 15

3.1.2 团队成员具有不同的技能 15

3.1.3 软件团队的组织 16

3.2 个例研究 16

3.2.1 个例研究的背景 16

3.2.2 HOLIS 软件开发团队 17

3.3 小结 17

第二部分 团队技能之一——分析问题 21

第4章 问题分析的五个步骤 21

4.1 第一步:在问题定义上达成共识 22

4.2 第二步:理解根本理由——问题背后的问题 23

4.3 第三步:确定风险承担人和用户 25

4.4 第四步:定义解决方案系统的界限 26

4.5 第五步:确定加在解决方案上的约束 27

4.6 小结 29

4.7 展望 29

第5章 商业建模 31

5.1 商业建模的目的 31

5.2 利用软件工程技术进行商业建模 32

5.2.1 选择正确的技术 32

5.2.2 统一建模语言 UML 32

5.2.3 利用 UML 的概念进行商业建模 33

5.3 从商业模型到系统模型 34

5.4 何时使用商业建模 35

5.5 小结 35

5.6 展望 35

第6章 软件密集型系统的系统工程 36

6.1 什么是系统工程 36

6.1.1 系统工程的实用准则 37

6.1.2 复杂系统的组合和分解 37

6.2 系统工程中的需求分配 38

6.2.1 关于派生的需求 39

6.2.2 无声的演化 39

6.2.3 冲突何时产生:资深系统工程师碰上年轻程序员 40

6.2.4 避免“烟囱”系统问题 41

6.2.5 当子系统是转包合同时 41

6.2.6 使系统正确实现 41

6.3 个例研究 42

6.3.1 基本用户需要 42

6.3.2 问题分析 43

6.3.3 HOLIS:系统、参与者和风险承担人 44

6.3.4 HOLIS 系统工程 45

6.3.5 HOLIS 子系统 46

团队技能之一小结 47

第三部分 团队技能之二——理解用户的需要 51

第7章 需求启发的挑战 51

7.1 启发的障碍 51

7.1.1 “是的,但是”综合症 51

7.1.2 “尚未发现的遗址”综合症 52

7.1.3 “用户和开发人员”综合症 52

7.2 需求启发的技术 53

第8章 产品或系统的特征 54

8.1 风险承担人和用户的需要 54

8.2 特征 54

8.2.1 通过对抽象级别的选择来管理复杂度 56

8.2.2 产品特征的属性 56

第9章 面谈 58

9.1 面谈的背景 58

9.2 增值背景 59

9.3 真实的时刻:面谈 61

9.4 编辑需要数据 62

9.4.1 分析人员的总结:10+10+10≠30 62

9.4.2 个例研究 62

9.5 对问卷调查的注解 63

第10章 需求专题讨论会 65

10.1 加速决策过程 65

10.2 专题讨论会的准备 65

10.2.1 推销概念 66

10.2.2 确保真正的风险承担人的参与 66

10.2.3 后勤保障 66

10.2.4 “热身材料” 66

10.3 联络员的作用 68

10.4 安排日程 68

10.5 举行专题讨论会 69

10.5.1 折衷的问题与技巧 69

10.5.2 自由讨论和意见精简 70

10.5.3 成果和监督执行 71

第11章 自由讨论和意见精简 72

11.1 现场自由讨论 72

11.2 意见精简 74

11.2.1 修剪 74

11.2.2 把意见归类 74

11.2.3 特征定义 75

11.2.4 确定优先次序 75

11.3 基于万维网的自由讨论 76

11.4 个例研究:HOLIS 2000需求专题讨论会 77

11.4.1 参加人员 77

11.4.2 专题讨论会 77

11.4.3 会议 77

11.5 结果分析 79

第12章 情节串联板制作 80

12.1 情节串联板的类型 80

12.2 情节串联板做什么 81

12.3 情节串联板制作的工具和技术 82

12.4 情节串联板制作的几点提示 82

12.5 小结 83

第13章 应用用例 86

13.1 构建用例模型 86

13.2 应用用例启发需求 87

13.3 个例研究:HOLIS 的用例 88

13.4 小结 89

第14章 角色扮演 90

14.1 如何扮演角色 90

14.2 与角色扮演类似的技术 91

14.2.1 脚本预演 91

14.2.2 CRC 卡 91

14.3 小结 92

第15章 原型开发 93

15.1 原型的类型 93

15.2 需求原型 93

15.3 原型的对象 95

15.4 构建原型 95

15.5 评估结果 95

15.6 小结 96

团队技能之二小结 96

第四部分 团队技能之三——定义系统 99

第16章 组织需求信息 99

16.1 组织复杂硬件系统和软件系统的需求 100

16.2 组织产品系列的需求 102

16.3 关于“未来”需求 102

16.4 商业和市场需求与产品需求的比较 103

16.5 个例研究 103

16.6 小结 104

第17章 前景文档 105

17.1 前景文档的组件 105

17.2 “δ前景”文档 107

17.2.1 1.0版本的前景文档 108

17.2.2 2.0版本的前景文档 108

17.3 遗留系统环境中的δ前景文档 110

第18章 负责人 111

18.1 产品负责人的作用 111

18.2 软件产品环境中的产品负责人 112

18.3 IS/IT 商店里的产品负责人 113

团队技能之三小结 114

第五部分 团队技能之四——管理广度 117

第19章 项目广度问题 117

19.1 项目广度的组件 117

19.2 难题 119

第20章 建立项目广度 120

20.1 需求基线 120

20.2 设定优先级 121

20.3 评估工作量 121

20.4 加入风险因素 122

20.5 缩小广度 123

20.6 个例研究 125

第21章 管理客户 128

21.1 促使客户管理他们的项目广度 128

21.2 交流结果 128

21.3 与客户协商 128

21.4 管理基线 129

21.4.1 正式变更 130

21.4.2 非正式变更 130

第22章 广度管理和软件开发过程模型 131

22.1 瀑布模型 131

22.2 螺旋模型 133

22.3 迭代方法 134

22.3.1 生命周期阶段 135

22.3.2 迭代 135

22.3.3 工作流程 136

22.4 做什么,做什么 137

团队技能之四小结 137

第六部分 团队技能之五——细化系统定义 141

第23章 软件需求 141

23.1 软件需求的定义 142

23.2 特征和软件需求之间的关系 143

23.3 需求的两难问题:做什么与如何做 143

23.3.1 排除项目信息 144

23.3.2 排除设计信息 144

23.4 更多有关需求与设计的讨论 145

23.5 需求的其他特性 146

23.5.1 功能性软件需求 147

23.5.2 非功能性软件需求 147

23.5.3 设计约束 150

23.5.4 设计约束是真正的需求吗 151

23.6 采用父-子需求提高确切性 152

23.7 展望 153

第24章 细化用例 154

24.1 要问的问题 154

24.1.1 什么时候应该采用用例方法 154

24.1.2 什么时候用例不是最佳选择 154

24.1.3 冗余问题 155

24.2 细化用例的规格说明 155

24.2.1 用例是如何演变的 156

24.2.2 用例的广度 157

24.3 个例研究:一个简单用例的解剖 157

24.3.1 定义参与者 157

24.3.2 通过命名用例来定义用例 157

24.3.3 写一个简明的描述 158

24.3.4 定义事件流程 158

24.3.5 确定前置条件和后置条件 159

24.4 展望 160

第25章 现代软件需求规格说明 161

25.1 现代 SRS 包 161

25.1.1 现代 SRS 包归谁所有 163

25.1.2 组织现代 SRS 包 163

25.2 为功能性需求建档 165

25.3 展望 166

第26章 歧义性和确切性 167

26.1 找到“最佳击球点” 167

26.2 玛丽有只小羊羔 169

26.3 消除歧义的技术 170

26.4 做什么 171

第27章 软件需求的质量度量 172

27.1 九个质量度量 172

27.1.1 正确的需求 172

27.1.2 无歧义的需求 173

27.1.3 需求集的完备性 173

27.1.4 需求集的一致性 175

27.1.5 根据重要性和稳定性给需求分级 175

27.1.6 可验证的需求 176

27.1.7 可修改的需求集 177

27.1.8 可跟踪的需求 177

27.1.9 可理解的需求 178

27.2 用例模型的质量度量 178

27.2.1 用例规格说明 178

27.2.2 用例的参与者 179

27.3 现代 SRS 包的质量度量 180

27.3.1 好的目录 180

27.3.2 好的索引 180

27.3.3 修正记录 181

27.3.4 词汇表 181

第28章 说明需求的技术性方法 182

28.1 说明需求的技术性方法 182

28.1.1 伪代码 182

28.1.2 有限状态机 183

28.1.3 决策树和决策表 184

28.1.4 图形决策树 185

28.1.5 活动图 185

28.1.6 实体联系模型 186

28.1.7 面向对象建模 187

28.1.8 数据流图 188

28.2 规格说明的维护 189

28.3 个例研究 189

团队技能之五小结 189

第七部分 团队技能之六——构建正确系统 193

第29章 正确地构建正确系统:概述 193

29.1 不断证实开发沿着正确的方向 193

29.1.1 软件验证的原则 193

29.1.2 验证的耗费 194

29.1.3 在所有层次上进行验证 194

29.1.4 验证的原因 195

29.2 证实开发结果是正确的 195

29.3 学习处理开发过程中出现的变更 196

29.4 展望 196

第30章 从需求到实现 197

30.1 把需求映射到设计和代码 197

30.1.1 不相关问题 197

30.1.2 面向对象 198

30.1.3 把用例作为需求 199

30.1.4 管理过渡 199

30.1.5 软件系统建模 199

30.1.6 用例模型在体系结构中的作用 201

30.2 在设计模型中实现用例 201

30.2.1 协作的结构方面和行为方面 202

30.2.2 利用协作实现个体需求集 203

30.3 从设计到实现 203

30.4 小结 204

30.5 展望 204

第31章 利用可跟踪性支持验证 205

31.1 需求验证中可跟踪性的作用 205

31.1.1 隐式跟踪与显式跟踪 206

31.1.2 其他要考虑的可跟踪选项 207

31.2 使用跟踪工具 207

31.3 在没有跟踪工具条件下进行 210

31.3.1 被忽略的验证关系 211

31.3.2 过度的验证关系 211

31.4 有关验证和可跟踪性的思考 213

31.5 展望 213

第32章 确认系统 214

32.1 确认 214

32.1.1 验收测试 214

32.1.2 确认测试 215

32.1.3 确认跟踪 215

32.1.4 基于需求的测试 216

32.2 个例研究:测试用例 216

32.2.1 测试实例1描述 216

32.2.2 跟踪测试实例 217

32.3 测试离散需求 217

32.3.1 被忽略的确认关系 218

32.3.2 过度的确认关系 219

32.4 测试设计约束 220

32.5 展望 220

第33章 利用投资收益决定 V&V 工作量 221

33.1 深度与覆盖 221

33.1.1 V&V 深度 221

33.1.2 V&V 覆盖 222

33.2 验证和确认什么 222

33.2.1 第1种选择:验证和确认一切 222

33.2.2 第2种选择:利用冒险分析来决定 V&V 的必要性 223

33.2.3 把冒险分析作为投资收益 224

33.3 展望 224

第34章 管理变更 225

34.1 为什么需求会变更 225

34.2 外部因素 225

34.3 内部因素 226

34.4 “我们已经遇到了敌人,而且敌人就是我们自己” 226

34.5 管理变更的过程 227

34.5.1 第1步:认识到变更是不可避免的并为变更制定计划 227

34.5.2 第2步:确定需求的基线 228

34.5.3 第3步:建立控制变更的惟一渠道 228

34.5.4 第4步:使用变更控制系统来捕获变更 229

34.5.5 第5步:分层次地管理变更 231

34.6 需求配置管理 231

34.6.1 基于工具的变更管理 233

34.6.2 变更所影响的元素 234

34.6.3 变更记录的审计追踪 235

34.6.4 配置管理和变更管理 235

34.7 小结 235

团队技能之六小结 236

第八部分 开始 240

第35章 开始 240

35.1 致词 240

35.2 已经学到的主要内容 240

35.2.1 引言 240

35.2.2 团队技能之一:分析问题 241

35.2.3 团队技能之二:理解用户的需要 241

35.2.4 团队技能之三:定义系统 242

35.2.5 团队技能之四:管理广度 242

35.2.6 团队技能之五:细化系统定义 243

35.2.7 团队技能之六:构建正确系统 243

35.3 需求管理的方案 244

35.3.1 简化的假设 244

35.3.2 方案 244

35.4 现在开始下一个版本 246

附录 248

附录 A HOLIS 制品 248

附录 B 前景文档模板 272

附录 C 现代 SRS 包模板 279

附录 D SEI-CMM 和 ISO 9000中的需求管理 285

附录 E Rational 统一过程中的需求管理 290

参考文献 299

索引 303

相关图书
作者其它书籍
返回顶部