第一部分 引言

第1章 需求问题

1.1 目标

1.2 有关数据

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

1.3.1 需求错误的频率

1.3.2 需求错误的高昂代价

1.3.3 结论

第2章 需求管理简介

2.1 定义

2.1.1 什么是需求

2.1.2 什么是需求管理

2.2 需求管理技术的应用

2.2.1 软件应用程序的类型

2.2.2 系统应用程序

2.3 路线图

2.3.1 问题领域

2.3.2 风险承担人的需要

2.3.3 向解决方案领域前进

2.3.4 系统的特征

2.3.5 软件需求

2.3.6 用例介绍

2.4 小结

第3章 软件团队

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

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

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

3.1.3 软件团队的组织

3.2 个例研究

3.2.1 个例研究的背景

3.2.2 HOLIS 软件开发团队

3.3 小结

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

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

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

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

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

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

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

4.6 小结

4.7 展望

第5章 商业建模

5.1 商业建模的目的

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

5.2.1 选择正确的技术

5.2.2 统一建模语言 UML

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

5.3 从商业模型到系统模型

5.4 何时使用商业建模

5.5 小结

5.6 展望

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

6.1 什么是系统工程

6.1.1 系统工程的实用准则

6.1.2 复杂系统的组合和分解

6.2 系统工程中的需求分配

6.2.1 关于派生的需求

6.2.2 无声的演化

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

6.2.4 避免“烟囱”系统问题

6.2.5 当子系统是转包合同时

6.2.6 使系统正确实现

6.3 个例研究

6.3.1 基本用户需要

6.3.2 问题分析

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

6.3.4 HOLIS 系统工程

6.3.5 HOLIS 子系统

团队技能之一小结

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

第7章 需求启发的挑战

7.1 启发的障碍

7.1.1 “是的，但是”综合症

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

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

7.2 需求启发的技术

第8章 产品或系统的特征

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

8.2 特征

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

8.2.2 产品特征的属性

第9章 面谈

9.1 面谈的背景

9.2 增值背景

9.3 真实的时刻：面谈

9.4 编辑需要数据

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

9.4.2 个例研究

9.5 对问卷调查的注解

第10章 需求专题讨论会

10.1 加速决策过程

10.2 专题讨论会的准备

10.2.1 推销概念

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

10.2.3 后勤保障

10.2.4 “热身材料”

10.3 联络员的作用

10.4 安排日程

10.5 举行专题讨论会

10.5.1 折衷的问题与技巧

10.5.2 自由讨论和意见精简

10.5.3 成果和监督执行

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

11.1 现场自由讨论

11.2 意见精简

11.2.1 修剪

11.2.2 把意见归类

11.2.3 特征定义

11.2.4 确定优先次序

11.3 基于万维网的自由讨论

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

11.4.1 参加人员

11.4.2 专题讨论会

11.4.3 会议

11.5 结果分析

第12章 情节串联板制作

12.1 情节串联板的类型

12.2 情节串联板做什么

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

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

12.5 小结

第13章 应用用例

13.1 构建用例模型

13.2 应用用例启发需求

13.3 个例研究：HOLIS 的用例

13.4 小结

第14章 角色扮演

14.1 如何扮演角色

14.2 与角色扮演类似的技术

14.2.1 脚本预演

14.2.2 CRC 卡

14.3 小结

第15章 原型开发

15.1 原型的类型

15.2 需求原型

15.3 原型的对象

15.4 构建原型

15.5 评估结果

15.6 小结

团队技能之二小结

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

第16章 组织需求信息

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

16.2 组织产品系列的需求

16.3 关于“未来”需求

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

16.5 个例研究

16.6 小结

第17章 前景文档

17.1 前景文档的组件

17.2 “δ前景”文档

17.2.1 1.0版本的前景文档

17.2.2 2.0版本的前景文档

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

第18章 负责人

18.1 产品负责人的作用

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

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

团队技能之三小结

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

第19章 项目广度问题

19.1 项目广度的组件

19.2 难题

第20章 建立项目广度

20.1 需求基线

20.2 设定优先级

20.3 评估工作量

20.4 加入风险因素

20.5 缩小广度

20.6 个例研究

第21章 管理客户

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

21.2 交流结果

21.3 与客户协商

21.4 管理基线

21.4.1 正式变更

21.4.2 非正式变更

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

22.1 瀑布模型

22.2 螺旋模型

22.3 迭代方法

22.3.1 生命周期阶段

22.3.2 迭代

22.3.3 工作流程

22.4 做什么，做什么

团队技能之四小结

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

第23章 软件需求

23.1 软件需求的定义

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

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

23.3.1 排除项目信息

23.3.2 排除设计信息

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

23.5 需求的其他特性

23.5.1 功能性软件需求

23.5.2 非功能性软件需求

23.5.3 设计约束

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

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

23.7 展望

第24章 细化用例

24.1 要问的问题

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

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

24.1.3 冗余问题

24.2 细化用例的规格说明

24.2.1 用例是如何演变的

24.2.2 用例的广度

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

24.3.1 定义参与者

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

24.3.3 写一个简明的描述

24.3.4 定义事件流程

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

24.4 展望

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

25.1 现代 SRS 包

25.1.1 现代 SRS 包归谁所有

25.1.2 组织现代 SRS 包

25.2 为功能性需求建档

25.3 展望

第26章 歧义性和确切性

26.1 找到“最佳击球点”

26.2 玛丽有只小羊羔

26.3 消除歧义的技术

26.4 做什么

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

27.1 九个质量度量

27.1.1 正确的需求

27.1.2 无歧义的需求

27.1.3 需求集的完备性

27.1.4 需求集的一致性

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

27.1.6 可验证的需求

27.1.7 可修改的需求集

27.1.8 可跟踪的需求

27.1.9 可理解的需求

27.2 用例模型的质量度量

27.2.1 用例规格说明

27.2.2 用例的参与者

27.3 现代 SRS 包的质量度量

27.3.1 好的目录

27.3.2 好的索引

27.3.3 修正记录

27.3.4 词汇表

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

28.1 说明需求的技术性方法

28.1.1 伪代码

28.1.2 有限状态机

28.1.3 决策树和决策表

28.1.4 图形决策树

28.1.5 活动图

28.1.6 实体联系模型

28.1.7 面向对象建模

28.1.8 数据流图

28.2 规格说明的维护

28.3 个例研究

团队技能之五小结

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

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

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

29.1.1 软件验证的原则

29.1.2 验证的耗费

29.1.3 在所有层次上进行验证

29.1.4 验证的原因

29.2 证实开发结果是正确的

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

29.4 展望

第30章 从需求到实现

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

30.1.1 不相关问题

30.1.2 面向对象

30.1.3 把用例作为需求

30.1.4 管理过渡

30.1.5 软件系统建模

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

30.2 在设计模型中实现用例

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

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

30.3 从设计到实现

30.4 小结

30.5 展望

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

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

31.1.1 隐式跟踪与显式跟踪

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

31.2 使用跟踪工具

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

31.3.1 被忽略的验证关系

31.3.2 过度的验证关系

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

31.5 展望

第32章 确认系统

32.1 确认

32.1.1 验收测试

32.1.2 确认测试

32.1.3 确认跟踪

32.1.4 基于需求的测试

32.2 个例研究：测试用例

32.2.1 测试实例1描述

32.2.2 跟踪测试实例

32.3 测试离散需求

32.3.1 被忽略的确认关系

32.3.2 过度的确认关系

32.4 测试设计约束

32.5 展望

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

33.1 深度与覆盖

33.1.1 V&V 深度

33.1.2 V&V 覆盖

33.2 验证和确认什么

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

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

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

33.3 展望

第34章 管理变更

34.1 为什么需求会变更

34.2 外部因素

34.3 内部因素

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

34.5 管理变更的过程

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

34.5.2 第2步：确定需求的基线

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

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

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

34.6 需求配置管理

34.6.1 基于工具的变更管理

34.6.2 变更所影响的元素

34.6.3 变更记录的审计追踪

34.6.4 配置管理和变更管理

34.7 小结

团队技能之六小结

第八部分 开始

第35章 开始

35.1 致词

35.2 已经学到的主要内容

35.2.1 引言

35.2.2 团队技能之一：分析问题

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

35.2.4 团队技能之三：定义系统

35.2.5 团队技能之四：管理广度

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

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

35.3 需求管理的方案

35.3.1 简化的假设

35.3.2 方案

35.4 现在开始下一个版本

附录

附录 A HOLIS 制品

附录 B 前景文档模板

附录 C 现代 SRS 包模板

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

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

参考文献

索引