前言
本书目的
天下无新事，都是以前做过的。
――福尔摩斯：血色研究
作者：柯南道尔
本书的目的是帮助你来决策和定义新的软件系统需要做什么，建议增加什么样的特征能够使它成为好系统，或者甚至成为优秀系统。通过提供详细的指南，教导如何论述单个需求，它会使我们省力和更精确。为了方便重用，需求模式封装了专业技能。书中包含了37个需求模式，每一个都描述了一个在各种类型系统中重复出现的特定类型场景有关的方法，但仅关注于商业交易软件。任何一个系统都会有一小部分论述到它的业务领域。无论系统是为了什么，大量的事情都会一再地重复发生。这些模式覆盖了一些系统所有需求的一半以上，如果增加了额外的模式建议，则会覆盖更多。
如果你对这里的“需求”一词有所堤防，是没有必要的，它不会让你卷入繁辱的文书的工作中。本书适用于传统分析方法的业务分析师，使用敏捷方法的软件架构师和工程师。即使你不写出正式的需求文档作为结果，你也可以使用需求模式来识别和定义系统需要作什么。
软件系统需求所论述的问题是系统需要解决的目标和目的。如果它们被遗忘和作的极差，不幸地是，无论它实现的如何好，个例系统都无法全面地完美适应情境。评定一个破坏比例的计算机系统是不够充分地；许多系统都没法发布；更多的是延迟和超预算。持续化研究表明，最大的原因是需求定义贫乏：不能正确地说明系统目标和它必须作的事情。即使提供了一个适度的需求改进，使局部节约大额度投资浪费的成为可能性。
大部分情况下，构建一个好系统，自始自终，持续性改进是需要的。深刻的成果都基本上已有有了（仍然地在持续）。但它们大部分都是说需求自身是什么（它的重要性，不足）。本书所作的就是被它们忽视的。如果我想去定义一个指定类型的需求，我需要写些什么？我如何去作？我应该考虑写下什么样的附加需求？我担心什么？本书识别出许多领域（大的或小的），它们的需求经常是不充分的、不精确或者被遗漏，本书会建议你作什么。模式本身是务实地，是个人经验自始自终地实践提炼。
这是一本参考书，你在你的实践环境中想搞明白需求需要表达什么，引出询问的问题，找出潜在易犯的错误，建议的额外需求，提供需求范例，提供通常的需求建议。不需要通读全书，便可以使用需求模式。
本书包括了大量的需求范例，其中超出400个例子可以不改变地应用到任何一个系统中，其它的，可以作为读者需求的参考。这些范例是本书的核心。本书中的需求模式来自真实系统。这些真实需求中所遗忘的、歧义的和其它的弱点，需求模式都帮助你做出了解释。
本书也提供了指南，如何写其它类型系统的应纳入到需求规格中的需求，如，系统范围、假设、词汇表、文档历史和参考，且包括如何结构化一个需求规格。
本书不提供
这不是一本论述需求过程、分析技术和需求管理的书。有许多其它更好的书能够解释这些，本书可以作为你枕边参考书。本书在什么程度上，都可以独自地被很好地使用；包括对没有经验的读者的“需求规格的速成”。
本书不主张任何的特定的方法论、方法和软件说明书工具。它提供可选择方法的建议，但不指定：不能说，“你必须使用这个方法”。它清晰地把控行话，避免陷入它自向术语的圈子中的可能性。
你不需要对本书中任何事情都赞同，你也不需要按照需求模式中所有建议来行动。但，如果它能够在你写需求时节约你的时间，这就值得你来购买它，使它获得生存。我希望这些模式能够为你在某种途径或者其它途径上带来好处，提供足够多的材料，引导你作出更好的系统。
本书的受益者
本书的基础读者是涉及到新软件系统范围决策的所有人。即使您不喜欢“需求“这个词，或者你临终也不完整的需求规格，这也是软件系统具体需求的业务。为了方便，我们把任何论述需求的人都叫做分析师，它们可能是业务分析师、系统分析师、系统架构师、软件工程师；他们可能是面向业务，或者面向技术的人。他们可能有以前的经验，也可能没有。他们被分为两类人，一类是使用传统分析过程的，另一类是使用敏捷方法的：
A 业务分析师，或者任何承担这个角色的人。本书不假设读者认识多少：它适应于新手和经验老道的业务分析师和业务执行人员，以前从来没有论述过需求规格的软件工程师。需求模式可以很快把你带入实践中。
B 软件架构师和工程师，他们不在任何一个系统中写需求，但需要补充中间差距，用某种方式或者其它方式。本书的建议对任何能够决定系统范围的人是同等的。它的建议对任何一个没有指定分析师，尤其是使用敏捷开发团队的组织，也同样有一样的价值。敏捷方法很少强调写需求规格，但系统的需求仍然要识别出。当使用传统的分析方式时，本书的需求模式也能够帮助你。在实践的权限编程中，需求模式可以帮助你写使用故事，解释用户故事，为开发者能够遵守好的实践，而规划“规则”。与设计模式中的软件架构师和软件工程师一样，需求模式也适合他们。
第二类读者：
C 要求评审需求规格的任何人，他们广泛地覆盖了技术、管理和销售代表，也包括用户社区中的人。本书帮助评审者鉴别规格的质量和完整性，挖掘中的遗漏。
D 必须实现需求的开发者，每一个需求模式都有一节“开发考虑事项”来帮助开发者。
E 必须测试交付的软件系统是如何更好地满足需求的软件测试者。每一个需求模式都有一节“测试注意事项”，建议如何测试这种类型的需求。
F 管理系统需求、变更、实现项目的项目经理。
能够从本书中找出价值的工作职务包括业务分析师、系统分析师、业务系统分析师、软件架构师、系统架构师、软件工程师、测试工程师、产品经理、项目经理、产品业务经理、首席技术官。
