《一線架構師實踐指南》讀後感(四)
什麼是Pre-architecture
- Pre-architecture就是架構設計的最前期階段，其工作目標包括：理解需求、建立需求大局觀、確定架構設計方向等
實際意義
需求理解的大局觀
- 有效處理互相矛盾的需求目標
- 識別重大需求、特色需求、高風險需求
- 相對短的時間內設計架構
降低架構失敗風險
- 架構師在需求的理解、權衡、取捨和補充這些方面能力嚴重不足。
儘早開始架構設計
Pre-architecture階段的好處：能夠在需求沒有“全面完成”的情況下開始架構設計。
爲了儘早開始架構設計，需要做好：讓架構師參與需求分析工作；不能被動地等待完善的《軟件需求規則說明書》出現的那一刻。
只要滿足下面3個條件就可以開始架構設計工作：
1.有了明確的業務需求：必須保證甲、乙雙方就建設系統的目標達成共識，《願景文檔》經過正式評審，並且明確了投資、工期標準、整合等約束條件；
2.瞭解全面的用戶需求：系統能幫助用戶幹什麼、不能幹什麼已經非常明確。如果採用用例技術，表現爲“用例圖”比較完善，沒明顯遺漏；
3.有了典型的行爲需求；如果採用用例技術，表現爲核心功能的《用例約束》已經定義；
明確架構設計的“驅動力”
除了需要關注《軟件需求規格說明書》之外，必須關注其他很多因素，最終理性地確定真正的架構設計“驅動力”。
實踐要領
不同需求影響架構的不同原理，纔是架構設計思維的基礎
“需求決定架構”是對的，但不同需求影響架構的不同原理，纔是架構設計思維的基礎。
不同需求是如何以不同原理影響架構設計：
二維需求觀與ADMEMS矩陣方法
ADMEM方法提倡的“二維需求觀
觀念是行爲的嚮導，有怎樣的觀念存在，就有怎樣的行爲方式產生。
關鍵需求決定架構，其餘需求驗證架構
關鍵需求決定架構：功能需求做減法；質量屬性需求做加飯；約束性需求做加法；
需求結構化
需求結構化可以將複雜的需求集合梳理得井井有條，爲進一步分析不同需求之間的聯繫、識別遺漏的重要需求打下堅實的基礎。
需求如何結構化
-
1.超越《軟件需求規則說明書》
需求文檔往往不夠全面；
需求經常變更，僅依賴需求文檔往往使架構設計工作非常被動；
架構師通過需求結構化真正全面地“鳥瞰”需求大局，就必須超越《軟件需求規則說明書》；
能夠擺脫對《軟件需求規則說明書》提交時間、文檔質量、內容變更的“呆板依賴”； -
2.ADMEMS矩陣
業務級需求：包含客戶或出資者要達到的業務目標、預期投資、工期要求，以及要符合哪些標準、對哪些遺留系統進行整合等約束條件。
用戶級需求：用戶使用系統來輔助完成哪些工作？對質量有何要求？用戶羣及所處的使用環境方面有何特殊要求？
開發級需求：開發人員需要實現什麼？開發期間、維護期間有何質量考慮？開發團隊的哪些情況會反過來影響架構？需求還要從下面3個方面考慮：
功能需求：更多體現各級直接目標要求。
質量屬性：運行期質量 + 開發期質量。
約束需求：業務環境因素 + 使用環境因素 + 構建環境因素 + 技術環境因素