在现实设计中，通过变化分析可以激发客户潜藏的需求？下面看一个例子。
一个美国某国际电子商务公司的订单处理系统。假设系统必须能够处理来自不同的国家（地区）的销售订单。最开始要求很简单：处理美国和加拿大的订单。
系统的需求清单如下：
- 要为加拿大和美国构建一个销售订单系统。
- 根据所在国家计算运费。
- 运费还应该以所在国家（地区）的货币支付。
- 在美国，税额应按当地计算。
- 使用美国邮政规则验证地址。
在加拿大，使用联邦快递发货，同时缴纳联邦政府销售税（GST）和地方销售税（PST）。尽管这个需求已经很清楚，但我们必须通过分析使这个需求变得清晰，分析：这个问题中存在的变化并不太复杂。光凭观察，就可以显而易见得到下面的表。
这是一个简单的问题，但是我们希望用这个简单的背景来说明分析矩阵的分析过程，而不希望把精力过多地放在案例的背景上。
在填写分析矩阵中进行分析
让我们从观察一种情况开始。首先观察必须实现的每个功能，并标记它所表示的概念。
当然，事情并非总是如此顺利。新情况往往会带来新功能。但是这是好事情。这样我们就能够有机会检验分析的完整性。
在分析过程中寻找不完整和不一致
随着时间流逝，我们总是需要处理新的情况（例如业务扩展到了德国）。当你发现了某种情况中存在一个新概念时，就扩展分析矩阵，在矩阵中增加一行，即使它并不适用于其他情况。
美国和加拿大有最大重量吗？可能没有，也可能有，但是客户忘了提到这一点。现在，有一个很好的具体问题要问了。我的客户对于回答具体问题是非常擅长的，而对于“还有别的什么吗？”这样的问题，他们一般并不擅长。
子矩阵
有时候一个简单的矩阵往往是不够的，即使在这个简单案例中，也很容易想像，如果一个国家（地区）中有超过一种货运方式会变成什么样子。这就可以在主矩阵中再加入子矩阵，下图给出了这个例子。
还要注意到另外一种变化：由于美国、加拿大、德国这些地域的变化，会成组的使用不同对象。这就需要确定在什么情况下使用哪一组对象是相同的。
具体的是提供一个接口，来创建一组相关或相互依赖的对象，但无需指定它们的具体类是什么，这种设计策略可以给它起个名字：Abstract Factory（抽象工厂，AF）。
这样一来，就得到了一个初始的高层设计，如下图所示。
如果这种解决问题的设计方案被证明是有效的，就可以把它记录下来，并赋予一个唯一的名称，这就成为模式，成为组织的智力资产。