文章洋洋灑灑，拋開自己已經懂得的，再拋開過於高深的（很多東西看懂了不代表得到了），剩下自己有心得的（往往是跟自己經歷相關的），也就剩下用熒光筆標註出來的幾句話了，但也足夠了。
架構設計對系統成敗非常關鍵，那麼什麼對架構設計成敗非常關鍵呢？
功能需求、質量屬性、以及約束共同決定了架構（圖1），對這三類需求的把握是否到位、設計決策是否合理，可以說是架構設計成敗的關鍵所在。
質量屬性和約束，同屬非功能需求，都是重要的“架構決定因素”。質量屬性是軟件系統的整體質量品質——所謂整體品質，就是它往往和大多數功能都有關，而不是僅僅表現在某個功能“內部”。
至於約束性需求，它們要麼是架構設計中必須遵循的限制，要麼經過約束分析、轉化爲質量屬性需求或者功能需求。但是，約束分析沒有受到架構師的普遍重視，於是約束背後的“衍生需求”變成了“遺漏需求”，造成了架構設計的偏離甚至失敗。
約束是最危險的需求
功能需求、質量屬性、約束這三類需求，其“危險性”各有不同。
功能需求是需求變更的主要來源。一刀切地認爲“需求變更無處不在”並不正確，也對實踐有害（失去了把握較穩定需求的機會）。質量屬性需求最爲穩定，如多年以來，銀行系統總是對安全性、持續可用性要求很高。而約束性需求也相對穩定，技術趨勢發生變化、法律法規重新界定、用戶組織調整改組等，可能使約束性需求變更。
質量屬性往往是架構設計的難點所在。例如，爲了滿足高性能要求，必須考慮外部及內部不同因素、在各種情況下、對系統不同部分的影響。另外，不同質量屬性之間往往相互影響，筆者在《軟件架構設計》一書中歸納了其中規律:可重用性、可擴展性等開發期質量屬性之間往往是相互促進的;性能和安全性與其他質量屬性常有矛盾……
但是，不知道危險何在，纔是最危險的！
一方面，質量屬性“難”也好，功能需求“變”也罷，這些已爲越來越多的人所認識，但對約束當前較爲普遍的看法依然是“直接遵守即可”，這是危險的。Mike Dyer最早指出，從需求轉入設計時，會激增出大量衍生需求。約束性需求背後就包含許多衍生需求，“約束直接遵守即可”的觀點就像“一葉障目”的那片樹葉，讓架構師忘了約束分析的必要性。
另一方面，我們往往僅關注來自甲方的、位於技術層面的約束，這很危險。有與遺留系統集成的要求嗎？行業趨勢有何新的動向？……這些深刻影響架構的約束雖來自甲方，但都是非技術約束。乙方自身的技術水平如何？產品在整個產品路線圖中的什麼位置？……乙方約束，對架構設計亦影響重大！
看來，對架構師而言，最“危險”的需求非約束莫屬。
對待約束的三種境界
境界一是“守”。既然書上說，“約束直接遵守即可”，那在架構設計中就不去費腦子分析約束，這種做法就是第一種境界。
境界二是“破”。盡信書不如無書，越來越多的架構師已經注意到了技術性約束、標準性約束、法律法規性約束等的不同之處，懂得分析約束直接遵守即可、還是會造成間接影響。例如，“必須基於J2EE平臺”是條可直接遵守的約束，但“執行現行利率”這條法規性約束卻牽扯出諸多功能、及質量考慮。
境界三是“離”。在架構師看來，所有影響架構設計的因素都是需求，只不過需求類型不盡相同罷了。所以，不僅技術方面會有約束，業務方面也會有約束。約束不僅來自於我們經常注意到的甲方，也來自於乙方自身……
外界（甲方）因素是一種約束條件，自身（乙方）能力也是一種約束條件。
守，意味着學習，照本宣科;
破，意味着突破，開始思考;
離，意味着創造，面向實踐。
實踐者自然崇尚“破”和“離”的境界，接下來的兩節，分享一些筆者的實際經驗。
正交表作爲思維工具
實踐中，我們可以用一個3×3的表格，來輔助全面理解需求、把握需求脈絡、發現需求衝突、特別是分析約束背後的衍生需求。我把這種方法叫作“正交表”（圖2）。
正交表的“行”代表需求的層次。一個成功的軟件系統，對客戶高層而言能夠幫助組織達到業務目標，這些目標就是客戶高層眼中的需求;對實際使用系統的最終用戶而言，系統提供的能力能夠輔助他們完成日常工作，這些能力就是最終用戶眼中的需求;對開發者而言，有着更多用戶沒有覺察到的“需求”要實現……
正交表的“列”代表需求的類型。例如，一個網上書店系統的功能需求可能包括“瀏覽書目”、“下訂單”、“跟蹤訂單狀態”、“爲書籍打分”等，質量屬性需求包括“互操作性”和“安全性”等，而“必須運行於Linux平臺之上”屬於約束性需求之列。實踐一再表明，忽視質量屬性和約束性需求，常常導致架構設計最終失敗。
值得注意的是，正交表的“約束”列縱穿了組織、用戶、開發三級需求層次，這恰是正交表方法的特點所在，體現了“約束來自甲方也來自乙方”的思想。
首先，是組織級約束，例如行業標準、法律法規所約束的對象一般爲組織。其次，是用戶級約束，例如軟件的最終用戶是老人還是年輕人、是商務人士還是電腦水平較低的人，都會使得架構在易用性、魯棒性方面有不同考慮。最終，乙方也有影響架構設計的約束，例如團隊技術水平較低的話，架構師就要慎重選擇較難掌握的技術。
架構設計中的約束分析
從需求轉入設計時，有經驗的架構師非常重視衍生需求對架構設計的影響，特別是針對約束、進行約束分析、發現約束背後隱藏的衍生需求。
總體而言，約束分析就是要區分約束影響設計的三種不同途徑，並藉助正交表方法把衍生需求找出來（結合圖3示例進行說明）:
●直接制約設計決策的約束。例如，“系統運行於Unix平臺之上”作爲一條約束，架構師直接遵守即可。
●轉化爲功能需求的約束。例如，“本銀行系統必須嚴格執行人行統一規定的利率”是一條約束，但分析後發現，正是它引出了一條功能需求:即必須提供調整利率設置的實用功能。
●轉化爲質量屬性需求的約束。例如，有經驗的系統分析員發現了一條重要約束:“任職於各儲蓄所和分理處的櫃員，計算機水平普遍不高”。由此，未來的軟件系統必須具有很高的易用性（否則不會用）和魯棒性（否則將導致系統癱瘓）。
所謂風險？風險是“你忘了它，它就會找上門來”的一類東西。所以，付諸實踐而言，千萬不要忘了架構設計中的約束分析環節。
圖1功能需求、質量屬性、以及約束共同決定了架構
圖2 正交表幫助把握需求脈絡、進行約束分析
圖3 銀行系統:約束分析示例