第一部分 准备
章节列表
第一章 “速成需求论述”概要
第二章 “需求规格”的内容
第三章 需求模式的概念
第四章 使用和编写需求模式
概述
如何使用第二章－“需求模式分类”－中的需求模式，第一部分为你叙述了有关的所有知识。有两章是需求一般意义的内容（关于如何作和作什么），其余的两章是有关需求模式的。
这是一本关于需求模式的书，所以，我们不想过多陷入到解释如何论述需求和需求规格应该包括什么。但，你需要理解需求模式中使用到这些主题。我们如何使这些主题协调起来？答案是，提供一个长的、全面的描述，但不能在本书中出现，可以从下面WEB站点上获取：http://www.microsoft.com/mspress/companion/9780735623989.。第一章和第二章是用与全面描述相同的方法组织它的概要。它提供对这两主题的快速参考。如果您想了解更多，请参考全面描述。
第一章，“速成需求论述”，是快速地、简略地介绍需求相关的内容，如何找出它们，在传统的风格下或敏捷方法中，是否选择它们来实现。在这样的环境中，传统的方法是在设计和开发系统之前，完成所有内容；敏捷意味着很少担心前期的需求，尽可能地更早开始开发。
第二章，“需求规格内容”，描述了需求规格中都包含了那些内容。第二章的全面描述提供的指南，同需求模式中为个体需求所作的需求规格是同一层面的。这会让你写出完整的、平衡好的、全面的需求规格。
第三章，“需求模式概念”，描述了需求模式参与的角色，每个模式所含（它的解剖），少许相关的概念。
第四章，“使用和编写需求模式”，讨论什么时候、如何去使用模式，描述如何编写出已存在模式，或者从零开始的新模式。
第一章 “需求论述速成”概要
“请告诉我，我应该从这里走哪条路？”艾丽丝问。
“取决于你想往哪里去”，猫回答。
“我不知道该去哪里。”，艾丽丝说。
“你走哪条路都没关系”，猫说。
“只要能到一个地方”，艾丽丝补充道。
“哦，你确定”，猫说，“只要你走够长”。
――艾丽丝奇遇记
Lewis Carroll
概述
本章告诉你的是，你需要理解本书其它部分的必备的最少知识。它是一个本章全面描述的一个快照，这个全面描述你可以从下面的WEB站点上获取： http://www.microsoft.com/mspress/companion/9780735623989（更多见前言）。为了方便，分为快照和全面描述。快照关注于定义全书中用到的概念和术语，作个准备。全面描述作了大量明细（每一个主题），提供了合理的解释理由和建议，但仍然是一个对主题的介绍。但，二者组织方式是一样的：用一些基本的鉴别和合理解释理由开始，然后描述需求是在哪里满足构建系统整体过程的，放出一些值得遵守的原则。二者的描述最终结束于三个需求方法：传统方法，需求被交移到开发阶段前就完成所有内容；极限方法，力求快速开发软件，可以损失正式手续和文档，在这里，需求是不突出的；折中的增量方法，论述的需求可以前面一些，后面再有一些。无论你采用哪种方法，需求模式都是适合和有价值的。
有大量的好书解释了一般意义上和传统方法过程中的软件需求的大量细节。展现了大量的分析技术，覆盖了这里忽略掉的需求的其它活动。这些中，Karl Wiegers写的“软件需求”(Software requirements,Microsoft Press, 2003)是我最喜欢的（还有其它的，在本书的明细中）。这章（包括全面描述），都不能代表那些。鼓励读者在它们的一本或多本上投入精力。
即使你坚持认为你不需要写需求规格，在你的项目中伴随着设计和构建系统中也不包括需求阶段，但你也必须作一些事情，所以，本章假设你想这一个新系统定义一些东西。在本书看来，一个系统是由软件构件和它运行在上面的硬件（可选）组成的集合物，本书步把使用系统的任何人看作是系统的一部分。
本书不假设与记录需求有关的任何风格。最直接的方法是使用文字处理器。可选择的是，你可以使用尤其为目标而构建的需求管理工具。
1.1什么是需求
至少我已经掌握了案件的真相。我应该对你详述，无偿地解决了一个案件，而且把它陈述给另外一个人，如果我们从一开始不亮明你的地位，我是很难取得你的合作。
――福尔摩斯：银光
Arthur Conan Doyle
让我为需求作个简单定义：
一个系统的需求定义它需要作什么，而不是如何作。
需求定义已被解决的问题：系统是为什么存在，为了完成它需要的每件事情。他们没有定义一个解决方案。需求是单一的，系统必须被满足的可度量目标。最好用纯文本来表达每一个需求。系统的需求是一份插入了所有背景材料的文档，使它易读、易理解。它需要定义系统占据的所有功能和其它能力。
进入需求的东西，没有唯一“正确”的明细程度。需求可能被多种明细程度。广义上需求被揉进去了更多的特殊需求，阐明了原始需求中暗含的含义。也可能在不同的层面写多个需求规格。一些组织和专家把需求分解为多种层面，“高层次”需求，捕获业务目标；“明细”需求，阐明系统需要完成业务目标的功能和其它能力。本书不把需求分隔成不同层次。然而，书中的需求模式各处会导入两个（甚至3个）它们自己局部的层次，展现如何把宽泛的目标分解成清晰的需求，使它能够满足开发明细的要求。例如，如果我们的系统必须满足一个特殊的标准（一个宽泛的目标），我们必须明确系统达成目标必须作的事情的明细需求（作什么，但不说如何作）。
需求定义了系统必须作的最重要事情，它是必须能够执行的活动。这些被叫作功能需求。它们被注入了大量的精力，经常忽略其它的特征，系统必须完成的特征，这些特征叫做非功能需求。它包括了更广泛的话题，从性能到完全，到标准，这些都是系统必须遵守的。
论述需求的过程是识别出系统需要作什么。无论需求是否清晰地阐明了，它都是曾经构建过的每个系统需要履行的。决定需要什么一个程序，简单地理解，就去编码，也是沿着这种方式快速地履行了需求规格过程，即使在超越令人兴奋的设计灵感之前需求是一闪念的时候，也是如此。我坚持认为，写下所有的需求计划是有利的，以便他们被用来讨论和鉴别出他们自己的正确性，独立于解决方案的设计。成熟的需求定义阶段不仅只有一个途径可完成。
