需求理由的理由

理由就是需求的原因，或存在的道理。我们发现，为需求加上理由，更容易理解真正的需求。利益相关者常常会告诉你一个解决方案，而不是他们真实的需求。或者他们会告诉一项很模糊的需求，以致(暂时)没什么用处。在前面给出的例子中，客户要求一个“用户友好”的产品，但如果你知道了理由是需要让用户采用该产品，这就有了意义。
利益相关者常常会告诉你一个解决方案，而不是他们真实的需求。
假设理由不同。比如说，客户给出的理由不是愿意采用，而是表明“用户友好”产品是指易于使用，与现有产品相比，用户犯的错误更少。对应的需求就有了不同的含义，导致的验收标准也完全不同。
描述:产品应该用户友好。
理由:用户必须发现新产品比原有产品更容易使用，这样他们犯的错误更少。
验收标准:所有用户输入的平均错误率应该小于1.5%。
理由不仅是帮助你发现验收标准的指导，它也帮助你发现，是否有好几项不同的需求伪装成了一项需求。一个利益相关者说的“用户友好”是指产品易于使用，另一个说的“用户友好”是指产品令人兴奋，还有一个说的“用户友好”是指用户愿意再次使用它。在这种情况下，你有3项不同的需求，每项需求都有各自的验收标准，测量期望的属性。

而且，理由也为如何实现需求的决定提供了基础。从开发者的角度考虑:你通常必须选择几种可能的实现方案，如果你理解需求背后的考虑，就能得到最合适的解决方案。当你需要折中的决定时，如果你理解了需求对业务的相对重要性，理解了需求没有正确实现对业务的影响，也有助于决定。
描述:产品应该确保购买者的连接来自批准的国家。
理由:某些国家没有版权法，供应商禁止我们销售给这些国家。
不要忘记测试者需要一致的理由。针对需求的验收标准，有很多种方式来设计测试，有些方式比另一些方式要花更多时间和成本。对怎样安排测试时间和费用，如果测试者要做出最佳决定，就需要理解需求的理由。
必须做许多工作来测量需求的真正含义。

稍后，在产品使用和维护时，理由仍将起到重要作用。通过阅读原代码和观察用户，你可以弄清楚软件产品在做什么。但假定你需要对产品进行变更:如果不理解产品为什么这么做，做出正确变更的可能性就会下降，变更与产品中遥远的相关部分发生冲突的可能性就会上升，这是波浪效应。由于不理解理由而导致的问题，也是软件维护成本非常高的一部分原因。
理由是业务和提交的产品之间的认知纽带。知道了存在的理由，业务分析师就能够发现正确的需求表述，开发者就能够构建正确的产品。
在向利益相关者询问需求的理由时，你可能看起来就像一个儿童，不断问父母为什么。这就对了，因为这是需求分析师的职责。你必须问为什么，不断地问为什么，直到理解了需求的真正理由。但是事还没完，因为还要做许多工作来测量需求的真正含义。这就是为什么要导出验收标准。