实例化需求

实例化需求包含实例化需求说明和技术实践。实例化需求说明可以帮助团队构建正确的软件产品，而技术实践可确保正确地构建产品。我们要二者兼顾才能获得成功。

正确地做正确的事

要想有效地构建正确的产品，软件开发实践必须满足以下几点：

保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解；

有准确的需求说明，这样交付团队才能避免由模棱两可和功能缺失造成的无谓返工；

有用来衡量某项工作是否已经完成的客观标准；

具有引导软件功能或团队结构变更的文档；

传统意义上，构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。如今，软件每周都要有交付，这一套已经行不通了。我们寻求的方案要能带来如下好处：

避免过度说明需求从而产生浪费，避免花时间在开发前会发生改变的细节上；

有一种可靠的文档，可以解释系统的行为，据此我们能容易修改系统行为；

可以有效地检查系统行为与需求说明的描述是否一致；

以最少的维护成本维持文档的相关性与可靠性；

适合短迭代和基于流的过程，这样能为即将开展的工作提供及时足够的信息。

实例化需求可以帮助团队达成这些目标。使用实例化需求说明，团队编写的文档数量恰到好处，在短迭代或基于流的开发中可以有效地协助变更。

实例化需求实现模式：

实例化需求说明的主要过程模式

1、从目标中获取范围

实现范围含有对业务问题的解决方案或达成业务目标的手段。很多团队在开始实现软件之前，期望客户、产品负责人或商业用户来确定工作的范围。在商业用户明确说明他们的需求后，软件交付团队就依此实现。这样本应该让客户感到满意。但事实上，这正是构建产品开始出现问题的时候。

如果软件交付团队依赖客户给出用户故事、用例清单或其他相关信息，那么他们其实是在让客户设计解决方案。但是商业用户不是软件设计师。如果我们让客户去界定范围，那么项目就无法从交付团队已有的知识中受益。这样开发出来的软件是客户所要求的，却不是他们真正想要的。

成功的团队不会盲目地接受软件需求，将其作为位置问题的解决方案，相反，他们会从目标中获取范围。他们以客户的业务目标为起始，然后通过协作界定可以实现目标的范围。团队与商业用户一起工作确定解决方案。商业用户专注于传达所需功能希望达到的目的，以及他们期望由此带来的价值，这样有助于所有人了解所需的功能。然后团队提议一个解决方案，这要比商业用户自己想出来的方案更实惠、更快，并且更容易交付或维护。

2、协作制定需求说明

成功的团队不会依赖于某个人独自去收集正确的需求，而是会与商业用户一起协作制定解决方案。不同背景的人们拥有不同的想法，他们会凭借自己的经验来解决问题。技术专家知道如何更好地使用底层的基础架构，或者如何应用新兴的技术。测试人员知道从哪里寻找潜在的问题，而团队则应该去做防止出现这些问题的事情。在设计需求时需要捕获所有这些信息。

协作制定需求说明使我们能够充分利用整个团队的知识和经验。它还创造了需求的集体所有制，让每个人能更多地参与到交付过程中。

3、举例说明

自然语言是模棱两可的，而且和上下文相关。仅仅使用此类语言编写的需求，无法为开发或测试提供一个完整明确的上下文。开发人员和测试人员在开发软件及编写测试脚本的时候，必须对需求进行解释，而不同的人可能会对一些棘手的概念有着截然不同的解释。

在使用编程语言实现需求的过程中，成功的团队不会等待需求被精确表述，而会举例说明需求。团队与商业用户一起工作，确定出那些描述预期功能的关键实例。在此过程中，开发人员和测试人员往往会提出一些额外的实例，用于说明边界情况，或重点标识出系统中某些特别有问题的地方。这可以清除功能分歧和不一致的地方，并确保所有参与者都对需求交付的东西有一个共识，避免由误解及解释不到位导致的返工。

如果系统能按照所有关键实例那样工作，那么它就是大家都认同的。需求说明的关键实例有效地定义了软件需求做什么，他们不仅仅是开发的目标，还是检查开发是否完成的客观评价标准。如果关键实例容易理解和沟通，就可以被有效用作清晰和详细的需求。

4、提炼需求说明

关键实例必须精简才有用。通过提炼需求说明，成功的团队能够移除多余的信息并未开发和测试创建一个具体的、精确的上下文。他们以适量的细节来定义目标，以便实现和验证。他们应明确软件该做什么，而不是软件该如何工作。提炼好的实例可以当做交付的验收条件。只有当所有实例在系统中都可以正常工作时，开发才算完成。为了让关键实例更容易理解，团队要提供一些额外信息，此事，实际上团队就已经创建出了带实例的需求，它是一种工作规范和验收测试，有可用作将来的功能回归测试。

5、自动化验证时不修改需求说明

一旦团队对带实例的需求达成一致并且对其进行了提炼，那么团队就可以将它们当作要实现的目标以及验证产品的手段。在开发过程中，这些测试将对系统进行多次验证，以确保它符合目标。人工运行这些检查会产生不必要的延误，并且反馈也比较慢。

快速反馈是短迭代或流程模式软件开发中的一个必不可少的元素，所以我们要把验证系统的流程变得廉价而且高效。一个显而易见的解决方案就是自动化。为了从关键实例中获得最大的收益，成功的团队在做自动化验证时不会去改变需求信息。在自动化过程中，他们几乎完全不改变需求说明---这样就不会有写错的风险。

当他们进行自动化验证而不改变需求说明时，关键实例看起来与他们写在白板上的几乎一样，团队的所有人员都可以理解、可以访问。团队所有人员都可以理解、访问的自动化的实例化需求说明，变成了可执行的需求说明。我们可以把它作为开发的目标，同时可以轻松地检查系统是否按照预期运作，而且我们可以使用同一个文档获取商业用户的澄清。如果我们要变更需求说明，只要在一个地方变更即可。

6、频繁验证

我们可以很容易地针对系统验证可执行的需求说明，如果验证比较频繁，那么我们就可以像信任代码那样信任可执行的需求说明。通过频繁地检查所有可执行的需求说明，团第能快速发现系统和需求说明之间的任何差别。因为可执行的需求说明很容易理解，团队可以和商业用户讨论这些改动，并决定如何处理。他们可以不断地同步系统和可执行的需求说明。

7、演化出一个文档系统

成功的团队不会满足于一些频繁验证的可执行的需求说明，他们能确保很好地组织需求说明，让大家很容易找到和获取，并让他们保持一致。随着项目的发展，团队对领域的理解也在变化，市场机遇也影响着业务领域模型。能从实例化需求说明中获取最大收益的团队会更新他们的需求说明来反映这些变化，演化出活文档。

活文档是关于系统功能可靠的、权威的信息源，任何人都可以获得。它和代码一样可靠，但是更容易阅读和理解。支持人员可以用它来查明系统在做什么以及这样做的原因。开发人员可以用它作为开发的目标，测试人员可以用它来测试，分析功能变更请求的影响时，业务分析师可以从它开始着手，它还提供了免费的回归测试。