肯定關鍵需求，架構師具體要作什麼呢？
· 一方面，不一樣質量屬性之間每每具備相互制約性，因而咱們天然應該權衡哪一部分質量屬性是架構設計的重點目標。
· 另外一方面，功能需求數量衆多，應該控制架構設計時須要詳細分析的功能（或用例）的個數。數據庫
1 肯定關鍵質量
爲了肯定對架構設計關鍵的質量屬性需求，須要作以下三方面的工做：
· 考慮爲了提升要開發的軟件系統受承認的程度，應着重提升哪些方面的質量屬性要求；
· 接下來，充分考慮這些質量屬性的相互制約或相互促進關係，以調整不一樣質量屬性的要求標準——例如，你可能會決定高性能要求最最重要，而可擴展性也比較重要；
· 同時，必須知足各類約束性需求。
肯定關鍵質量時考慮質量屬性之間的矛盾關係，例如，「互操做性」需求每每給「安全性」需求形成威脅，而爲了知足「高性能」需求，每每須要使用特定平臺的非標準能力，這勢必影響了系統的「可移植性」，……，不一而足。因而，咱們天然應該權衡哪一部分質量屬性是架構設計的重點目標。安全
2 肯定關鍵功能
功能需求是你們最熟悉的一種需求。Karl E. Wiegers在《軟件需求（第2版）》中這樣描述它：服務器
功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，知足業務需求。功能需求有時也被稱做行爲需求（Behavioral Requirement），由於習慣上老是用「應該」對其進行描述：「系統應該發送電子郵件來通知用戶已接受其預約」。架構
而所謂對軟件架構關鍵的功能需求，就是它涉及（或串起）的模塊最多、協做方式最有表明性的功能需求。
任何功能需求，都是由一條特定的「模塊協做鏈」完成的。控制權在模塊協做鏈中來回傳遞，而功能需求就至關於串起不一樣模塊的線索
如何肯定關鍵功能需求呢？可經過以下4條啓發規則，肯定關鍵功能子集：
· 核心功能。
· 必作功能。
· 高風險功能。
· 獨特功能（覆蓋了上述3類功能沒有涉及的職責）。性能
核心功能。識別「核心功能」，有個標誌：業務層的接口要反映這些功能。例如，項目管理系統中，項目信息查看、添加項目任務等都是核心功能。ui
必作功能。識別「必須實現的功能」主要依據客戶方的背景。架構師不該忽視系統的《願景與範圍文檔》，這份文檔描述了項目立項的真正源起，文檔「項目願景的解決方案」中「主要特徵」每每應做爲「必作功能」的備選項。另外，對於業務系統而言，通常支持「運營」的功能比支持「管理」的功能優先級要高。spa
高風險功能。基於務實考慮，還應該把「風險高的功能」選入關鍵功能子集。架構設計
例如，你在設計一個網上書店系統，書籍的全庫搜索功能就須要特別關注：
· 從用戶角度講，極慢的搜索速度、甚至直接收到「系統忙，請稍後再試」的提示，都是使人不滿的；
· 從架構設計角度講，此功能對書籍數據庫進行「面狀、只讀」式的使用，和增長書籍、修改書籍信息等功能「點狀、寫入」式的數據庫使用特色徹底不一樣……儘早將全庫搜索功能選入「高風險功能」之列，利於有針對性地進行架構設計。設計
獨特功能。最後，看看仍是否覆蓋了「上述3類功能沒有涉及的職責」的功能。例如，若是你設計相似「搜狗拼音」這樣的輸入法軟件，「詞庫在線更新」功能就必然是對架構關鍵的功能，由於忽略了它就很難發現架構中負責和服務器交互的「互操做模塊」。顯然，「特殊功能」是相對上述3類功能而言的。接口
另外，架構師在肯定關鍵功能子集時，還必須注意兩點。
第一，「關鍵功能子集」的肯定並不存在「標準答案」。只要能較好地覆蓋組成架構的不一樣職責模塊，並體現職責模塊之間協做關係的特色（有經驗的架構師不會放事後者），那麼「關鍵功能子集」的價值也就體現了。
第二，值得專門說明的還有「關鍵功能所佔比例」的問題。有些專家認爲比例大體是固定的，例如，Per Kroll和Philippe Kruchten在《Rational統一過程：實踐者指南》中寫道：
在初始階段，應該肯定出一些（大概佔總數的20%至30%）對系統起關鍵做用的用例。這些用例一般對建立架構具備重要影響。
參考：溫昱《軟件架構設計》