第一部分 背景 1
第1章 导论 3
1.1 业界的当前状况 3
1.2 有效需求实践的必要性 5
1.3 需求过程 5
1.3.1 什么是过程 5
1.3.2 什么是需求过程 7
1.4 过程方法的优点 8
1.5 过程方法的缺点 9
1.6.2 关键术语 10
1.6 关于本书 10
1.6.1 角色 10
1.6.3 需求分类 11
1.6.4 系统与软件工程师 12
1.6.5 读者对象 12
1.6.6 对本书读者的建议 12
1.6.7 脚注 13
1.6.8 主要参考文献与推荐读物 13
1.7 本书其他内容 13
1.8 小结 13
1.9 主要参考文献与推荐读物 14
第二部分 推荐的需求实践 17
第2章 对方法的承诺 19
2.1 承诺的含义 19
2.2 如何获得并维护承诺 20
2.3 有关合作方式的建议 24
2.3.1 请具有权威性的管理人员参加合作工作会议 24
2.3.2 开发需求计划 25
2.3.3 使用一组机制、方法、手段和工具 26
2.4 小结 27
2.3.4 向质量文化方向发展 27
2.5 主要参考文献与推荐读物 28
第3章 建立并利用负责需求的联合团队 31
3.1 什么是“联合团队” 31
3.2 联合团队的职责 32
3.3 如何建立联合团队 32
3.4 联合团队的成员 33
3.5 联合团队多长时间聚会一次 33
3.6 需要创建并跟踪什么指标 33
3.7 计算使用有效需求实践的投资回报(ROI) 33
3.8 客户与提供商的作用 34
3.10 主要参考文献与推荐读物 35
3.9 小结 35
第4章 定义真实的客户需要 39
4.1 有助于获取真实需求的建议 40
4.1.1 在需求过程方面增加投入 40
4.1.2 培训项目管理人员更多地关心需求过程 42
4.1.3 找到项目倡导者 43
4.1.4 项目前景和范围的定义 43
4.1.5 找到一位需求工程师，并且利用领域专家完成需求工程任务 47
4.1.6 培养开发人员不要作出需求决定，不要自行发挥 48
4.1.7 使用不同手段启发客户，获取用户需求和期望 48
4.1.8.1 需求错误的影响 52
4.1.8 培训需求工程师编写好的需求 52
4.1.8.2 需求对于程序费用的重要性 53
4.1.8.3 什么是好的需求 54
4.1.9 记录每条需求的基本原理 55
4.1.10 使用方法和自动化工具分析和跟踪需求，并为需求划分优先级 55
4.1.11 收集来自多种观点的需求 58
4.1.12 尽量考虑使用适当的形式化方法 59
4.2 缺陷 59
4.3 小结 60
4.4 主要参考文献与推荐读物 60
5.1 什么是过程 63
第5章 使用并不断改进需求过程 63
5.2 如何设计过程 64
5.3 为什么需要需求过程 66
5.4 需求工程师的目标 68
5.5 一个样本需求过程 70
5.6 机构怎样创建和剪裁需求过程 78
5.7 过程剪裁 79
5.8 Web支持：一种机构过程资产库 80
5.9 小结 80
5.10 主要参考文献与推荐读物 80
6.1 系统工程过程 83
第6章 迭代使用系统需求和体系结构过程 83
6.2 建议 84
6.2.1 在确定需求时考虑系统的“可设计性” 84
6.2.2 为功能划分、对象、人员或支持要素分配需求，以支持解决方案的综合 85
6.2.3 使用系统体系结构过程 86
6.2.4 考虑开放系统标准 95
6.3 “体系结构设计”方针 98
6.4 另一种观点 99
6.5 小结 100
6.6 主要参考文献与推荐读物 100
7.2 人的自然倾向 105
7.1 设置阶段 105
第7章 运用机制维护项目组之间的沟通 105
7.3 实现有效沟通的积极方法 106
7.4 有效沟通机制的一个例子 106
7.5 如何对待消极态度 108
7.6 另一种很有价值的机制——自备食品聚餐 109
7.7 举行有效会议的建议 109
7.8 关于有效电子邮件沟通的建议 110
7.9 共同词汇的价值 113
7.10 纵向专家的使用 113
7.13 小结 114
7.11 避免多地点开发 114
7.12 最后的建议 114
7.14 主要参考文献与推荐读物 115
第8章 选择熟悉的方法并维护一组工作产品 119
8.1 系统开发基础 119
8.2 什么是可选的方法和手段 119
8.3 哪些方法和手段是最佳的 121
8.4 软件评估功能点的使用 126
8.5 质量功能部署 126
8.7 对需求划分优先级的基本理由 128
8.6 需求规范的内容包括什么 128
8.8 小结 130
8.9 主要参考文献与推荐读物 131
第9章 执行需求检验与确认 135
9.1 检验与确认术语 135
9.2 检验与确认的重要性 136
9.3 检验与确认的规划 136
9.4 检验方法 138
9.5 检验与确认技术 138
9.6 使用可追踪性支持检验 138
9.7 测试的一种结构化方法 139
9.8 建议 140
9.9 问题 140
9.10 小结 141
9.11 主要参考文献与推荐读物 141
第10章 提供适应需求变更的有效机制 143
10.1 为什么这样强调 143
10.2 为需求变更进行规划 144
10.3 推荐机制 145
10.4 需求泄漏 145
10.5 将注意力集中在价值高的地方 147
10.7 以协议方式处理需求变更 148
10.6 需求能够变更多少 148
10.8 其他建议 149
10.9 小结 150
10.10 主要参考文献与推荐读物 150
第11章 使用经过业界、机构和项目组证明的、已知的、熟悉的最佳实践，推动开发工作 153
11.1 为什么会出现混乱情况 154
11.2 我们能做什么 154
11.3 建议 155
11.3.1 让开发团队了解业务要使用的策略、过程和程序 155
11.3.2 使用实用、有效的项目管理方法 156
11.3.4 使用已知(经过培训)、经过证实的过程、机制、方法、手段和工具执行开发工作 160
11.3.3 保证经过挑选的开发团队成员具有领域知识 160
11.3.5 提供并运用机制促进整个开发团队的有效沟通 161
11.3.6 运用同行评审和审查，从过程和工作产品中清除缺陷 162
11.3.7 确保配置管理是有效的 163
11.3.8 培养积极地辅助并支持开发团队且为项目增值的独立的QA角色 164
11.3.9 确保子承包商处于管理之下，保证子承包商的工作是有效的 165
11.3.10 使用适当、有用的指标管理项目 166
11.3.11 使用系统化的方法，确保使客户参与整个项目开发工作 169
11.3.12 定量管理项目。此外，使用缺陷预防(DP)过程、技术变更管理(TCM)过程和过程变更管理(PCM)过程。在整个机构中大量引用和复用资源 169
11.4 有关项目管理的思考 170
11.6 主要参考文献与推荐读物 172
11.5 小结 172
第三部分 下一步做什么 175
第12章 如何发展 177
12.1 常见问题 177
12.2 解决这些问题的关键因素 178
12.2.1 客户 178
12.2.2 需求是所有系统或软件工作的关键的牵引器 178
12.2.3 为需求过程的改进投入资金 178
12.2.5 指标 179
12.2.7 开发团队 179
12.2.5 管理层的意识与期望 179
12.2.4 适者生存 179
12.3 从哪儿开始 180
12.4 如何对所需完成的工作划分优先级 182
12.5 所推荐的有效需求实践与CMM之间的关系 185
12.6 但是有那么多的事要做 186
12.7 如果项目“继续推进”会出现什么情况 186
12.8 小结 187
12.9 主要参考文献与推荐读物 187
结束语 191
缩写词汇表 193
名词解释 203