整體這本書很實際，十年前寫的也不過時。今天所謂好書越來越沒水平，跟時下浮誇之風氣相關吧。

關於分階段，每個階段在多檢視。我覺得做一件事情是要以時間軸來看。更廣泛一點，應該是主題來看。一個主題，我們可以有多種視角。拿時間來說，我們確實會分步驟去做長期的實施計劃。

關於二維需求矩陣。一個維度是功能質量約束，沒啥問題。但另外一個維度是說組織、使用者和開發，這裡問題比較大，因為從理論上來說，我們應該考慮涉眾及其利益，包括boss、客戶、使用者等。研發是一個過程，他卻把裡面的很多點都放進去了，涉及軟體工程。維度不怎麼合理、差一點理論。我覺得他把組織和使用者分開適合面向網際網路to c的場景。好比一端是商戶的需求，一端是使用者的需求。目標和涉眾，應該是更科學的劃分。

關於魯棒圖。他彌補了從用例到互動圖之間的缺失。互動圖非常的複雜，因為它會有很多場景，是一個非常重的圖，我不建議用在常規的設計裡面，除非是一些核心的互動場景，而且是那些不易經常發生變化的。魯班圖可以識別出來物件和過程，相當於把用例更細化掉。後面可以做做推廣實踐。他定性成系統的初步設計，沒啥問題。

關於用例架構驅動還是概念架構驅動。此文說，概念架構的驅動力，等於功能、質量、約束。但實際從軟體的根本目標來講，都服務於使用者和商業價值。軟體本身也可是一種商業，但這比較特殊。所以核心用例驅動，這句話沒啥毛病，他雖然不是一個很全的覆蓋面，但是他把軟體的本質體現出來了。

如果求全我們可以說，是需功能需求和非功能需求驅動。但本質並不對，很有可能很多功能需求，很是很傻逼的產品經理提出來的，並不代表著市場的認可。需求是偽需求，那根據偽需求構建的系統也是偽系統，所以，真正是市場驅動著軟體的一個架構。

關於概念架構和方案的區別。概念架構他關注抽象的部分，它沒有介面約定和子系統間的互動。方案更偏內容層面。

關於邏輯架構的分層、分割槽和機制。主要關於機制，他的定義是為了完成某一目標、基於抽象角色的協作方式和流程。可以理解為是基於角色和USECASE的功能流程。有兩個關鍵詞，一個是角色，另外一個是流程。