假設說我們今天開發的是一個POS系統。在開發的時候，我們針對POS產品類別，保留了一個彈性：「可以很輕意的增加產品類別」。所以未來我們可以很簡單的新增一個產品類別。不過這裡有一個地方要注意。
這裡有一個前提假設： 「每個產品類別，其他的流程是一樣的」。如果接下來一些銷售流程不儘相同，或是相關的擴充彈性沒有一起保留下來，倒不如在未來真的增加產品類別時，再一併增加，以免在目前的架構下，多了許多無意義或是令人困惑的程式碼。
其實不只是這個假設；你需要brain storm看看是否還有其他隱含假設。這些隱含假設來自於每個人不同的經驗。當然，需要保留多少彈性，這永遠是一個tradeoff 的問題。你需要考慮時間成本、研發人力、系統複雜度blabla。需要保留什麼樣的彈性這是一個經驗的問題。像上面所舉的「增加產品類別」，需要看系統中，所謂的「類別」是怎麼定義法。舉例來說，書店增加一類書是很容易的，但是增加書以外的產品類別比方說滑鼠，可能就沒那麼隨隨便便可以增加(雖然說最近有越來越多的書局開始兼賣滑鼠是怎樣…？)，因此像這類的彈性，如果在成本、人力都很吃緊的情況下，可以選擇性放棄這樣的彈性。
