看到本書第十三章發現，需求不應該決定架構，我心想：what？架構不就是要根據使用者需求來確定的嗎。再往下看，原來是關鍵需求決定軟體架構。
究其原因也很好理解，在實際軟體開發中，不是像大學裡這種「實驗室**」，軟體架構師沒有時間對『所有需求』進行深入分析，這既是策略，也是現實，當然這對於我以後走向社會提供了很大幫助，轉化了一種思路。俗話說，事無鉅細，但這在軟體架構設計階段並不適用，姑且不論使用者的需求經常變化，反覆無常，要想兼顧所有的需求那是不可能的，所以確定關鍵需求至關重要。
結合課上所學知識，相互印證，一般可以從功能需求、質量需求和商業需求三方面來進行分類。任何功能需求，都是由一條特定的『模組協作鏈』完成的。
一方面，不同質量屬性之間往往具有相互制約性，於是我們自然應該權衡哪一部分質量屬性是架構設計的重點目標。另一方面，功能需求數量眾多，應該控制架構設計時需要詳細分析的功能（或用例）的個數。
可通過如下4條啟發規則，確定關鍵功能子集：
核心功能
必做功能
高風險功能
獨特功能（覆蓋了上述3類功能沒有設計的職責）
只要能較好地覆蓋組成架構的不同職責模組，並體現職責模組之間協作關係的特點，那麼「關鍵功能子集」的價值也就體現出來了。
為什麼架構師的經驗很重要呢，確定「關鍵需求」靠的就是經驗，目的是用有限的時間針對關鍵需求把設計做到位、並減小需求變更對架構設計的影響。
這也就是為什麼軟體架構師比較難做，做好就更不用說了，你既要有多年的軟體開發而經驗，也就是心中有「貨」，又要當機立亂，不能猶豫，確定出本軟體最核心的功能是什麼，就像硬碟一樣，要求讀取速度快，就不能要求磁碟利用率高；要保證充分利用磁碟，節省空間，就無法注重讀取速度，所以要學會取捨。
《軟體架構設計》溫昱著讀後感（一）
弄懂了2個關鍵概念，如下 啥是軟體架構 software architecture 軟體架構是指在一定的設計原則基礎上，從不同角度對組成系統的各部分進行搭配和安排，形成系統的多個結構而組成架構，它包括該系統的各個元件，元件的外部可見屬性及元件之間的相互關係。元件的外部可見屬性是指其他元件對該元件所做...
架構實戰 軟體架構設計的過程讀後感（三）
本書第五張主要講述了 可重用架構資源 由於我參與開發實際專案並不多，所以對軟體重用體會和理解並不是很深，故查閱了相關資料，結合書上的敘述和例子，有了乙個巨集觀的了解。乙個可重用資源可以代表乙個可重用需求 在不同系統裡反覆出現的需求 可重用的解決方案元素 乙個架構模式或者可重用 可重用測試 可重用的方...
軟體架構實踐讀後感三
軟體架構實踐讀後感三 問題，在過去的學習中我並沒有注意到分析架構這個問題，直到我閱讀了這本書，我才真正接觸並理解了軟體架構中還有分析架構這一階段，閱讀中我了解了架構並不是單獨存在的，而是在某個週期的一部分。構架是實現某個目的的手段，他受到系統涉眾的影響，也受到客戶和開發組織的功能及質量目標的影響，還...