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