第1部分 原理、模型与误区
第1章 需求实践现状分析 2
在信息化高速发展的今天，构建与时俱进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题的根源。
1.1 软件项目失败的根源 2
1.1.1 CHAOS Report 1994 2
1.1.2 CHAOS Report后续版本 3
1.1.3 需求相关败因简要分析 4
1.1.4 一幅漫画带来的思考 8
1.2 透过表象，分析本质 13
1.2.1 需求变更频繁 13
1.2.2 上线阻力大 14
1.2.3 运行效果差 15
1.2.4 完全崩溃 16
1.3 方法论与需求工作 17
1.3.1 计算模式 17
1.3.2 软件工程方法论 18
1.3.3 开发思想 19
1.4 小结 20
第2章 不同软件项目的需求视图 21
随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中所担负的角色也越来越多，应用层面也在逐渐地深入，同时也意味着不同的软件项目具有不同的特点，这也就对需求工作产生了诸多影响。 在本章中，我们就将针对信息系统、嵌入式系统、软件产品等不同角度来说明如何进行相应的需求工作，为需求分析师提供一个切实有效的视图。
2.1 信息系统的需求视图 21
2.1.1 信息系统的本质与分类 21
2.1.2 联机事务处理系统——流程电子化 23
2.1.3 管理信息系统——数据信息化 26
2.1.4 其他信息系统 30
2.1.5 信息系统的多维视图 32
2.2 嵌入式系统的需求视图 34
2.2.1 面向直接用户的嵌入式系统 35
2.2.2 面向特定设备的嵌入式系统 36
2.3 软件产品的需求视图 37
2.4 小结 41
第3章 软件需求与需求工程 42
笔者在做需求分析师的培训时，经常会问学员这样的一个问题：什么是软件需求？这个看似简单的问题却并不好回答，也许很多人会简单地认为软件需求就是用户需要实现的功能加上一些非功能方面的要求。但这样的理解却并不完整，如果对用户所处的业务场景没有建立正确认识，经常会给工作带来麻烦。因此本章将对一些与需求、需求工程相关的关键概念进行阐释。
3.1 什么是软件需求 42
3.1.1 需求的三个层次 42
3.1.2 需求的三种类型 44
3.1.3 优秀需求的标准 47
3.2 需求工程解析 51
3.2.1 需求工程的范畴 52
3.2.2 需求开发工作要点 52
3.2.3 需求管理工作要点 57
3.2.4 需求分析人员的技能组成 60
3.2.5 SERU模型概述 61
3.3 小结 62
第2部分 需求开发
第4章 需求定义最佳实践 64
需求定义活动准确来说是不属于需求工程范畴的，它实际上是立项管理需要做的工作。但需求定义阶段的产物对于需求捕获、分析与建模活动都有着直接的影响，如果这个阶段的工作做得不理想，就会出现“上梁不正下梁歪”的结果。因此本书还是将这个活动纳入进来，并将给大家提供一个能够与后续活动结合紧密的方法。
4.1 需求定义任务概述 64
4.1.1 需求定义的时机 64
4.1.2 需求定义的理念与策略 65
4.2 问题分析的五步法 67
4.2.1 在问题定义上达成共识 67
4.2.2 分析问题背后的问题 73
4.2.3 确定相关人员和用户 77
4.2.4 定义解决方案的界限 78
4.2.5 确定加在解决方案上的约束 81
4.2.6 小结 81
4.3 需求定义的产物与要素 82
4.3.1 需求定义的产物 82
4.3.2 需求定义的要素 83
4.4 定义需求范围 88
4.4.1 案例说明 88
4.4.2 划分主题域 89
4.4.3 确定主题域范围 98
4.4.4 标识业务事件与报表 102
4.4.5 生成需求大纲 105
4.5 小结 108
第5章 需求捕获最佳实践 109
需求捕获是需求开发中的第一个活动，可以说任何一个需求团队对它都不陌生，但如何提高需求捕获的有效性却一直以来是困扰大家的问题。需求捕获的要点在于计划性和科学性，计划性体现在对捕获对象、问题、时间的计划，科学性则表现在如何有效地选择合适的捕获方法。本章的目的就在于帮助大家更好地达到这两个目标，从而提高需求捕获活动的质量。
5.1 需求捕获的策略 109
5.1.1 需求捕获应该是主动的 109
5.1.2 需求捕获应该是聚焦的 110
5.1.3 破解需求的冰山模型 111
5.1.4 破解阻碍需求捕获的心理现象 113
5.1.5 不要忽视对变更可能的捕获 117
5.1.6 需求协商 118
5.2 需求捕获的主要方法 126
5.2.1 用户访谈 126
5.2.2 用户调查 138
5.2.3 文档考古 143
5.2.4 情节串联板 145
5.2.5 现场观摩 147
5.2.6 联合开发 149
5.3 需求捕获的记录工具 152
5.3.1 工具的选择与定义 152
5.3.2 任务卡片 152
5.3.3 场景说明 154
5.3.4 其他工具 155
5.4 小结 156
第6章 需求分析与建模最佳实践 157
需求分析是需求工程中最为核心的工作，而需求建模则是需求分析的主要手段。但由于分析这个词比较抽象，很多时候让人感到无从入手，甚至导致被轻易地滑过了，直接将需求捕获的结果整理到软件需求规格说明书中。而需求建模也有很多工具，到底怎么有效地应用到需求分析过程中也是令人感到难以掌握的东西。因此本章的目标就是为读者勾勒出需求分析的阶段与任务，指出如何选择适合的建模工具，以及在什么时机、如何应用这些建模工具。
6.1 需求分析与建模的要点与误区分析 157
6.1.1 需求分析到底做什么 157
6.1.2 建模的目标与要点 160
6.1.3 选择建模工具的要点 162
6.2 周期一：理清框架与脉络 165
6.2.1 业务流程分析 166
6.2.2 业务实体分析 192
6.2.3 角色与使用场景分析 218
6.2.4 周期一的产物 236
6.3 周期二：确定需求细节 252
6.3.1 确定行为需求的细节 253
6.3.2 确定结构需求的细节 274
6.3.3 周期二的产物 283
6.4 其他需求分析 296
6.4.1 接口需求 296
6.4.2 非功能需求的追踪 299
6.4.3 设计约束 302
6.5 小结 306
第7章 需求描述最佳实践 307
需求描述就是将需求捕获、分析的结果进行文档化的过程。在软件开发时，将分析的结果文档化是不可或缺的任务，也称为编写规约活动；而在某个项目中，可能还会由用户代表或需求捕获人员对捕获的内容进行整理，形成用户需求说明书。具体要干什么，想必大家并不陌生，而且在前一章中也看到了一些实例的片段。因此本章将重点从需求描述的风格与格式、写作策略与技巧两个方面做些强调和补充。
7.1 需求描述的风格与格式 307
7.1.1 常见的描述风格与选用标准 307
7.1.2 典型软件需求规格说明书模板解析 308
7.1.3 定义模板的技巧 323
7.1.4 用户需求说明与软件需求规格说明 331
7.2 写作策略与技巧 333
7.2.1 文字表达的先天不足 333
7.2.2 需求描述的两大原则 335
7.2.3 不要忽视陈述需求理由的重要性 338
7.2.4 注意措辞 339
7.3 小结 340
第8章 需求验证最佳实践 342
需求验证是需求开发的最后一个环节，它是一个质量关。也就是说，其目标是发现尽可能多的错误，减少因为需求的错误而带来的工作量浪费。而需求验证的主要手段就是Review（复查，也常译为评审）。但是许多需求团队都觉得需求验证比较容易变得“务虚”，收效很少，本章的目标就是帮助大家缓解这个问题。
8.1 需求验证的主要手段 342
8.1.1 不同正式化程度的评审 342
8.1.2 审查过程概述 344
8.2 需求验证的主要误区与解决方案 346
8.2.1 需求验证的5大要点 347
8.2.2 需求验证常见的5大问题 350
8.3 小结 353
第3部分 需求管理
第9章 需求基线操作实务 356
需求基线是需求管理活动中最为基础的一个，通常也是在项目中首先应该引入的管理活动。但许多相关书籍中对需求基线的介绍相对比较理论化，很少给出具体的操作方法，往往使得许多软件开发团队无从入手。为了帮助大家更好地引入需求基线，本章的重点将是结合具体的实例来说明需求基线的划分方法。
9.1 需求基线的理念与策略 356
9.1.1 基线思想的起源 356
9.1.2 基线的策略 358
9.2 基线划定的基础：优先级评价 359
9.2.1 组织需求项 359
9.2.2 业务优先级评价 360
9.2.3 根据技术依赖性和项目风险调整优先级 364
9.3 基线划定的要素：工作量估算 364
9.3.1 估算的意义与要点 364
9.3.2 定义阶段的估算示例 366
9.3.3 分析一阶段的估算示例 369
9.4 基线划定与管理 370
9.4.1 划定基线 370
9.4.2 管理基线 371
9.5 小结 372
第10章 变更管理操作实务 373
需求变更频繁恐怕是困扰无数软件开发团队的恶魔之首，而且在美国权威的第三方机构Standish Group的CHAOS报告中，也将其列为困扰软件开发团队、导致项目失败的5大原因之一，其中原因实际上也充分暴露了整个产业的不成熟。需求变更在CHAOS报告中是排名第四的问题，而在中国软件开发团队中却是排名第一的问题，这里面就意味着存在距离，本章的目的就是希望帮助大家找到其中的差距。
10.1 变更管理的理念 373
10.2 变更管理要点一：统一渠道 374
10.2.1 CCB背后的道理 374
10.2.2 变更处理过程 377
10.3 变更管理要点二：统一平台 381
10.3.1 变更管理平台的选择 381
10.3.2 变更管理平台的应用要点 382
10.4 小结 383
第11章 需求跟踪操作实务 384
需求跟踪是一个高阶的管理活动，它的目标是为了更好地管理需求的状态、更好地分析需求变更产生的影响。虽然执行需求跟踪会带来不错的效益，但其所需付出的工作量也是巨大的。本章我们就对跟踪的一些要点做一简要的说明。
11.1 需求跟踪的基本概念 384
11.1.1 用户需求到软件需求的跟踪 385
11.1.2 软件需求到软件需求的跟踪 385
11.1.3 软件需求到下游工作产品的跟踪 385
11.2 需求跟踪的操作方法 386
11.2.1 表格法 386
11.2.2 链表法 387
11.3 小结 389
第4部分 总结
第12章 SERU过程框架总结 392
经常说一个观点：“我们并不缺乏软件工程、需求工程的理论、技术，缺乏的是将这些理论与技术有效地应用到实践中去的具体方法”。而贯穿全书的SERU过程框架（也称为SERU模型）正是笔者基于多年不同领域、不同规模的软件项目实践的基础上，通过对许多重型方法的剪裁而得到的一个清晰、实用的软件需求过程框架。
12.1 SERU过程框架要点概述 392
12.1.1 SERU过程框架的理论基础 392
12.1.2 SERU过程框架全景图 393
12.1.3 SERU过程框架导入建议 396
12.2 需求实作要点概述 397
12.3 结语 399
参考文献 400
SERU诫语 第1章 需求实践现状分析 2
SERU诫语1-1：需求规格说明书应该采用业务导向的树型层次结构来组织。 6
SERU诫语1-2：对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通。 6
SERU诫语1-3：缓解沟通失真最有效的方法是及时复述。 10
SERU诫语1-4：需求分析的本质在于业务分析，而非技术分析。 12
SERU诫语1-5：业务场景是需求之魂。 12
SERU诫语1-6：需求分析人员对于技术方法论的评价重在适用性。 17
SERU诫语1-7：对预设计的需求是评判敏捷方法论是否适用的关键。 18
第2章 不同软件项目的需求视图 21
SERU诫语2-1：流程分析（业务事件）是OLTP系统的关键线索和主要视图。 24
SERU诫语2-2：报表分析是MIS系统的关键线索和主要视图。 27
SERU诫语2-3：决策场景是DSS系统的关键线索和主要视图。 31
SERU诫语2-4：工作场景是专家系统的关键线索和主要视图。 31
SERU诫语2-5：并行工作流是OA系统的关键线索和主要视图。 32
SERU诫语2-6：高层管理人员的关注点往往在问题和机会。 34
SERU诫语2-7：对于面向用户的嵌入式系统，行为分析是要点。 36
SERU诫语2-8：面向特定设备的嵌入式系统，外部接口和事件分析是要点。 37
SERU诫语2-9：信息系统类软件产品的需求重点在于针对不同目标客户群体的不同商业模式分离变化点；经常需要减出通用性，再通过插接解决扩展性。 40
SERU诫语2-10：基于使用场景的困难点分析是工具软件的需求要点。 41
第3章 软件需求与需求工程 42
SERU诫语3-1：业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。 44
SERU诫语3-2：功能需求的要点在于如何组织。 45
SERU诫语3-3：非功能需求的要点在于保证信息的有效传递和注意其局部性。 45
SERU诫语3-4：设计约束包括非技术因素的技术选型、预期的软硬件环境和预期的使用环境三大类型。 47
SERU诫语3-5：业务导向的层次结构是保障完整性的关键。 47
SERU诫语3-6：需求有时会戴上“高优先级”的面具，实际上就是担心你不去实现它。49
SERU诫语3-7：满意/不满意度模型是需求必要性评价的有效手段。 50
SERU诫语3-8：在需求捕获活动中，化被动为主动是关键。 53
SERU诫语3-9：需求分析就是向下分解+向上提炼，外加一些规格化。 54
SERU诫语3-10：需求分析是目标，需求建模是手段。 55
SERU诫语3-11：在编写需求规格说明书时，应确保一类信息只在一处描述。 57
SERU诫语3-12：划分出大小合适、粒度均匀的需求项是需求管理的前提。 58
SERU诫语3-13：需求优先级与工作量估算是基线管理的关键。 59
SERU诫语3-14：SERU模型是需求分析的工作指南。 61
第4章 需求定义最佳实践 64
SERU诫语4-1：清晰的项目目标和范围定义，能够引导需求工作顺利进行。 65
SERU诫语4-2：对混沌不清的目标，可以通过内部寻根或外部溯源来破解。 65
SERU诫语4-3：对问题进行了正确的定义，意味着成功解决了一半。而在问题定义时应该善于使用转换和本源两个技巧。 68
SERU诫语4-4：需求定义阶段要善于将未知解问题转换成已知解问题。 69
SERU诫语4-5：在确定某问题的解决方案时，一定要思考是否会引发新问题。 70
SERU诫语4-6：直接修改错误，不要用其他方案来弥补错误。 71
SERU诫语4-7：鱼骨图为解决问题找到了靶子，帕累托图则标上了环数。 77
SERU诫语4-8：范围是涉及的事、物，边界是人与系统的职责边界。 80
SERU诫语4-9：用户永远会希望花同样的钱，获得尽可能多的功能。 80
SERU诫语4-10：需求阶段描述的是用户的能力特点，旨在提高可用性。 86
SERU诫语4-11：你可以不做一件事，但一定不能不知道为什么需要做这件事。 86
SERU诫语4-12：在分解系统时，应该按业务的脉络来划分成不同的主题域。 90
SERU诫语4-13：各个主题域之间的服务接口是需求变更的防火墙。 91
SERU诫语4-14：确保能做的事和知道的事相匹配是职责驱动设计的要点。 94
SERU诫语4-15：目标决定范围。 97
SERU诫语4-16：绘制上下文关系图，先考虑Customer再考虑Worker是要点。 99
SERU诫语4-17：业务事件应该是主动触发的，并且将会产生一系列后续行为。 103
SERU诫语4-18：业务事件是直接作用于系统的，也就是将触发系统行为。 104
第5章 需求捕获最佳实践 109
SERU诫语5-1：需求捕获是撒网打鱼，不是休闲钓鱼。 109
SERU诫语5-2：善于聚焦访谈话题是需求捕获人员成功的关键。 111
SERU诫语5-3：尝试理解业务场景是合格需求分析人员的良好习惯。 112
SERU诫语5-4：善于利用技术为用户创造全新体验是优秀需求人员的特质。 113
SERU诫语5-5：通过比较用户代表的表述来识别言过其实，利用差异展现、瓶颈分析法来缓解影响。 114
SERU诫语5-6：针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。 114
SERU诫语5-7：离开办公室、对访谈进行计划是避免非正事现象的主要手段。 116
SERU诫语5-8：化敌为友是缓解抗拒心态的主要方向。 116
SERU诫语5-9：倾听对方的抱怨是化敌为友的有效手段之一。 116
SERU诫语5-10：突破推卸责任心理的简单手段是让被访谈者介绍工作场景。 117
SERU诫语5-11：需求捕获时不要忽视对变更可能的了解。 118
SERU诫语5-12：在需求捕获时要善于使用“？”之箭，找到真正的需求。 121
SERU诫语5-13：“拨开立场，寻找利益诉求”是需求协商的要点。 123
SERU诫语5-14：不要孤立地看待需求项，应该将所有需求视为一个整体。 123
SERU诫语5-15：“环境”将改变结果，切换不同的视角会得到不同的认识。 125
SERU诫语5-16：善于打比方是提高跨专业沟通效果的好方法。 126
SERU诫语5-17：占用时间长和信息的片面性是用户访谈的两大敌人。 127
SERU诫语5-18：访谈的线索是因“人”（用户类型）而异的。 127
SERU诫语5-19：尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。 129
SERU诫语5-20：在需求捕获时别忘了“一图抵千言”这句经典提示。 133
SERU诫语5-21：用户访谈是一个有计划的、科学的过程。 136
SERU诫语5-22：用户调查能够有效克服用户访谈中存在的片面性。 138
SERU诫语5-23：在需求捕获过程中，先访谈再调查是更合理的方式。 138
SERU诫语5-24：大样本用户、跨地域用户的存在就是使用用户调查的时机。 139
SERU诫语5-25：分析文档资料时应该思考新流程对其的影响。 144
SERU诫语5-26：收集文档时，应该尽可能让用户提供带有真实数据的样本。 145
SERU诫语5-27：需求捕获人员要善于根据流程分析的结果主动收集相关文档。 145
SERU诫语5-28：情节串联板是消除用户盲区的有效技术。 146
SERU诫语5-29：情节串联板应该以业务场景作为展示的主线索。 147
SERU诫语5-30：交互才是情节串联板的本质，不要只关注于界面的静态效果。 147
SERU诫语5-31：现场观摩技术是消除开发团队认识盲区的有效手段。 147
SERU诫语5-32：现场观摩技术能够使开发团队实现对业务场景“感同身受”。 147
SERU诫语5-33：联合开发是突破双方需求盲区的有效手段。 149
SERU诫语5-34：出现“上面开大会，下面开小会”现象，一半责任在组织者。 150
SERU诫语5-35：沟通决定内容，内容决定格式。 152
第6章 需求分析与建模最佳实践 157
SERU诫语6-1：需求分析就是先分解，再提炼，在这个过程中消除矛盾。 157
SERU诫语6-2：需求建模的过程远比建模的结果更重要。 160
SERU诫语6-3：模型是用来沟通的，因此仅当需要时才构建它。 161
SERU诫语6-4：建模的要点是根据要完成的任务选择合适的建模工具。 162
SERU诫语6-5：UML本身不是方法论。 164
SERU诫语6-6：业务流程是对信息系统进行“庖丁解牛”的核心线索。 166
SERU诫语6-7：流程有组织级、部门级、岗位级三个层次，其中部门级是需求分析的主线索，岗位级是需求细节填充时的工作内容，组织级是对部门级流程的抽象概括。 171
SERU诫语6-8：应该根据项目的特点和团队的技能情况选择合适的模型。 173
SERU诫语6-9：模型最有效的方式是在交流中演化出来的。 177
SERU诫语6-10：流程图绘制完成之后，花些时间进行瓶颈和利益分析会有意想不到的收获。 186
SERU诫语6-11：在需求建模时，应该大胆地用中文命名类和类的属性。 195
SERU诫语6-12：需求阶段的类建模应该尽可能保持简单，引入过多的辅助建模元素反而会降低图的可读性。 200
SERU诫语6-13：领域模型是自底向上合并出来的。 206
SERU诫语6-14：领域模型的要点是拒绝实现、保持简单、忠于问题域。 209
SERU诫语6-15：领域建模时应遵循“拒绝实现细节、大类不分拆、子类不合并、同类不抽象”的原则。 209
SERU诫语6-16：团队的分工不明确往往是导致视图交叠的原因，了解不同视图的关注点，是理解不同模型的关键。 216
SERU诫语6-17：仅在需求规格中出现用例图并不意味着应用了用例技术。 219
SERU诫语6-18：千万不要为了使用扩展、包含关系而使用它们。扩展用例建模的通常是优先级较低的扩展事件流，包含关系建模的通常是多个用例所包含的公共子事件流。225
SERU诫语6-19：在访谈现场，就流程图讨论出用例图是高效的建模方法。 230
SERU诫语6-20：如果说用例有粒度，那么它取决于业务流程和任务分工。 233
SERU诫语6-21：系统动作（诸如新增、删除之类）和业务名词在用例名称中相遇时，就是一个十分危险的信号。 234
SERU诫语6-22：对不影响泳道间协作的判断、活动均属于细节信息。 237
SERU诫语6-23：对于报表而言，并不一定非得按用例模板来组织需求描述。 241
SERU诫语6-24：诸如Rose之类的建模工具，对模型抽象的支撑是最重要的。 252
SERU诫语6-25：前、后置条件出现的频度并不高，不要画蛇添足。 257
SERU诫语6-26：避免在用例事件流描述中出现实现细节、分支结构、循环结构；特别是不应该出现多路分支结构，如果出现要反思用例抽象是否正确。 265
SERU诫语6-27：界面原型部分是约束、是建议，目的是支持有效的UI设计。 269
SERU诫语6-28：建议使用不同的字体风格约定，以表达出数据的结构特点。 280
SERU诫语6-29：历史记录的标准也是数据需求的一部分。 280
SERU诫语6-30：哪里有分解，哪里就有接口。 297
第7章 需求描述最佳实践 307
SERU诫语7-1：需求规格的格式取决于开发团队的特点及所选的开发方法论。 329
SERU诫语7-2：用户需求说明书是为生成软件需求规格说明书服务的。 333
SERU诫语7-3：文字的歧义可能与其长度成正比。 335
SERU诫语7-4：要使需求描述更加清晰，就应该转用“结构化文本”式描述。 338
SERU诫语7-5：在你被逼在需求描述中增加How的信息之前，先确认自己已经尝试过为需求添加了Why。 339
SERU诫语7-6：对于非功能需求而言，应该抛弃定性，改用场景化描述；并通过选取指标、积累经验值的方法过渡到定量描述。 340
第8章 需求验证最佳实践 342
SERU诫语8-1：需求验证的目标是尽可能暴露问题，而不是证明无错。 347
SERU诫语8-2：在企业中推行即时评审、同级桌查等正式化程度不高的评审手段，是创建企业评审文化的有效手段。 348
SERU诫语8-3：在评审会中，不要用“评价者”的口气谈论你的观点。 349
SERU诫语8-4：参加需求评审的人不是越多越好，一定要保证同级、适合。 349
SERU诫语8-5：评审时要确保评审内容、缺陷检查表的规模适合，内容应该按每小时30～40页的速度来准备，缺陷检查表尽量在9条之内。 350
第9章 需求基线操作实务 356
SERU诫语9-1：优先级是相对的，要在同一级中进行比较。 363
SERU诫语9-2：评价具体功能点的优先级时，应将其放到业务场景甚至是业务流程环境中考虑。 364
SERU诫语9-3：软件估算是随着工作任务的细化不断提高精确度的。 365
SERU诫语9-4：不同阶段进行软件估算时，应该采用不同的计数单元。 365
SERU诫语9-5：悲观估计、乐观估计应和“风险”理由对应起来。 370
第10章 变更管理操作实务 373
SERU诫语10-1：需求变更管理的目标是控制变更，而非避免变更。 373
SERU诫语10-2：控制变更的目标是减少变更对开发工作的影响。 373
SERU诫语10-3：需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于“尽可能以弹性的设计来减少变更的影响”。 374
SERU诫语10-4：建立统一的渠道让客户意识到变更的成本，减少“来路不正”的变更，记录“变更的工作”。 374
SERU诫语10-5：CCB的核心人员只有两个，分别代表用户团队和开发团队，其他组成人员都是协作者和决策者。 375
SERU诫语10-6：基于业务驱动的需求项（树型）列表，是对变更进行业务影响分析的有效方法。 380
SERU诫语10-7：对变更进行分类、再分类，是管理变更的重中之重。 383
第11章 需求跟踪操作实务 384
SERU诫语11-1：需求跟踪是高阶管理活动，所需的工作量很大，特别是软件需求到设计元素的跟踪，因此一定要考虑投入与产出是否成正比。 385