本书还介绍了通过用例来采集用户需求，为实际的需求问题提供解决方案，从而产生满足用户要求的高质量的系统。本书作者极具实践经验，他们将自己的经历融入书中，从需求中遇到的问题谈起，阐述了使用用例的必要性，用例的基本知识，通过用例确定需求的三步法等内容，并对用例驱动的生命周期、跟踪等方面给出了有价值的建议。书中还包含大量的实例以供读者参考。本书主题鲜明，结构清晰，实用性强，适合软件需求工程师、设计人员、项目经理阅读，也适合作为相关专业的本科生、研究生的参考读物。
无
前言
本书第1版出版至今，已经过去了三年。三年前，用例还是一种“有趣的手段”，还没有被广泛采纳。在今天的软件开发市场中，用例已经成为采集需求的标准实践，甚至已经移植到其他应用中，包括业务过程和服务提供。但是在三年前，即使从最乐观的角度预计，也没有料到用例会如此流行。
当然在过去几年中，本书并不是惟一一本介绍用例的专著，不过它在一定程度上满足了软件行业人士了解这种新手段的要求。在这种软件技术发展趋势条件下，我们决定出版本书的第2版，把第1版出版以来我们得到的众多经验教训补充到本书中。我们根据开发多个用例驱动的项目的经验创建了本书第1版提出的方法，不过这种过程还很稚嫩。自从本书第1版出版以来，这种过程已经在很多其他项目中得到应用，我们也有机会把软件业务中很多好的想法融合到过程中，并对过程进行精心调整，使之成为更有效、更实用和更具扩展性的方法。我们还吸收了其他新兴领域的思想，包括“混沌机构”的思想（Dee Hock 2000；Margaret Wheatley 2001等）和Purdue大学Theodore Williams博士和Hong Li博士的“Purdue企业参考体系结构”的思想。这两项成果对我们将用例用于项目的方式和重新形成新版本中的许多新构想有着巨大影响。
首先最值得注意的是，第2版只有三个“F”迭代，即外观（facade）、填充（filled）和聚焦（focused）迭代。在应用到诸多项目后，最后一个“F”（结束，finished）迭代被证明是有问题的。首先，在迭代方法中，没有什么是能够真正结束的，事物永远都要进化。此外在一次迭代中，用例和用户界面设计总要交织在一起。我们把用户界面思想转移到外观迭代中，因为用户界面的进化应该与创建早期用例并行进行，而不是在其之后进行。
我们方法的另一个大的变化出现在管理这一章中。虽然和以前的内容并没有直接矛盾，但是第2版对迭代/渐进式用例驱动的项目管理的解释做了很大扩展。我们把它叫作整体迭代/渐进法，也就是HI/I（读作hi-eye）。我们相信生命周期的这个领域还有很多工作要做，因为多年以来沿用的瀑布式项目管理过程无法适应今天节奏更快、更加“混沌”的软件生命周期。我们在本书中给出管理一章只是为了抛砖引玉，非常希望其他作者能够扩展这些思想，并提出解决这个重大问题的新方法。此外，项目管理研究所（PMI）也提出了一些采用某些新的软件生命周期思想的方案。
我们了解到有很多读者认为本书第1版的附录既是书中的最好部分，也是最差部分。那是我们第一次尝试给出部分完整的用例例子，这也是理解创建用例的迭代本质的至关重要的一个步骤。但是，我们的表达不够清晰，因为我们通过四次迭代重复了该用例，有时用例有变化，有时没有变化，很难知道出现了什么变化以及什么时候出现的变化。这一次我们采用极为不同的方法。我们仍然要解释如何在软件需求采集中运用用例，但是所采用的方法不那么正式。在附录的各个部分中，我们选择不同风格的应用系统（大型业务应用系统、技术子系统、包评估等），并展示用例和其他制品不断演化的过程。我们希望这样做既能够保持第1版的优点，又能够反映出用例版本的演化。
我们发现，在很多的项目中，用例层次结构的思想除了引起混乱之外，没有起到任何作用。首先创建“高层”用例，然后创建“细节”用例，这种方法会损害需求获取过程。层次结构越高、越复杂（有的书建议采用4层或更多层次的结构），距离最初的业务需求就会越远。即使我们的初始过程只有两层结构（系统背景环境级用例和下层用例构成），但是当团队想要增加层次时仍然会遇到麻烦，并会引起混乱。类似地，对用例关联使用<<包含>>（include）和<<扩展>>（extend）构造型，也会产生不必要的层次问题，因此除了非常特殊的情况，一般不使用构造型。为解决这个问题，我们在大家都很熟悉的工具和过滤器包中补充了一种新的工具，即“层次结构杀手”。希望你在每次精简层次结构时都能够得到乐趣。
用例在很多方面都与其他类型的需求获取手段不同，其中一个方面就是可跟踪性方面的不同。用例对业务需求有很强的可跟踪性，对软件开发制品也有很强的可跟踪性，可以跟踪UML分析和设计制品，跟踪测试、编写文档记录、培训、安全，甚至跟踪体系结构的各个部分。我们决定专门设立一章来介绍用例的可跟踪性现象，以说明如何确保团队“做正确的事”。
最后，为了反映需求获取工具的最新动态，我们列出在本书出版时可以得到的工具，并提出一些充分利用这些工具的建议。由于这些工具的更新速度很快（但我们写书的速度很慢），因此我们只列出主要的工具。
我们希望读者能够喜欢本书的第2版。我们很高兴能够与Pearson Education公司再次合作，出版本书的更新版本。如果你有什么看法、经验和建议，请随时与我们联系。我们的电子邮件地址列在本书最后一章的末尾。
第1版前言
可能与大多数书一样，写作本书的初衷来自抱怨。因为我们觉得没有一本好的著作专门讨论用于需求采集的用例。很多人都赞同用例是解决需求问题的完美工具，但是却没有人把详细过程写下来，帮助大家理解如何使用用例。
需求采集已经成为我们所参与的所有项目中的重要问题。需求的模糊特性常常使大多数软件分析人员感到困惑并且无从下手。用例是我们看到的用于解决通常与需求采集相关的规格说明和沟通问题的第一种工具。
虽然用例本身相当直观，但是围绕用例制定的过程却常常不能很好地实施。人们的问题是：我要进行多少次迭代？用例的粒度应该有多细？大多数著作都没有回答甚至没有涉及这些问题。这可能是因为这些问题很难回答，因为在不同情况下答案会有很大不同。但是这些都是很重要的问题，所以我们决定把自己的想法写出来，目的是抛砖引玉，希望能够得到同行关于如何产生能够描述用户需要的需求这一问题的看法。
本书是技术工作者的一本实践参考。与信息技术业的咨询公司一样，我们也把使用用例描述业务系统作为自己日常工作的一部分。我们认为自己理解人们在使用像统一建模语言和用例这样的工具设计软件时所面临的问题。我们的主要目的不是描述用例符号，尽管我们确实也要讨论这个问题。我们的主要目的是，说明以一种可以产生高质量结果的方式采集需求的需求过程。
在编写本书时，我们研究了引起需求采集问题的因素，提出了一种交付面向需求的可交付产品集合的用例方法。这种方法论将产生需求的活动分解为一系列步骤，它可以解决人们在使用用例时通常会遇到的问题。本书与交付规格说明、管理团队工作和激励下属等实际工作相关。
我们希望读者能够喜欢本书。本书对于我们而言是爱的付出。本书所述的过程是很适合我们的，如果这个过程也适合你，那再好不过了。如果不适合，那么读者可以根据自己的实际情况，对本书提供的工具、思想或建议进行修改以解决自己的需求问题。
(美)Daryl Kulak,Eamonn Guiney：暂无简介
韩柯 杨柳青等：暂无简介
与软件危机一起诞生的软件工程方法和建模理论已经发展了几十年。但现实的情况是，软件项目存在的问题仍然很严重，我们经常会看到有头无尾的工程，用户不满意的工程，难以投入实际使用的工程，或者严重超支和拖延进度的工程。而这种现象往往是需求问题造成的。虽然人们提出了解决需求获取问题的很多方法和技术，但是仍然难以从根本上解决需求问题。
UML作为一种建模语言标准已经得到广泛应用，市场上有许多介绍这一主题的书籍。本书的特点是，专门论述通过基于用例的过程采集和定义软件需求，为系统分析人员和设计人员展示怎样运用用例为最具挑战性的需求问题提供解决方案，产生满足用户需要的高质量的有效系统。此外，作者还提出了需求获取的三步法，即一种渐进地产生细化需求的三轮迭代过程。书中给出大量详细的例子，有助于读者根据自己的具体情况，运用用例获取和描述需求。本书适合各类软件需求工程师、开发人员、测试工程师和软件项目经理阅读，对于大专院校计算机应用和系统工程专业的研究生和高年级学生，也是不错的补充材料。
在翻译过程中，除了对原文个别明显文字错误进行了相应更正外，我们力求忠实原文。但由于译者的知识水平和实际工作经验有限，不当之处在所难免，恳请读者批评指正。
译 者
译者序
前言
第1版前言
第1章 需求中的问题 1
1.1 首要问题与至少要解决的问题 1
1.2 需求是什么 5
1.2.1 功能需求 8
1.2.2 非功能需求 9
1.3 需求获取、定义与规格说明 9
1.4 需求获取的挑战 11
1.4.1 找出用户需要什么 11
1.4.2 建立用户需要文档 12
1.4.3 避免过早提出设计假设 13
1.4.4 消解矛盾的需求 13
1.4.5 消除冗余需求 13
1.4.6 压缩篇幅 13
1.4.7 确保需求的可跟踪性 14
1.5 标准方法问题 14
1.5.1 与用户面谈 14
1.5.2 联合需求策划会议 15
1.5.3 合同风格的需求清单 16
1.5.4 原型 17
1.6 麻烦的需求 18
第2章 用例 19
2.1 重要的是交互 23
2.2 统一建模语言 25
2.2.1 九种图 27
2.2.2 通过构造型方法扩展UML 32
2.3 引入用例、用例图和场景 33
2.3.1 用例的目标 34
2.3.2 用例图怎样表示关系 36
2.3.3 用例模板 40
2.3.4 路径与场景 45
2.4 用例在需求获取中的使用 48
2.4.1 用于只查系统的用例 48
2.4.2 用于招标书的用例 48
2.4.3 用于软件包评估的用例 48
2.4.4 用于非面向对象系统的用例 49
2.5 使用用例解决需求获取问题 49
第3章 需求获取的用例驱动方法 51
3.1 需求规格说明工具 51
3.2 成功获取需求的原则 51
3.3 需求获取的三个步骤 52
3.4 使命、远景、价值的作用 53
3.5 工作陈述的作用 54
3.6 风险分析的作用 54
3.7 原型的作用 55
3.8 用例的作用 55
3.8.1 用例是有效的沟通工具 55
3.8.2 用例可以用来描述功能和非功能需求 56
3.8.3 用例有助于确保需求的可跟踪性 56
3.8.4 用例可以抑制过早的设计 56
3.9 业务规则分类的作用 57
3.10 成功地管理 58
第4章 外观迭代 59
4.1 目标 59
4.1.1 用户 60
4.1.2 项目团队 60
4.1.3 行业专家 61
4.1.4 信息技术管理小组 61
4.1.5 用户管理人员 62
4.1.6 数据拥有者 63
4.2 外观迭代的步骤 63
4.2.1 确定使命、远景与价值 63
4.2.2 标识并评审现有文档和智力资源 64
4.2.3 确定执行发起人的独特观点 65
4.2.4 评审业务过程定义 68
4.2.5 标识用户、客户和有关小组 68
4.2.6 与项目相关人员面谈 69
4.2.7 编制项目相关人员清单 69
4.2.8 确定参与者 70
4.2.9 进行用例调查 70
4.2.10 收集非功能需求并形成文档 72
4.2.11 开始编写业务规则分类 76
4.2.12 编写风险分析 76
4.2.13 编写工作陈述 76
4.2.14 开始试验用户界面比喻 77
4.2.15 开始确定用户界面情景板 78
4.2.16 得到执行发起人的非正式批准 78
4.3 工具 78
4.3.1 用例图 78
4.3.2 层次结构杀手 79
4.3.3 用例名称过滤器 81
4.3.4 参与者过滤器 81
4.3.5 动词过滤器 81
4.3.6 名词过滤器 82
4.3.7 存储扩展功能的包 83
4.3.8 外观过滤器 83
4.3.9 同行评审 84
4.3.10 用户评审 84
4.4 可交付产品 84
4.5 角色 85
4.6 背景环境 85
4.7 小结 85
第5章 填充迭代 87
5.1 目标 87
5.2 步骤 87
5.2.1 分解细化用例 88
5.2.2 创建填充用例 90
5.2.3 补充业务规则 95
5.2.4 测试填充用例 95
5.2.5 推迟一部分工作 97
5.3 工具 98
5.3.1 项目相关人员的面谈 98
5.3.2 IPA过滤器 98
5.3.3 空白分析过滤器 98
5.3.4 抽象过滤器 99
5.3.5 通过场景测试用例 99
5.3.6 评审 99
5.3.7 补充用例 99
5.4 可交付产品 100
5.5 角色 100
5.6 背景环境 100
5.7 小结 101
第6章 聚焦迭代 103
6.1 目标 103
6.2 什么是聚焦用例 104
6.3 步骤 104
6.3.1 合并重复的过程 104
6.3.2 将关注点集中到每个用例上 105
6.3.3 管理本轮迭代期间的范围变更 106
6.3.4 管理风险与假设 107
6.3.5 评审 107
6.4 工具 109
6.4.1 多余功能过滤器 109
6.4.2 集中系统的焦点 109
6.4.3 找出用例内部的多余功能 110
6.4.4 词汇过滤器 110
6.5 可交付产品 110
6.6 角色 111
6.7 背景环境 111
6.8 小结 111
第7章 管理需求与人员 113
7.1 概述 113
7.2 瀑布生命周期管理 114
7.2.1 Nell与咖啡店 115
7.2.2 瀑布模型的缺点 117
7.3 瀑布模型以外的其他模型 119
7.3.1 快速应用系统开发 119
7.3.2 螺旋 120
7.3.3 分阶段交付 120
7.3.4 整体迭代/渐进 121
7.4 引入整体迭代/渐进用例驱动的项目生命周期 121
7.4.1 迭代的含义 122
7.4.2 渐进的含义 123
7.4.3 整体的含义 124
7.4.4 自适应的含义 125
7.4.5 复杂自适应系统 126
7.5 过程 128
7.6 整体迭代/渐进软件生命周期的原则 130
7.6.1 管理需求，而不是管理任务 131
7.6.2 重要目标是业务目标—日期和预算 132
7.6.3 像业务人员那样思考—你们最近为我做什么了 133
7.6.4 分而治之 134
7.6.5 把工作分解为程序和项目 137
7.6.6 把一切都与业务联系起来 140
7.6.7 创建可演示的可交付产品 141
7.6.8 学会“足够好”质量艺术 141
7.6.9 分块要比想象的更小 142
7.6.10 预期会出现谈判，而不是规格说明 142
7.6.11 忘记基线和退出条件 143
7.6.12 通过实践进行估计 143
7.6.13 使用组合以新的方式计算投资回报率 144
第8章 需求可跟踪性 147
8.1 跟踪用例 150
8.1.1 分析模型可跟踪性 151
8.1.2 设计模型可跟踪性 152
8.1.3 类-责任-协作卡会议可跟踪性 152
8.1.4 测试模型可跟踪性 152
8.1.5 用户界面设计可跟踪性 153
8.1.6 应用系统体系结构可跟踪性 153
8.1.7 项目管理可跟踪性 153
8.1.8 文档记录与培训可跟踪性 153
8.1.9 产品市场开发可跟踪性 154
8.1.10 安全可跟踪性 154
8.1.11 发布策划 154
8.2 跟踪非功能需求 154
8.3 跟踪业务规则 156
8.3.1 结构事实 156
8.3.2 行动约束与行动触发规则 156
8.3.3 计算与引用 156
第9章 经典错误 157
9.1 错误、缺陷与教训 157
9.2 经典错误：有错就改 158
第10章 用例的应用 165
10.1 为什么用例能够成功 166
10.1.1 用例对于业务人员是切合实际的 166
10.1.2 用例是可跟踪的 166
10.1.3 用例是很好的范围确定工具 167
10.1.4 用例不使用特殊语言 167
10.1.5 用例使人们可以描述情节 167
10.1.6 其他方法很糟糕 168
10.2 软件之外的用例 168
10.2.1 服务用例 169
10.2.2 业务用例 170
10.3 小结 172
附录A 房地产管理系统 175
附录B 集成系统 199
附录C 即刻消息系统加密 203
附录D 通过产品目录订购产品 207
参考文献 213
