ATDD的原则传统的软件需求（Specification）存在一个问题：需要特别的努力才能做得好。

然而一旦它们编写完成，很快就会因为各种原因（你能控制的，或无法控制的）而迅速过时。

举个例子，如果一个竞争对手发布了一个新特性，你的需求要立刻响应以保持你的市场份额。

由于这显然是一个非技术决策，所以至少需要一些有业务背景的人参与需求决策过程。

在确定需求过程中获得的意见越是多样化，你就越能看清楚整个应用的全景。

通常来说，你至少需要从三个不同的视角考虑。

首先，需要考虑业务视角。

在敏捷团队中，这方面需求通常由客户代表、客户代理人或是Scrum中的产品负责人（Product Owner）来提出。

其次需要考虑技术视角。

在传统的团队中，资深开发人员或技术负责人通常会站在这个视角。

在敏捷团队中，你会希望讨论会中有一个参与实际开发工作并熟悉源代码的团队成员参加。

最后，需要有人在这两种视角中充当中间人。

在传统项目中，你会发现业务分析人员会提供这种视角。

一个富有经验的软件测试人员会带来同样的价值。

1 见识“三的力量”可是为什么这三种不同的视角可以帮助我们确定产品的需求呢？设计软件系统包含很多对这两个方面的权衡：业务功能与技术限制。

我们的软件代码中充满了对功能和限制所做的折衷。

另一方面，我们的缺陷数据库中则充满了由明显决策失误而导致的问题。

这些决策中，有些在软件开发过程中很难改变，有些则很容易改正。

通过尽早让业务功能和技术限制这两种不同的视角接触，我们可以尽早找到正确的决策平衡点。

因而，可以将引入难以改正的bug和容易改正的bug 的概率降到最低。

顺便我们也可以避免这两种极端情况中间的那些bug。

软件系统的功能分布在一个解决方案空间中[GW89]。

这个解决方案空间中存在很多可以实现所需功能的可行设计方案。

这就解释了为什么你可以带着性能或负载等特性的需要去探索解决方案空间。

这些特性限制了解决方案空间中能满足用户期望的方案的数量。

另一方面，软件实现还存在技术方面的制约。

这些制约同样限制了实现所有功能以及特性的设计方案数目。

将业务功能和特性与技术的制约尽早放在一起考虑，可以帮助参与者在解决方案空间中探索可能的设计。

这是验收测试驱动开发方法可以成功的重要因素之一。

并且，它证明了测试人员在这个探索过程中也能发挥作用，他们可以对软件在功能、特性以及制约方面提出问题和建议。

但是，怎么看待独立的测试团队能带来独特的视角这一观点呢？在过去数十年的测试培训中，我们学到的观点是：开发人员和测试人员应当基于需求文档这一共同的基础而完全独立的工作。

这避免了在现代心理学中被称为共识偏见(confirmation bias)的现象。

测试人员必须避免受到开发人员观点的影响，并且在应当在适当的时候对产品作出评价。

一些团队将这条规则发挥到这样一种极致：开发人员与测试人员被完全禁止与对方交谈。

与开发人员一起描述软件需求并不会给测试人员带来先入为主的偏见。

相反，开发人员、测试人员与业务专家应该一起捕捉软件需求。

如果你认为这也会使测试人员产生偏见，那么你是不是该开始怀疑阅读需求文档也同样会使测试人员产生偏见？对于测试人员，与开发人员以及业务专家一起描述需求实例和参加需求讨论会的功用是一样的，这也是大多数测试人员在他们的职业生涯中都梦想能做到的。

事实上，在Gojko Adzic的书《实例化需求》（Specification by Example）[Adz11]中采访到的团队反映，由至少一个开发人员和一个测试人员提供的综合观点，会让我们在项目初期就更好地理解需求。

就像我们在机场的实例中看到的一样，这种讨论通常会达到以下的效果，开发人员通过提出技术性的问题来澄清业务流程，同时测试人员提出的问题则增加了需求的可理解性，并且用表格这一更加可视化的方式记录了需求。

1在迭代过程中，开发人员与测试人员基于对特性共同的基本理解开展工作。

作为验收测试的实例则成为衡量团队进度的指标。

为了达到最好的结果，确认需求的过程应包含以下三种不同的角色：一个业务专家（例如Produce Owner，或驻厂的用户）、一个开发人员和一个测试人员。

基于所包含的角色个数，Janet Gregory和Lisa Crispin把这叫做“三的力量”。

“三种解释原则”[Wei93，90页]提醒我们在对收到的信息下结论之前，至少要想到3种可能的情况。

如果我对收到的信息不能想到至少3种解释，就说明我对它的含义考虑的还不够全面。

“三的力量”可以帮助我们克服想象力的不足。

让代表三种视角的人坐在一张桌子旁，充分理解特性或用户故事的可能性就会大大增加。

这就是“三的力量”为何如此强大的原因。

“三的力量”不仅限于功能性需求。

开发人员会注意到代码可能存在的性能问题，而要求澄清这方面的需求。

测试人员通常会注意到可用性方面的问题。

开发人员、测试人员和业务代表可以澄清对所有特性在质量方面的要求——有些时候这被称为非功能性需求。

记住，要考虑到自动化测试无法覆盖的问题，并使用测试象限（见图9-2）来构建你的测试交响曲（见9.4节）。

大多数的性能、负载以及稳定性的需求可以通过自动化测试来检测。

2 举办讨论会如同我们在第一部分看到的，讨论会可以使整个团队对将要实现的功能获得一致的理解。

你必须仔细考虑以下方面，才能组织一场让大家（包括不出席会议的）都满意的需求讨论会。

2 1 参加者首先，你要确保自己选择了正确的参与者。

对有些团队来说，这可能意味着包含整个开发团队以及来自不同公司的所有用户。

这些团队通常都会举办一次比较大型的会议，但每个迭代都会开个小的碰头会。

另一方面，也有团队在讨论会中只包含三个角色的代表，就是只有三个人参加的小型会议。

无论哪种情况，你都需要保证存在不同的视角。

通常这意味着要包含熟悉产品业务方面的人。

你同样需要有直接能接触到专业用户的人[Coc06]。

如同我在10.1节中提到的，你应当包含至少一个开发人员和一个测试人员。

这个开发人员要熟悉代码。

在需求讨论会中，开发人员会基于功能的技术实现提出问题。

由于他们自身的特点，开发人员会考虑功能如何实现并且在他们的脑海中构建领域模型。

讨论会能使他们对新功能点对应的业务领域取得一致的理解。

测试人员通过他们批判性的眼光，可以很快发现业务规则中的漏洞。

测试人员在需求讨论会中发挥的另一个独特作用是：他们能够使用表格记录业务规则，使其变得清楚透明。

无论他们是否使用过被称为“敏捷友好”的自动化测试框架，有经验的测试人员都知道如何使用决策表以及如何用表格形式表达复杂的业务规则。

如果大家在需求讨论会中使用这样的表达方式，那么开发人员、测试人员和业务专家就可以在没有写任何代码之前就对讨论的功能点达成共识。

2 2 讨论会的目标为了使需求讨论会能开得成功，你要知道谁是你的主要听众。

虽然领域专家带来了关于新特性的必要知识，但是开发团队（开发人员和测试人员）才是你的主要听众。

还要记住很重要的一点，客户和外部业务专家通常都很忙。

如果你邀请他们参加会议，而会上你的开发人员们在激烈争论是否要使用最新的Web服务器，以及要使用哪种技术，那么下一次他们可能就不会再参加你的讨论会了。

你需要一个有经验的引导者使会议集中于讨论特性，而不是争论具体实现的技术问题。

讨论会的目标是对业务规则取得一致的理解。

你可以在业务代表离开之后再接着讨论所有的技术问题。

在需求讨论会上花费的时间应该用来使团队获得共同的理解和愿景。

2 3 频率与时长下面要讨论的问题是你应当多频繁地组织这样的讨论会。

当然，这很大程度上取决于领域专家是否有时间。

如果你需要联系一些业务代表，你会发现他们都很忙。

另一方面，你可能有驻厂的客户，那你就可以经常向他请教一些问题。

你可以根据实际情况，每个月为需求讨论会预留一个时间段，或者在每个迭代开始前开一个简短的讨论会。

你可以根据与领域专家一起参加需求讨论会频率的高低，为会议预留不同的时间长度。

如果你不经常举行需求讨论会，那么你可能希望每次多讨论一些特性，因此你需要多预留一些时间。

另一方面，如果你既希望保持会议简短，又希望开会不那么频繁，那么你只能选择少讨论一些特性，或者提前做一些准备工作。

如果你希望少讨论一些特性，那么你需要根据最新确定的优先级，从代办事项列表中挑选要讨论的特性。

应当首先讨论那些最有可能在下一个迭代中开发的特性。

你可能需要在讨论中跳过一些对团队来说已经比较清楚的特性，例如登录功能或者网页上的某个注释信息。

这会让你有更多时间讨论更复杂的特性中充满挑战的业务规则。

如果你想事先做一些准备，可以在讨论会之前研究一下代办事项列表，准备一些需要业务专家回答的问题。

你可以在大多数Scrum团队都有的代办事项列表准备会（backlog grooming meeting）上收集一些开放性问题。

也可以在讨论会前几天召集一个简短的会议讨论一下将要实现的特性。

另一种收集关于业务规则的想法和开放性问题的方式是在会议中将当前的理解可视化，通过思维导图（mindmap）来收集开放性问题。

但是你要记住，如果你在需求讨论会中打开投影仪，利用思维导图来收集答案，这样的会议就开始变成一种折磨。

因为你在强迫所有人安静地坐着，看你用投影仪打出来的字。

使用非高科技的工具，例如索引卡片、白板或者翻页纸版可以让你避免那些低效的会议，但你需要有人辅助你来记录讨论结果。

3 捕捉需求需求通常都不是收集到的[Coh04]。

客户与业务专家认为他们清楚地知道他们想要的是什么。

但当他们看到最终成果后，你和你的团队就会发现他们需要的是完全不同的东西。

这就是为什么说使用“收集”需求这个隐喻并不恰当的原因。

只有当它们明显地摆在那里，每个人都可以捡起来去实现所期望的软件时，才能说是收集需求。

不幸的是，需求并不是躺在那里等你去捡的。

大多数团队付出了很大的代价才明白这一点。

Mike Cohn建议采用一个不同的隐喻来取代“收集”。

既然需求不是躺在那里等着我们去收集的，因此我们需要付出一些努力才能抓住它们。

有一些技巧可以在不同层面帮我们做到这一点，就像使用不同网眼大小的渔网可以捕捞不同种类的鱼，而漏过其它种类的鱼一样。

这个类比可以很好地用来解释“实例化需求”中的各种不同技巧。

在前面的例子中，我们见到过两种应用都很广泛的实例化需求实践。

第一种是有一个独立的测试团队，可以在实现软件某个特性时与开发人员并行工作。

在这种情况下，我们的渔网意味着在产品中加入任何新的特性之前获得对特性的一致理解。

停车场例子中，整个团队在一起捕捉需求。

因为每个人对停车场都有一个基本的理解，所以团队成员通过提一些问题就可以对机场停车费用计算取得一致的理解。

这些问题就是我们捕捉实例所用的工具。

测试人员Tony很快就发现他可以通过记录实例来表达他对业务规则的理解。

在他记录的同时，Phyllis和Bill可以观察，并讨论他们的“渔网”还漏掉了什么。