本书从实用的角度出发，通过全新的视角介绍了书写良好需求的格式和指导原则，以及分析需求问题的框架模型。本书讲述了问题域概念，列举了需求文档和规格说明书所包含的具体内容，重点引入了Michael Jackson的问题框架概念，通过非层次化的方法，举例演示了如何使用问题框架把巨大、复杂的问题分解成简单的问题。
　　本书内容丰富、编排合理，为程序员、测试人员、用户接口设计人员以及技术写作人员等提供了所需的全部信息。

无

本书介绍如何书写许多软件项目开发早期所需要的两种文档：需求文档，它描述软件所产生的期望效果；程序规格说明书或者接口设计，它描述产生这些效果的计算机的外部行为—输入/输出设备的行为。
　　同时，这些文档向编程人员提供必需的信息以创建程序，产生规格说明书中所描述的行为，并最终满足需求。这一信息也为测试人员设计测试计划提供了基线，为技术写作人员生成用户手册或在线帮助提供了操作规程和背景信息。

以下人员有必要书写这些文档：
　　* 系统分析员—客户和开发团队其他人员之间的联络员。在大型组织中，书写需求文档通常是系统分析员的职责。本书为系统分析员提供了许多写作技术，能使读者更加清楚和更加方便地使用他们的文档，并且相对于其他书籍，本书提供了软件的其他方面与需求之间更加清晰的界线。
　　* 用户接口设计人员—根据最终用户操作软件的想法，绘制屏幕和创作概念世界的人。对于用户接口设计人员，本书介绍了程序员、测试人员和技术写作人员根据用户接口设计完成他们工作所需的信息，以及如何简洁和清晰地表达它们。
　　* 程序员—特别是正在对开发过程进行规范化的小公司中的那些人。许多这样的公司没有系统分析员，并首次招募自己的程序员来书写需求文档。实际上，许多程序员已经做了大量的需求工程和接口设计，只不过没有这样称呼他们的工作。对于许多程序员来说，定义问题和挑选接口行为以解决问题是他们感兴趣的工作之一；许多人认为这些工作是编程的最本质的部分。本书以更加狭隘的概念来解读编程这个词，以便把精力集中在需求和接口设计上。
　　* 需要书写需求文档的项目经理。特别是在小公司中，人们以多种角色工作。项目经理经常与客户有更多的联系，因此，他就是书写需求文档最合理的选择。这将是特别令人头痛的任务，特别是第一次，即公司中没有人有书写需求的经验。本书提供了许多具体实例以及高层和详细指南去帮助新手从头开始。

　　第一部分，基本原理，提供了区分需求、接口设计和程序设计的现行原则。这些原则主要依赖于Michael Jackson划时代的工作，更多的是以理论的形式呈现在他的书中：Software Requirements & Specificatons：A Lexicon of Practice，Principles and Prejudices。
　　第1章和第2章涵盖了程序员如何真正书写程序以及如何裁剪需求以使其可用。第2章定义了软件问题的概念。第3章把软件问题同其解决方案的主要元素相关联，以奠定本书剩余章节的基础。
　　第4章到第6章介绍Jackson问题框架概念：把软件问题的基本元素转换为适合于详细文档化的形式、适合于用已知（或未知）技术创建解决方案的形式。第4章引入域、共享现象和需求等基本元素。第5章描述了软件问题的五种常见类型以及如何框定它们。第6章举例演示了如何使用问题框架把巨大、复杂的问题分解成简单的问题。不像大多数其他技术，该技术并不采用层次分解。相反，该技术更加灵活，允许一个子问题的元素和另外子问题的元素之间存在任何类型的重叠。

　　第二部分，内容，给出每种类型文档所包含内容的详细信息，以及如何简洁、清晰地描述这些内容的技巧。
　　第7章描述开发团队中每个人阅读需求和规格说明书的工作，以及他们所需要的信息。第8章是两份内容检查清单的集合，每类文档一份清单。清单列出灵活的指导原则，能帮助你发现可能忽略的必要信息，但清单不是强加于任何文档上的通用内容表。软件问题和它们的解决方案远不止如此简单。
　　第9章介绍如何文档化出现在大多数软件问题中的两种集合：类以及类间的关系。显示这两类集合的主要技术是标准的实体关系图或类图，并且补充了如何采用文本形式描述在图中略述的所有信息的指导原则。第9章也显示了如何描述软件所要回答的查询。
　　第10章是有关描述序列的技术，特别是事件序列。这包括需求文档中所需的事件本身的描述技术，以及程序规格说明书中所需的计算机和用户对这些事件响应的描述技术。
　　第11章解决如何描述因果关系和规则这个特别棘手的问题。因果关系可以存在于与软件交互的世界中，在需求文档中描述这些因果规则；或者它们是计算机行为所遵循的因果规则，在程序规格说明书中描述这些因果规则。第10章为读者提供了各种技术以便解决特定问题的特殊之处。
　　第12章介绍了大量与内容相关的其他主题，包括抽取、把面向对象设计强加到问题域描述的诱惑以及用例灾难。

　　第三部分，风格，关于如何选择合适的形式以展现相同的内容。大多数这些信息是良好技术写作的标准元素，尽管有关需求和规格说明书的标准元素侧重点不同。
　　第13章列举了大量的技术写作原理，举出了一些需求文档中的通病，并就如何纠正它们提出了建议。大多数这些错误产生于书写需求时呆板的概念或规程—强迫内容符合描述而不是形式服从内容。
　　第14章列举了文档组织技术：如何进行信息分组，如何选择展现这些信息的顺序。策略总是根据第二部分识别的内容来创建内容表，但不要从内容表开始，也不要在填写内容表时不考虑项目的特殊之处。
　　第15章是有关微小细节的指南：如何进行版面布局使之更具可读性，如何改写模糊语句，标题页面如何放置信息，如何表达定义等等。

　　第四部分，实例，包含真实项目中的两个示例文档。
　　第16章是位于美国科罗拉多州Boulder的Information + Graphics System公司在软件开发过程中，跟踪发现的bug的小软件的需求文档。
第17章是来自相同项目的用户接口设计文档的一组摘录。这些摘录包括很多示例信息，这些信息的简洁文档化非常需要技巧。
　　我特别感谢Michael Jackson在写作本书时给予我的耐心帮助。除了仔细地审阅手稿外，他还多次回答我漫无边际的、稍有些缺乏组织的有关需求和软件工程的问题，他的见识为我消除了迷惑。能向世界最著名的软件工程导师学习、请教是一种莫大的荣耀。
　　我非常感谢Ray Agostinelli、Paul Agostinelli、Heidi Anderson、Harold Cheney和Asim Jalis许多令人鼓舞的彻夜交谈—或者更恰当地说，容忍我激昂的发泄和大声地喧叫，甚至是在星期一晚上的足球之夜。由于Ray多次仔细审阅草稿，发现了细小的错误和许多不清楚的章节，所以手稿才得以特别的改进。
Sonia Kovitz，我的母亲，对于大多数困难章节，给了我一些最苛刻的批评。她经常发现逻辑主线丢失的确切位置，帮助我改进文本，她的作用不可估量。
　　还有很多人不辞劳苦地抽出时间去评审各种不同手稿，他们是：William Bail，Steve Colwell，Bruce Ediger，Anne Frank，Richard Gabriel，Earl Glynn，Lon Gowen，Haim Kilow，Peter Luise，Charlie Whiting。他们的领域经验远超过我本人，反馈过滤掉了书中的许多错误，并且给本书添加了大量有价值的内容。
　　同时也感谢给我有关软件问题域详细信息的人们，作为程序员、需求写作人员或用户，他们非常理解软件问题域，他们是：Michael Button，Joanne curme，Ben Eng，Lisa Higgins，Brent Jones，James Jones，Charles Libicki，Craig Lloyd，Scott Meyers，Scott Peter，Darrin Smith，Kim Swaney，Rachel Tillman，Gina Vick，Don Whiteside，Bob“Zimbob”Zimering。一些人允许我接连几个小时对他们的领域知识的细枝末节进行盘问。本书所使用的例子取自于非常广泛的软件应用范围。如果没有这些人的帮助，本书不可能包含这么大量的例子。James Jones几乎在电话中给我上了一堂债券扫盲课。Rachel Tillman也审阅了手稿，她的洞察力和丰富的经验反映在整本书中。
　　要特别感谢Information + Graphics System公司的Craig Bachmann和Steven Bruny，他们慷慨地允许我出版我在IGS时书写的一些需求文档。这在我们的软件业界是非常罕见的现象：由于真实项目的文档是有专利的，所以大多数有关需求的书籍仅包含假想项目的专门准备的案例。但是只有真实文档才具有真实项目的无规律性和不可预知的复杂性。人们需要了解在这些真实实例中其他人是如何同真实问题艰苦奋战的，书写需求的简单方案永远不能适应真实的问题。
　　同样感谢IGS中的Bug Log团队：Judy Bennett，Rae Bernhardson，Stacey Glazer，Jennifer Key，Bjorn Laukli，Randy Law，Tim Phillips，Ivan Storck。一组良好需求所体现的知识比系统分析员所赋予的更多。这些实例文档体现出他们的重要思想。
　　当然，这些帮助过我的人不是都赞同本书所陈述的每个思想。我已很努力地去排除错误思想和不确切的方法，但我不能获悉本书的所有缺陷。上面所列的许多人可能能指出很多。
　　最后，感谢Manning Publications的杰出员工。我不可能找到一个更加投入、更加专业、更加令人愉快的团队。我特别感谢Marjan Bace，他确切地知道什么时候让创造性过程自由进行，以及什么时候给创造性过程施加压力，如此巧妙但又严格地去满足最后期限，或者激进地花费几个月时间去修订章节组织。Marjan几乎无形的冷静，以很多微妙的方式改进了本书，并可能以我们无法了解的方式改进着本书。
　　读者可以免费访问私人因特网论坛，在那里你可以评论本书、询问技术问题，并可以从作者本人或其他读者那里获取帮助。该论坛的网址为：
http://www.manning.com/Kovitz
　　在那里你可以订阅论坛。该站点也提供如下信息：如何访问论坛，注册后可获取什么帮助，以及操作论坛的规则等。
　　我已努力完善和校正本书，然而错误和遗漏是在所难免的。如果你发现了本书中的错误或者遗漏，请告诉我。本书可能会有另外一个版本，如果那样，我希望尽可能地做出校正和完善。请通过作者在线论坛来指出它们。

（美）Benjamin L.Kovitz：暂无简介

胡辉良 张罡 等：暂无简介

有关如何书写软件需求和程序规格说明书（程序接口设计）的书籍通常是很呆板的、程序化的、枯燥无味的，而本书则立足于全新视角，从实际出发，从实用的角度出发，通过合理的组织和非教条化的方法来讲述需求，这使本书富有极强的可读性。
　　本书讲述了问题域概念，列举了需求文档和规格说明书所包含的具体内容，重点引入了Michael Jackson的问题框架概念，通过非层次化的方法，举例演示了如何使用问题框架把巨大、复杂的问题分解成简单的问题。本书内容丰富，编排合理，为程序员、测试人员、用户接口设计人员以及技术写作人员提供了所需的全部信息。
　　这本书确实是比较实用的软件需求类的书籍，提供了书写良好需求的格式和指导原则，并提供了分析需求问题的框架模型，读来颇有启发，对国人软件工程水平的提高有帮助，对我国软件产业中外包业务的拓展提供了思考的工具。
　　本书旁征博引，涉及的领域非常宽泛，包括：社会经济领域中公司债券的生命周期、美国公民申请税款返还以及美国联邦平衡预算；法律上不动产交易及法律、美国法律的案例引用规则；文学上《悲惨世界》的情节描写、《1984》的鸭叫来源；通信业中电话网络、美国电话线路；医药卫生领域中医药处方；技术领域中卫星勘察技术、复印机技术、条形码技术及其格式；印刷领域中大量英文文法和排版惯例；语言学领域中介词结尾的争论，等等。本书实例丰富，引用恰当，没有丝毫的堆砌感，极具吸引力。另外，在本书的最后两章，列举了作者在Information + Graphics System公司时书写的真实需求文档，这是极其罕见、难能可贵的。本书引领读者进入真实项目的无规律和不可预知的复杂性环境中，去了解其他软件人员如何同真实问题艰苦奋战，感触真实项目的困难之处。
　　总之，本书素材的选择、内容的安排、表达的准确、文字的流畅无不是上乘的。不管你是第一次书写需求的编程者或项目经理，还是有经验的系统分析员，本书都将帮助你熟练和有效地进行工作。
　　由于时间仓促，译者水平有限，难免存在错误或疏漏，希望读者批评、指正，也希望与同行一道共同学习、探讨。我们的电子邮箱为 requirements@126.com。

译　 者
2004年7月于上海

第一部分　 基 本 原 理
第1章　 问题解决 2
1.1　 功能分解的神话 3
1.1.1　 功能分解 4
1.1.2　 测试一下 4
1.2　 问题解决与设计模式 7
1.2.1　 工程是如何真正起作用的 8
1.2.2　 设计模式 9
1.3　 软件为什么困难 9
1.4　 模式合成与分解 12
第2章　 问题定义 16
2.1　 需求和设计模式 16
2.2　 软件问题 17
2.3　 需求工程 19
2.4　 已学课程 21
第3章　 两个世界和三种设计 23
3.1　 问题域 23
3.2　 需求 24
3.3　 接口设计 25
3.4　 验证接口和程序 27
3.5　 描述 28
3.6　 创建和验证 30
3.7　 软件需求不是什么 32
3.7.1　 不是自顶向下 32
3.7.2　 不是纲要 33
3.7.3　 不是“什么”和“如何” 35
3.8　 小结 35
第4章　 问题框定 37
4.1　 马的遍历 37
4.2　 域 38
4.3　 共享现象 40
4.4　 连接域 42
4.5　 实现域 43
4.6　 框架图 44
4.7　 从图到文档 47
4.8　 符号小结 47
第5章　 五个问题框架 49
5.1　 概要 49
5.2　 信息问题 51
5.2.1　 连接域 52
5.2.2　 静态和动态 52
5.2.3　 被动与主动 53
5.2.4　 解决信息问题 54
5.2.5　 检查清单 55
5.3　 控制问题 56
5.3.1　 连接域 57
5.3.2　 解决控制问题 58
5.3.3　 检查清单 58
5.4　 变换问题 59
5.4.1　 解决变换问题 60
5.4.2　 检查清单 60
5.5　 工件问题 60
5.5.1　 解决工件问题 61
5.5.2　 检查清单 61
5.6　 连接问题 62
5.6.1　 解决连接问题 64
5.6.2　 检查清单 66
第6章　 多框架问题 67
6.1　 组合问题框架 67
6.2　 库存控制系统 68
6.3　 统计包 70
6.4　 数字应答机 71
6.5　 编译器 72
6.6　 电子邮件 73
6.7　 卫星勘测 74
第二部分　 内　　　容
第7章　 软件开发 78
7.1　 认知劳动的分工 78
7.2　 分析 80
7.3　 用户接口设计 81
7.4　 编程 82
7.5　 测试 83
7.6　 用户文档 86
第8章　 两种文档 89
8.1　 需求文档的内容 90
8.2　 规格说明书的内容 96
第9章　 类和关系 98
9.1　 两种集合 98
9.2　 类 100
9.3　 所有可能的值 104
9.4　 不可能的取值 108
9.5　 关系 109
9.6　 基数 111
9.7　 把关系作为属性 114
9.7.1　 三元关系 116
9.7.2　 参考属性 117
9.8　 惟一性和功能性依赖 120
9.9　 查询 122
9.10　 命名类、属性和关系 124
第10章　 序列和事件 126
10.1　 结构 126
10.2　 事件 130
10.3　 事件响应 133
10.3.1　 每个事件 134
10.3.2　 响应硬件和软件事件 135
10.4　 更多的序列符号 136
10.4.1　 巴科斯范式 136
10.4.2　 句法图 137
10.4.3　 Warnier-Orr图 139
10.4.4　 流程图 140
10.4.5　 状态转换图 140
10.4.6　 特殊注释 141
第11章　 因果关系和控制 143
11.1　 状态转换 143
11.1.1　 命名状态和事件 148
11.1.2　 四种解释 149
11.2　 行为 151
11.3　 依赖关系 153
11.4　 流 160
11.5　 规则 162
11.5.1　 映射和完整性 163
11.5.2　 不连续性 165
11.5.3　 鸟瞰图视角 165
第12章　 专题 167
12.1　 抽取 167
12.2　 面向对象 168
12.2.1　 程序结构的两种类型 169
12.2.2　 错误所在 170
12.2.3　 设计模式的一个不同类型 172
12.3　 用例与特征交互 173
12.4　 评审 177
12.5　 需求行话 178
12.6　 捷径 180
12.7　 一些好书 181
第三部分　 风　　　格
第13章　 文档记录 184
13.1　 为什么书写文档 184
13.2　 基本原则 186
13.3　 扰乱视听的文本 191
13.3.1　 元文本 191
13.3.2　 通用性描述 192
13.3.3　 画蛇添足 193
13.3.4　 包含其他文档 193
13.4　 更常见的错误 195
13.4.1　 智力拼图 195
13.4.2　 手段与目标混淆 196
13.4.3　 吃力不讨好 196
13.4.4　 鸭叫需求 198
13.4.5　 创建不必要的术语 199
13.4.6　 需求与设计混淆 199
13.4.7　 预制的内容表 199
13.4.8　 术语不一致 200
13.4.9　 写给挑剔的读者 201
13.4.10　 责任转嫁给开发人员 202
13.5　 文档的低效使用 203
13.5.1　 为了文档而文档 203
13.5.2　 两手准备 203
13.5.3　 CYA文档 204
第14章　 文档组织 206
14.1　 内容第一 206
14.2　 分组 207
14.2.1　 一次说一件事 208
14.2.2　 七加或减二 209
14.3　 先后次序 211
14.4　 重点强调 212
第15章　 一些小细节 214
第四部分　 实　　　例
第16章　 Bug Log 需求 242
第17章　 Bug Log 用户接口 266
术语表 281
参考文献 287