需求不只包含描述。我们建议(强烈建议)你在需求中添加"理由"，说明需求为什么存在。在某些情况下这可能很明显，但在许多情况下，这是需求的关键部分。
这有一个例子。
描述:产品应该记录已经处理过的道路
第一眼看上去这似乎是一项常规需求，不是很重要。现在让我们为它加上理由。
描述:产品应该记录已经处理过的道路
理由:为了能调度安排未处理的道路并突出潜在风险。
现在它看起来有点严重了，因为人的生命可能存在风险，或者至少产品的拥有者没有承担其法定的职责。加入理由后，你不仅让开发者有机会构建最好的解决方案(该方案让发现未处理道路的功能随时能访问这一信息)，而且也告诉测试人员需要在测试这项需求上投入多少工作量。很清楚，理由表明这项需求值得关注。
理由表明这项需求值得关注。
现在考虑这个例子。
描述:对于卡车被调度的活动，产品应该记录开始和结束的时间。
这是普通的需求，不会带来太多意见。但它对产品贡献了什么价值吗?让我们看看两种可能的理由。
理由:卡车车库负责人希望知道哪辆卡车用得最多。
或
理由:卡车在24小时内最多被安排20小时，以便进行维护和清理。
现在事情有些进展了。第一个理由说需求的优先级很低，可能不值得实现。毕竟，卡车车库的负责人可以通过卡车的转速表来了解卡车的使用情况。但第二个理由表明这是一项有价值的需求，如果它没实现，那么卡车车队就会遇到麻烦，因为卡车可能保养不当。
对描述给出理由，需求本身就变得更有用了。知道了为什么需求会存在，开发者和测试者就更清楚他们应该投入多少工作量。它也向未来的维护者说明了需求一开始为什么会存在。
知道了为什么需求会存在，开发者和测试者就更清楚他们应该投入多少工作量
理由也有助于克服不小心写下解决方案，而不是真正的需求。例如，这项需求描述是为城市公交公司的公交车售票机写下的。
描述:产品应该在触摸屏上提供公交网络路线图。
这个描述实际上是对问题的解决方案。如果添加理由，真正的需要就出现了。
描述:产品应该在触摸屏上提供公交网络路线图。
理由:乘客必须提供目的地，以计算车费。
真正的需要(即真正的需求)是乘客要提供目的地。他们如何做到这一点最好留给有经验的设计师和技术人员。触摸屏可能是实现这个目标的最佳方式，但也可能不是的。如果旅游者是公交车的主要用户，那么他们可能不熟悉公交网络的样子，在图上找到车站可能很慢。这会让后面排队买票的乘客不高兴。而且，如果网络为计费而划分成一些区域，那么对于通勤乘客来说，更有效的方式是表明穿过几个区域，忽略具体的车站。
为什么这方面的需求开发很重要?因为很容易通过描述一种实现来隐藏重要的功能，也很容易选择最明显的实现，忽略可能更好的实现。不论需求最终如何实现，写下描述和理由显然会导致发现真正的需求。
不论需求最终如何实现，写下描述和理由显然会导致发现真正的需求
我们还没有谈到如何确保每项需求可以测量，从而可以测试。我们通过添加"验收条件"来做到这一点。