软件需求管理：统一方法

第一部分   引      言
第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
第二部分   团队技能之一—分析问题
第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
第三部分   团队技能之二
—理解用户的需要
第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
第四部分   团队技能之三—定义系统
第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  “d前景”文档 107
17.2.1   1.0版本的前景文档 108
17.2.2   2.0版本的前景文档 108
17.3   遗留系统环境中的d前景文档 110
第18章   负责人 111
18.1   产品负责人的作用 111
18.2   软件产品环境中的产品负责人 112
18.3   IS/IT商店里的产品负责人 113
团队技能之三小结 114
第五部分   团队技能之四—管理广度
第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
第六部分   团队技能之五—细化系统定义
第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
第七部分   团队技能之六—构建正确系统
第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
第八部分   开      始
第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
附      录
附录A   HOLIS制品 248
附录B   前景文档模板 272
附录C   现代SRS包模板 279
附录D   SEI-CMM和ISO 9000
中的需求管理 285
附录E   Rational统一过程中的需求管理 290
参考文献 299
索引