本书描述了37个真实的、可重用的模式，为编写软件需求提供了特定情形下的框架。每种模式详细描述需要包括哪些信息，提醒常见的缺陷，以及建议需要考虑的额外需求。无论使用传统的分析方法还是敏捷方法，都可以学习如何使用需求模式，从而为成功的软件开发编写一致、有效的需求。

　　需求模式可以帮助你：
　　■识别系统间的接口、技术以及文档需求。
　　■定义详细的信息需求，包括归档、数据类型以及数据实体。
　　■指定系统的可用性、容量、伸缩性、扩展性以及易用性。
　　■定义访问控制，包括用户注册、认证以及授权。
　　■指定查询、报表、计算公式以及费和税的需求。
　　■获得400多个实际的需求实例，学习如何编写自己的需求模式。

　　■“本书是充满智慧和见解的需求学习图书。”
　　■—Karl E. Wiegers，《Software Requirements》作者

　　■“本书以一种新颖的方式编制优质需求，并对它们进行实例封装。本书是任何业务分析人员的必备工具。”
　　■—Roxanne Miller，Requirements Quest首席顾问

无

本书的目的
太阳下没有任何新东西，所有东西以前都做过了。
——阿瑟·柯南·道尔，《福尔摩斯：血字的研究》

本书的目的是帮助决定和定义新的软件系统需要做什么，建议添加哪些额外的特性，使系统更好或者更卓越。通过详细地指导如何定义一个需求，它将节省你的工作量，使你能更精确。需求模式是技术的结晶，方便将来重用。本书包含37个需求模式，每一种模式描述一种方法，解决在所有系统中反复出现的一种特定的情况，主要关注于商业业务系统。任何系统都只有一小部分属于特定的业务范围，不管系统是做什么的，大部分是反复出现的。这些模式覆盖了一些系统中超过一半的需求（如果添加模式建议的额外需求，会覆盖更多）。
如果你对“需求”这个词敏感，那大可不必；它并不意味着要卷入乏味的文档工作。使用传统分析方法的业务分析师和使用敏捷方法的架构师和工程师都可以使用本书。即使不需要编写正规的需求文档，使用需求模式也可以帮助识别和定义系统需要做什么。
软件系统的需求定义它要解决的问题：它的意图和目的。如果需求遗漏或者做的很糟糕（遗憾的是，这是非常常见的情况）系统就不可能是合适的，不管系统实现得如何完美。相当比例的计算机系统被认为是不合格的；很多甚至没有交付使用；更多的是延期或者超预算。很多研究都表明最大的一个原因就是拙劣的需求定义：没有完全地确定系统的意图和它必须做的事。甚至稍微改进需求就可能节省商业上浪费的大量投资。
为了确保构造更好的系统，需要一系列的改进。几乎各个领域已经（而且将继续）进行大量的投入。但是其中最基础的是需求本身表达什么（同样重要的是不能表达什么）。这点被忽略了，而这正是本书所关注的。如果想定义一种特定类型的需求，需要写什么？如何着手？需要考虑哪些额外需求？其他还有什么应该考虑？本书指出很多方面（大的或小的）的需求经常不充分，不准确，或者完全遗漏，并针对这些问题提出建议。模式本身希望是脚踏实地和实用的多年以来积累的经验（主要来自个人的经验）。
本书是一本参考书，当你需要处理一种特别的情况的时候帮助你摆脱困境——解释需求需要传达的内容，帮助提出问题，指出可能的缺陷，提示额外的需求，提供需求实例，以及提供实用的建议。你不需要通读本书就可以开始使用需求模式。
本书包括很多需求实例（超过400个），很多都可以不用修改就应用于任何系统，其他则可以作为适应读者的各种需要的需求的出发点。这些例子是本书的核心。本书中所有的需求模式来自于实际需求的研究。实际需求中存在的遗漏、含糊以及其他的问题为需求模式提供了很多内容。
本书也指导如何编写需求规范中其他种类的信息（例如，系统范围、假定、词汇表、文档历史和参考）以及如何组织需求规范。本书不做什么
本书不涉及定义需求的流程，分析技术以及需求管理。有很多关于这些方面的优秀的书籍，本书可以作为它们的参考书。不过本书可以很好地单独使用；它包括一节“定义需求速成课程”，（参见第1章）可以帮助没有经验的读者。
本书不关注任何特定的方法论、办法，或者定义软件的工具。不管你选择如何工作，本书都提供相关的建议。本书不是规定：它不会说“你必须这么办。”本书避免使用行话，并尽可能不引入自己的术语。
你不必同意本书的所有观点，也不需要完全照需求模式的建议去做。但是无论是在编写需求的时候还是在之后，如果它帮助你节省了时间，如果它物超所值，那么就值得保留。希望这些模式是足够有用的、引发思考的材料，引导建立更好的系统，从而可以以某种方式证明它是有用的。
谁将从本书中受益
本书的主要读者是涉及决定一个新的软件系统需要做什么的任何人。这就是定义一个软件系统的需求要完成的工作，即使你不喜欢“需求”这个词，或者你不以编写完整的需求规格为目的。为了方便，对任何定义需求的人，我们称之为分析师；他们可能是业务分析师、系统分析师、系统架构师，或者软件工程师；他们可以是业务人员，也可以是技术人员。他们以前可能有定义需求的经验，或者他们没有。他们可以分为两种人：使用传统的分析流程和使用更敏捷一些的方法：
a）业务分析师，或者任何完成这个角色的人。本书不对读者的经验做任何假设：它既适合经验欠缺或经验丰富的业务分析师，也适合以前从没有定义过需求的业务人员和软件工程师。需求模式可以迅速付诸实践。
b）软件架构师和工程师，所负责的系统的需求还没有确定——必须弥补这块空白，不管它使用什么样的方式。无论谁决定系统需要做什么，本书的建议都是有用的。即使组织内部没有专职的分析师，特别是采取敏捷方法开发的组织，它的建议是同样有价值的。敏捷方法不注重（如果有）编写需求规格，但还是要确定系统的功能——无论使用敏捷方法还是传统的方法，本书中的需求模式提供同样的帮助。特别是在极限编程中，需求模式可以帮助编写用户故事，解释用户故事，并为开发人员建立良好的实践规则。熟悉设计模式的软件架构师和工程师应该很容易接受需求模式。
本书的其他读者：
c）任何被要求评审需求规格的人，这包括技术、管理、销售人员以及新系统的用户团体。本书帮助评审人员判断规格的质量和完整性，以及发现遗漏。
d）实现需求的软件开发人员，每个需求模式都包括“开发考虑”部分帮助开发人员。
e）测试交付的系统满足需求的程度的软件测试人员。每个需求都包括“测试考虑”部分建议测试人员如何测试这种类型的需求。
f）管理系统需求，需求的变更以及实现需求的项目经理。
从本书中受益的人员的职务包括业务分析师、系统分析师、业务系统分析师、软件架构师、系统架构师、软件工程师、测试工程师、产品经理、项目经理、项目办公室经理以及首席技术官。
读者的收益
亲爱的读者，阅读本书（以及作为参考书）你将能够提高下列方面的技术和生产效率：
1）你将能定义更好的需求——更详细、准确以及清晰，并且更少的不确定性。
2）通过利用本书的一些成果（重用！）你将能更快、更省力的编写需求。
3）你将认识到需求应该额外定义一些主题，进一步提高需求的质量，使需求更完善。
4）你将可以更好的组织需求规格，编写概要部分（例如词汇表）。你、你的同事、你工作的机构将因此获得进一步的收益。
5）更容易估算构造定义的系统所需的工作量。
6）开发和测试组会更容易理解需求。
7）得到的系统将更好地体现组织的需要，有此可能产生相当客观的额外的投资回报。为了避免酿成大祸，你愿意承担多少代价呢？
8）重大的错误、误解以及遗漏将更早发现——考虑到在设计阶段改正缺陷的代价大约是需求阶段的10倍，而开发阶段则10倍不止，这意味潜在着极大的节约。
读者需要的技术和经验
阅读本书不需要以前有定义需求的经验。第1章是一个速成课，包括初学者开始着手所需的最低要求。入门更好的办法是阅读一本关于需求工程的好书（例如第1章开始提到的书籍），阅读过的读者或者已经是经验丰富的业务分析师的读者将从本书中获益更多。使用敏捷方法的软件工程师可以单独使用本书。任何负责评审需求规格的人不需要以前的知识或技术就可以使用本书获得帮助。
非技术人员也可以阅读本书。它关注的是以自然语言编写需求，任何人都可以阅读。它不使用晦涩的图表格式，深奥的理论和术语。即使不知道UML(统一建模语言)或其他规范化语言，也不会影响阅读。
本书的结构
本书分为两部分：
 第一部分：准备开始包括4个解释性的章，第1章是写给没有定义需求经验的读者——但是所有人都可以阅读，因为它讲述了一些基本原则，对阅读本书很重要。第2章描述了需求规格包含的素材的类型，除了需求本身之外。本书中的第1章和第2章只是更长的完整版本的纲要，你可以从相关的网站上下载完整版本（参见下面“辅助资源”的描述）。第3章解释了什么是需求模式：基本要素，每个模式包括什么，它们如何组织（形成领域），以及相关概念。第4章解释了如何使用需求模式，以及如何编写自己的需求模式。
 第二部分：需求模式目录是一组经常出现的需求类型的模式，可以作为参考书使用。它首先概述了本书中的需求模式，后面的8章（第5~12章）是需求模式的具体描述。
最后给出了书中用到的术语和缩略语的列表，以及参考资料的列表。
笔者建议通读第一部分，以便了解需求模式是怎么回事。如果你认为本书的第1章和第2章不够充分，可以参考网上的完整版本。不必系统地仔细阅读第二部分，只需要熟悉它包含哪些模式（除非你是渴望进步的分析师），当遇到某个模式可以帮助你的时候，再去参考它。
辅助资源
你可以从本书的网站http://wwwmicrosoftcom/mspress/companion/9780735623989下载下列文档：
1）完整版的第1章。
2）完整版的第2章。
3）“需求实例”。本书中所有的一整套实例，加上所有需求模式的需求模板，这样更容易复制和粘贴模板和实例，作为编写你自己需求的出发点。这个文档也包括一个需求模式的模板，可以在编写你自己的模式时使用。
4）适合打印的“现成的参考资料”，包括所有需求模式的图表，并且列出了所有需求模式和每个模式的适用性（使你更容易决定什么时候使用哪个模式）。
前两个文档既有Adobe PDF格式的也有微软XPS格式的。后两个是微软Word文档。下载这些文档需要大约6MB的磁盘空间。看这些文件需要的系统配置，请参见网页。
致谢
非常感谢大量人员认真的慷慨的贡献，没有你们的帮助，本书可能会拙劣很多，甚至可能根本没法完成。首先要特别感谢Trish Reader一直以来的鼓励、中肯的业务分析建议，以及对各种草稿的及时反馈。
非常感谢所有的评审人员，特别是仔细阅读和评论了本书的每一页上的每一个字的人：Roxanne Miller，感谢她深刻理解业务分析师对本书的需求，也感谢她使我对分析技术（相对的）迷途知返；Lydia Ash，感谢她的测试专业知识以及无数的针对各个方面的宝贵建议；感谢Robert Posener的反馈和建议，以高级项目经理的锐利眼光仔细审查本文；感谢Craig Malone的开发方法论（特别是敏捷方法方面）；感谢Marc Munro在信息和数据实体模式方面的数据库专业知识；感谢安全大师Eric Fitzgerald的访问控制知识以及易用性专家Annuska Perkins、Norm Hodne、Ramkumar Subramanian和Laura Ruby；最后，感谢Shanno Sanders对本书整体方向的敏锐洞察。就像对待以前犯的所有错误，有时候我固执地坚持不采纳他们的意见——对此我承担全部的责任。
感谢Karl Wiegers为本书所写的序，以及对我开始着手本书前的鼓励。
感谢微软出版社的所有人员，特别感谢策划编辑Ben Ryan对于需求模式概念的信心，感谢编辑Devon Musgrave和Maria Gargiulo巨大的耐心，和蔼地对待我最离奇的想法，以及辛苦的复制编辑工作。
最后，如果没有这么多年以来无数人士对我的职业经验的帮助，本书根本无法编写。最有价值的是两种极端的人士：杰出人士，从他们身上我学习到如何定义和开发好的系统；笨拙人士，他们总能别出心裁地做错事情，提高了我的认识。感谢你们所有的人。微软出版社的支持
微软出版社尽了一切努力保证这本书的准确。在下面的网址上微软出版社提供了本书的勘误：
http://wwwmicrosoftcom/mspress/support/
如果想直接访问微软出版社的知识库，查询相关的问题或者有任何其他问题，使用：
http://wwwmicrosoftcom/mspress/support/searchasp
如果有任何意见、问题或者关于这本书的任何想法，可以使用下列方法联系微软出版社：
邮寄：
Microsoft Press
Attn: Software Requirement Patterns Editor
One Microsoft Way
Redmond, WA 98052-6399
电子邮件：
mspinput@microsoftcom

本书描述了37个真实的、可重用的模式，为编写软件需求提供了特定情形下的框架。每种模式详细描述需要包括哪些信息，提醒常见的缺陷，以及建议需要考虑的额外需求。无论使用传统的分析方法还是敏捷方法，都可以学习如何使用需求模式，从而为成功的软件开发编写一致、有效的需求。 需求模式可以帮助你： ■识别系统间的接口、技术以及文档需求。 ■定义详细的信息需求，包括归档、数据类型以及数据实体。 ■指定系统的可用性、容量、伸缩性、扩展性以及易用性。 ■定义访问控制，包括用户注册、认证以及授权。 ■指定查询、报表、计算公式以及费和税的需求。 ■获得400多个实际的需求实例，学习如何编写自己的需求模式。 ■“本书是充满智慧和见解的需求学习图书。” ■—Karl E. Wiegers，《Software Requirements》作者 ■“本书以一种新颖的方式编制优质需求，并对它们进行实例封装。本书是任何业务分析人员的必备工具。” ■—Roxanne Miller，Requirements Quest首席顾问

求开发是困难的！很多需求分析师缺乏训练或者经验不足，他们没有必要的编写高质量需求的知识，只是尽力做好。分析师们经常提出一些问题，比如：“我从哪里开始？”，“我怎样知道什么时候我做完了？”，“需求应该详细到什么程度？”，“我遗漏需求了吗？”，以及“我写的需求里忽略了一些关键信息吗？”遗憾的是，对于理解和定义需求这种沟通密集型的挑战没有公式化的方法。
　 本书可以帮助分析师编写出更好的需求。这些模式提供了一种方法表达关于不同类型需求的全面的结构化知识。需求开发是探险之旅，不只是简单地收集或抄写的过程。Steve提出的模式可以帮助分析师询问合适的问题，以恰当的详细程度正确地理解和定义很多类型的需求。从需求使用者角度来看，模式协助开发人员和测试人员在开发阶段了解需求。人们通常从实例中学习，而且模板可以使他们的工作更有效。基于这个目的，Steve的需求模式提供了模板和实例。
　 这些需求模式适用于多种多样的项目和产品。你可以应用本书中的概念开发你自己的行业、应用领域或者产品线的特殊的需求模式。太多的项目从零开始定义需求，而需求模式使开发组织可以有效地重用以前项目获得的需求知识。
　 本书传达了大量的编写高质量需求的智慧和洞察力。Steve指出使用模式以一致的风格编写需求的价值，它可以增强每个分析师的能力。即使不想严格地使用模式，本书包含的几百个实用提示也可以帮助定义更好的需求。还可以使用本书作为参考：阅读相关的模式，尝试它们，吸收Steve提出的思想和建议。透彻理解模式适用的情况后，你会自觉使用它们探索、分析、记录和使用软件需求。
　 需求模式可能代表了未来软件需求思考的方向。本书或许将是未来几年关于需求模式的最权威的著作。

　 Karl Wiegers
　 2007年4月

Stephen Withall：Stephen Withall: 有近30年开发和定义软件系统的经验，曾经为全球多个行业组织工作。在其职业生涯中，他扮演了很多角色，包括程序员、业务分析师、架构师以及首席技术官。

曹新宇：暂无简介

软件大师Frederick PBrooks在他的著名著作《人月神话》中有一句话：“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification(软件任务的最艰难之处在于取得完全和一致的规格说明，构建程序的主要核心实际上是调整和完善规格说明)。”本书就是关于如何更好地完成软件开发中最艰巨部分的一本书。
　　业务和软件技术是两个完全不搭界的东西。怎样能够使技术发挥作用，为业务服务，需求正是弥补业务和技术之间的差距的一种方法。现在很多项目的需求存在的普遍问题是业务和技术完全脱节，要么是过于偏向业务，要么过于偏向技术，如何在业务和技术之间取得折衷，本书提出了需求模式的概念，为这一问题提供了很好的答案。需求是平衡的艺术，既要对开发人员有指导意义，又要能帮助业务解决问题，如何在两者之间取得平衡，本书中的大量实例对此有自己的独特见解。或许你对本书中的一些内容会有不同的看法，可能会觉得啰嗦，不实用，但是需求模式这个概念绝对是未来软件需求分析发展的方向。
　　翻译一本书类似做一个庞大的软件系统的开发，作者是设计师，我是开发人员，而读者就是测试人员。作为开发人员，我与作者就原著进行了大量的沟通，并且尽量忠实地翻译原文，但绝对不能保证完全反映了设计人员的意图，没有任何bug。作为测试人员的读者在阅读过程中一定会发现一些不合适的地方，有任何不妥当的地方还请您见谅。
　　本书翻译过程中，Stephen Withall先生总是非常及时、耐心地回答我的所有问题，甚至有些“啰嗦”，我想这是一个优秀的业务分析师的“通病”。
　　感谢机械工业出版华章分社给我机会翻译这部优秀的著作。另外清华大学的杨经纬帮助审校了部分章节，在此一并感谢。

曹新宇
2008年6月

译者序
序
前言


第一部分准备开始
第1章需求概述
11什么是需求
12需求在总体方案中的位置
13一些基本原则
14传统需求流程
15敏捷需求流程
151极限需求流程
152增量需求流程
第2章需求规格的内容
21介绍部分
211系统目的
212文档目的
213需求格式
214词汇表
215参考书目
216文档历史
22上下文部分
221范围
222主要假设
223主要排除
224关键业务实体
225基础架构
23功能域部分
24主要非功能要求部分
第3章需求模式概念
31需求模式概述
32需求模式剖析
321基本细节
322适用性
323讨论
324内容
325模板
326实例
327额外需求
328开发考虑
329测试考虑
33领域
34需求模式组
35需求模式之间的关系
351需求模式分类
352提炼需求
353转移需求模式
354需求模式和方法的多样性
355需求模式用例
356业务规则和需求模式
第4章使用和编写需求模式
41何时以及如何使用需求模式
42裁剪需求模式
43编写新的需求模式
431如何发现潜在的需求模式
432如何编写需求模式
第二部分需求模式目录
第5章基础需求模式
51系统间接口需求模式
52系统间交互需求模式
53技术需求模式
54遵从标准需求模式
55参考需求需求模式
56文档需求模式
第6章信息需求模式
61数据类型需求模式
62数据结构需求模式
63标识符需求模式
64计算公式需求模式
65数据寿命需求模式
66数据归档需求模式
第7章数据实体需求模式
71活实体需求模式
72交易需求模式
73配置需求模式
74编年史需求模式
75信息存储基础架构
第8章用户功能需求模式
81查询需求模式
82报表需求模式
83易用性需求模式
84用户界面基础架构
85报表基础架构
第9章性能需求模式
91响应时间需求模式
92吞吐量需求模式
93动态容量需求模式
94静态容量需求模式
95可用性需求模式
第10章适应性需求模式
101可伸缩性需求模式
102可扩展性需求模式
103非狭窄性需求模式
104多样性需求模式
105多语言需求模式
106安装性需求模式
第11章访问控制需求模式
111用户注册需求模式
112用户认证需求模式
113用户授权需求模式
114特定授权需求模式
115可配置授权需求模式
116批准需求模式
第12章商业需求模式
121多组织单元需求模式
122费/税需求模式

词汇表
参考文献