到目前為止，我們已經完成了需求的分析過程，總結來說，主要的步聚是
一）需求結構化，
二）分析約束影響
三）重點關注質量需求。
那麼接下來的階段則是系統的概念架構了，這也許是大家最感興趣的話題，前面提到系統的多層架構，各層之間相互隔離，下層提供服務而不知道上層應用，上層也只通過介面與下層互動，每一層的修改均不會影響其它層的邏輯，看上去有多華麗就有多華麗！
但是真正開始系統架構時，卻有無從下手無力感，為啥？因為你注意到軟體的概念架構最主要的任務就是將系統按照某作規則劃分成各種子系統，確定各子系統之間的協作，為下一階段的細化設計奠定基礎。
系統劃分的規則主要有三類：
1：按邏輯分割
2：按物理部署分割
3：按通用性分割
而三層架構也正是按邏輯分割的體現。
簡單地說，要對系統進行分割，我們必須明確系統有哪些職責，在明確職責之後，再將相似或相近的劃分至各層中。
在需求分析階段我們了解了系統需要實現的功能，但僅基於此，卻難以支撐我們確定職責。在需求用例與功能職責之間還需要一座橋，那就是魯棒圖。
如前文提到的檢視簽到記錄用例，通過繪製魯棒圖，我們發現了很多用例中沒有體現的物件及相互之間的互動。系統分割正是基於此時發現的職責來進行割分的。
如何開展軟體架構之需求分析2
前面提到，在需求分析階段，架構師的兩個重要的工作步聚為 1 結構化需求 2 分析約束影響 以上兩個步聚都是為了解各需求之間的聯絡，發現隱藏需求而服務，相對的從業務需求到用 戶需求的分析，再到開發需求的分析，一般不太容易遺漏需求，而平時較少考慮的則是由於 約束產生的設計或功能或質量需求。a 業務環境 ...
如何開展軟體架構之需求分析3
前面提到在需求分析過程中，需要將需求結構化，然後依據該需求矩陣，通過推薦需求，分析約束來分析隱藏需求。現在我們來看乙個具體的例子 如下圖1所示 圖1 其上圖中，顏色相同且之間有聯線的，表示是兩者之間有相互的制約關係。比如，1 對於網際網路這麼乙個業務環境，必然會有很多的殭屍使用者，考慮資料庫容量有效...
如何開展軟體架構之需求分析3
前面提到在需求分析過程中，需要將需求結構化，然後依據該需求矩陣，通過推薦需求，分析約束來分析隱藏需求。現在我們來看乙個具體的例子 如下圖1所示 圖1其上圖中，顏色相同且之間有聯線的，表示是兩者之間有相互的制約關係。比如，1 對於網際網路這麼乙個業務環境，必然會有很多的殭屍使用者，考慮資料庫容量有效，...