以下是一份問題列表，優秀的架構應該關注這些問題。這張覈對表的意圖並非用做一份有關如何做架構的完全指南，而是作爲一種實用的評估手段，用來評估軟件食物鏈到了程序員這一頭還有多少營養成分。這張覈對表可用做你自己的覈對表的出發點。就像“需求”的覈對表一樣，如果你從事的是非正式項目，那麼你會發現其中某些條款甚至都不用去想。如果你從事的是更大型的項目，那麼大多數條款都會是很有用的。
針對各架構主題
q 程序的整體組織結構是否清晰？是否包含一個良好的架構全局觀（及其理由）？
q 是否明確定義了主要的構造塊（包括每個構造塊的職責範圍及與其他構造塊的接口）？
q 是否明顯涵蓋了“需求”中列出的所有功能（每個功能對應的構造塊不太多也不太少）？
q 是否描述並論證了那些最關鍵的類？
q 是否描述並論證了數據設計？
q 是否詳細定義了數據庫的組織結構和內容？
q 是否指出了所用關鍵的業務規則，並描述其對系統的影響？
q 是否描述了用戶界面設計的策略？
q 是否將用戶界面模塊化，使界面的變更不會影響程序其餘部分？
q 是否描述並論證了處理I/O的策略？
q 是否估算了稀缺資源（如線程、數據庫連接、句柄、網絡帶寬等）的使用量，是否描述並論證了資源管理的策略？
q 是否描述了架構的安全需求？
q 架構是否爲每個類、每個子系統、或每個功能域(functionality area)提出空間與時間預算？
q 架構是否描述瞭如何達到可伸縮性？
q 架構是否關注互操作性？
q 是否描述了國際化/本地化的策略？
q 是否提供了一套內聚的錯誤處理策略？
q 是否規定了容錯的辦法（如果需要）？
q 是否證實了系統各個部分的技術可行性？
q 是否詳細描述了過度工程(overengineering)的方法？
q 是否包含了必要的“買 vs. 造”的決策？
q 架構是否描述瞭如何加工被複用的代碼，使之符合其他架構目標？
q 是否將架構設計得能夠適應很可能出現的變更？
架構的總體質量
q 架構是否解決了全部需求？
q 有沒有哪個部分是“過度架構/overarchitected”或“欠架構/underarchitected”？是否明確宣佈了在這方面的預期指標？
q 整個架構是否在概念上協調一致？
q 頂層設計是否獨立於用作實現它的機器和語言？
q 是否說明了所有主要的決策的動機？
q 你，作爲一名實現該系統的程序員，是否對這個架構感覺良好？
