作者：安德鲁 ·马丁，牛津创意出版社

首先，我们将用它来帮助人们理解情况，或者更具体地说，了解需求变更的来源的范围。在我们充分利用九个盒子之前，我们必须首先调整轴 以反映我们感兴趣的情况

案例：需求变化。

对于时间轴，我们考虑三个不同的时期，其中需求变化可以发生

Ø 预设计 (包括传统的需求捕获阶段)

Ø 设计/实施阶段 (系统正在设计和实施阶段)

Ø 交付后阶段 (在系统已部署和正在使用期间)

我们现在可以填充我们的9个盒子，依次考虑每个盒子，并使用它来收集所有符 合“时间”和“空间”相关组合的需求变化的原因。我们包括任何有可能直接和/或 间接地产生变化的东西。

请注意，这里使用的术语“利益相关者”包括所有对该系统感兴趣的个人或机 构——包括用户、购买者、设计师、维护者和其他人员。

例如，我们包括了“利益相关者” (第一个条目，左上角的方框) ，因为他们是 变化的直接来源——有时是由于最初缺乏知识或对他们需求的理解造成的结果。我 们还包括它们，因为它们本身可能会发生变化——这种情况也会导致需求的变化。

完成了九个方框后，我们可以看到有多种可能在整个项目生命周期中导致需求变更的来源和原因。

在任何一个盒子中确定的任何因素都可能发生潜在的变化，从而 对需求产生相应的连锁反应。

毫无疑问，这里所确定的一系列原因并非详尽无遗——但它说明了这个问题的广泛性质。毫不奇怪，超级系统的盒子特别丰富——就像这些东西的方式一样，它们 不仅是数量最多的，而且是我们的影响力和控制最小的。还有一个跨越时间的趋势 ：随着生命周期的进行，可能的需求源的范围会扩大 ( 一般来说，每个阶段都容易 受到为前面阶段确定的所有源的更改的影响， 以及更多阶段) 。

还要注意，我们还包括了诸如“我们不知道的东西”和“糟糕的假设”等 因素。就像完全固定的需求一样，任何对完全理解的需求的期望也是幼稚的。

我们还将许多实施问题作为潜在需求更改。乍一看，这是一个基本问题系统工程的租户是需求和实现，应该分开——混淆两者（非常恰当）被认为是“坏的”这件事”。然而，这里我们关注的是需求的可能来源变化和令人不快的现实是，系统实施经常会影响要求。例如，许多需求规范都是用眼睛写的到可能的艺术。一个不太舒服但实用的例子是无论出于何种原因，项目达到了无法满足原始要求的程度要求。在这种情况下，尽管保留了最初的要求系统的规格可能必须改变——正是这种改变，项目团队将不得不应对。

当我们看到这一分析时，我们可能会开始怀疑任何项目如何能够在这样反复无常的目标面前取得成功。