需求蔓延是指，在大家认为需求已经完成后，新需求又进入规格说明书。很自然，需求过程永远不会结束(产品不断地演进)，但是总存在一个项目阶段，在这个阶段打算要开始构建产品的工作。在这个阶段之后发生的需求被视为需求蔓延。
质量关在控制蔓延方面是有作用的。我们前面曾指出，你可以利用上下文模型中的数据流，来决定需求是否超出范围。同时，你也应该确保每项需求都包含有效的顾客满意度/不满意度评分。这些评分告诉你，顾客认为该需求具有的价值。如果评分高，那么蔓延的需求也许可以容忍(伴随着预算的调整)。
需求所附的理由必须有意义，因为通常蔓延的需求的理由会表明，该需求超出了范围。在本章早些时候我们提到了需求的相关性，以及需求必须怎样与产品的目标相关，并在工作的范围之内。如果需求蔓延到范围之外，或与产品的目标无关，那么我们建议你认真地考虑一下。范围是否正确?产品的目标正确吗?符合实际吗?我们建议你仔细找出需求蔓延的根源。也许范围在一开始就设错了，也许范围应该变更(与业务利益相关者商议，并对预算进行合适的调整)。图13-5展示了需求蔓延的影响，其中展示了提交功能的成本。看看产品的规模增加35%时会发生什么:需要增加的工作量超过35%，而这一部分在某些人看来应该是免费的。如果需求的增长超过了最初的期望，预算必须成比例地增加。但你是否常常听到:"只是再加一点点，不会影响到预算吧?"
需求蔓延的名声不好，主要是因为它打乱了开发进度，增加了因此而导致的提交产品的成本。不是为需求蔓延辩解，我们确实认为查看导致蔓延的原因，并讨论如何处理这个问题，是一种审慎的做法。
首先，大多数需求蔓延都是因为一开始就没有正确地收集需求。如果需求不完整，那么随着产品开发的进行，越来越多的原来忽略的东西就需要发现。用户意识到产品的提交就在眼前，开始要求越来越多的"新"功能。但它们真的是新功能吗?我们认为它们实际上从来就是产品的部分。只是到目前为止，还没有纳入需求规格说明。
大多数的需求蔓延都是因为一开始就没有正确地收集需求。
类似地，如果用户和客户没有机会完整地参与需求过程，那么毫无疑问，需求将是不完整的。几乎可以肯定，当提交日期临近时，需求会蔓延，用户开始要求那些他们知道需要的功能。我们也观察到蔓延产生的一个原因是最初的预算太低，不符合实际情况(出于政策上的原因)。当难以置信的显著蔓延发生时，问题已不再是需求蔓延，而是产品能否正确地实现其功能。需求也会变更。通常它们的更改有个很好的理由:业务变了，或者新的技术进步让大家期望变更。这类变更常常被视为需求蔓延。实际上，如果变更导致正式需求过程"结束"后产生新的需求(它们不能事先预见)，那么这类需求蔓延就是不可避免的。
在这种情况下，质量关的职责是让项目管理层意识到需求蔓延正在发生，如果可能，帮助确定蔓延的原因。