在現實設計中，通過變化分析可以激發客戶潛藏的需求？下面看一個例子。

一個美國某國際電子商務公司的訂單處理系統。假設系統必須能夠處理來自不同的國家（地區）的銷售訂單。最開始要求很簡單：處理美國和加拿大的訂單。

系統的需求清單如下：

• 要為加拿大和美國構建一個銷售訂單系統。

• 根據所在國家計算運費。

• 運費還應該以所在國家（地區）的貨幣支付。

• 在美國，稅額應按當地計算。

• 使用美國郵政規則驗證地址。

在加拿大，使用聯邦快遞發貨，同時繳納聯邦政府銷售稅（GST）和地方銷售稅（PST）。盡管這個需求已經很清楚，但我們必須通過分析使這個需求變得清晰，分析：這個問題中存在的變化並不太復雜。光憑觀察，就可以顯而易見得到下面的表。

這是一個簡單的問題，但是我們希望用這個簡單的背景來說明分析矩陣的分析過程，而不希望把精力過多地放在案例的背景上。

在填寫分析矩陣中進行分析

讓我們從觀察一種情況開始。首先觀察必須實現的每個功能，並標記它所表示的概念。

當然，事情並非總是如此順利。新情況往往會帶來新功能。但是這是好事情。這樣我們就能夠有機會檢驗分析的完整性。

在分析過程中尋找不完整和不一致

隨著時間流逝，我們總是需要處理新的情況（例如業務擴展到了德國）。當你發現了某種情況中存在一個新概念時，就擴展分析矩陣，在矩陣中增加一行，即使它並不適用於其他情況。

美國和加拿大有最大重量嗎？可能沒有，也可能有，但是客戶忘了提到這一點。現在，有一個很好的具體問題要問了。我的客戶對於回答具體問題是非常擅長的，而對於“還有別的什麽嗎？”這樣的問題，他們一般並不擅長。

子矩陣

有時候一個簡單的矩陣往往是不夠的，即使在這個簡單案例中，也很容易想像，如果一個國家（地區）中有超過一種貨運方式會變成什麽樣子。這就可以在主矩陣中再加入子矩陣，下圖給出了這個例子。

還要註意到另外一種變化：由於美國、加拿大、德國這些地域的變化，會成組的使用不同對象。這就需要確定在什麽情況下使用哪一組對象是相同的。

具體的是提供一個接口，來創建一組相關或相互依賴的對象，但無需指定它們的具體類是什麽，這種設計策略可以給它起個名字：Abstract Factory（抽象工廠，AF）。

這樣一來，就得到了一個初始的高層設計，如下圖所示。

如果這種解決問題的設計方案被證明是有效的，就可以把它記錄下來，並賦予一個唯一的名稱，這就成為模式，成為組織的智力資產。

本文出自 “中科院計算所培訓” 博客，謝絕轉載！

系統架構培訓：矩陣，封裝，一個案例教你激發客戶潛藏的需求！