3.10 確定系統需求
確定系統需求即確定系統用例。方法以根據業務用例實現場景分析為輸入，分析每個系統Actor的系統用例。每個系統用例一定是一個完整的事件流，注意業務用例和系統用例的區別，業務用例是一個完整的業務目標，而系統用例是一個完整的事件流，是業務目標中的一個環節，如客戶代表申請開戶是一個完整的系統用例，但不是一個完整的業務目標，其包括多個頁面操作。
3.11 用例實現分析
對每個系統用例，識別其可能的實現路徑，每個實現路徑就是一個用例實現，然后針對每個用例實現，分析人機交互，使用活動圖繪制用例實現場景。
3.12 分析模型
使用分析對象，實現所有的用例實現場景，識別出三種分析對象。在這個過程中，也可以建立界面原型，和客戶進一步達成需求的一致理解。分析模型是需求到設計的橋梁，分析類的層次高于設計實現，需求通過分析類轉成計算機語言。后續做系統設計的時候，可直接將分析模型轉換成設計模型。
在考慮分析模型的過程中，有可能識別出一些公共模塊，比如開戶、銷戶過程中都會有一些業務規則校驗，需要引入規則引擎的支持，那么類似規則引擎這樣的公共模塊需要添加到邏輯架構中去。
3.13 非功能性需求設計
以性能為例講一下對非功能性需求設計的過程。
1、確定性能目標：要支持多少用戶、多少在線用戶、多少并發操作、操作響應時間要求等；
2、以一個簡單的三層架構為起點，根據性能目標，識別瓶頸。比如，如果數據庫撐不住，那么需要考慮最佳的分庫設計，如果是邏輯層撐不住，則要考慮負荷分擔，狀態同步的邏輯層方案設計，如果操作響應時間要求很高，則可根據不同場景，分析其操作的數據的讀寫特點，采用合適的緩存方案。如要支撐高并發低時延的大數據量查詢，Twitter就采用了垂直緩存，raw緩存的設計方案。
3、驗證性能設計。抽取典型場景，實現一個prototype來驗證性能設計是否滿足性能目標。
在質量屬性設計中，如果需要新增模塊，則需要修改邏輯架構。
有一些約束類需求也是非常重要的，不能遺漏分析。
經過這一個階段，我們能夠得到一個比較完整的邏輯架構，運行架構、開發架構、物理架構、數據架構的輸入了。剩下的工作就是編檔的工作了。
3.14 架構編檔
有了上面的工作作為鋪墊，編檔就非常容易了，這個就不細講了。