在需求采集結束后，就進入了一個相對重要的環節：問題分析。
1.問題與客戶達成共識
這個共識有簽字式的——協議，也有非簽字式的——確認。
記住，所有的共識都基于雙方的理解。文字的東西往往會引起歧義，電話確認又往往失于嚴肅。圖形化的方法可以彌補這些缺憾。個人經驗，文字的描述比較適用于
早起的問題收集，或者是簡單的問題確認。復雜的問題需要交給圖形化來解決，wireframe——虛擬界面，是個不錯的選擇。它除了可以收集輸入輸出數據
項，還可以給客戶一個比較直觀的感覺。當然，這個也相對費時一些。但對于需求的確認至關重要，可以減少客戶與軟件人員的誤解。
2.找出問題背后的發生原因
韋伯說過，社會行為是行動者賦予主觀意義的人類行為。任何人（團體、組織）的活動在社會中都會牽涉到另一個人（團體、組織）。任何行為本身都具有意義，如
無意義，則無行為。
扯遠了，還是談談需求問題。客戶問題的提出，是為了解決問題。要想解決問題，就必需知道問題是如何產生的。也就是說，要想找到蛋，就必需先找到下蛋的雞，
研究它的活動軌跡，最后定位雞蛋的位置——解決問題。在社會學里，找到了行為的意義，也就掌握了行為本身。記住，無意義就無行為，有行為則必有意義。
3.確定系統用戶
包括用戶的角色和權限。這是系統能夠運行起來的基本條件。如果不能引起足夠的重視，對于系統將是嚴重的災難。筆者曾做過一個office
resource
management系統，從初始的一個角色對應一個office,到一個role對應多個office,一個人一個角色，到一個人多個角色。修改之多，
之繁重，不能與人言。
4.確定系統邊界
在實踐過程中，個人引入了"內外表"來定義系統邊界。這個在稍后的usecase中具體描述
5.劃分子系統的三個原則：
a.職責不同的功能劃歸不同子系統：將一類包含統一職責的功能劃分為一個子系統。如權限管理系統與業務系統分離。（企業系統需要統一的權限管理：安全認證
以及系統授權），再如社會保障信息系統按業務類別的劃分：養老，醫療，工傷，失業，生育。按照業務規則劃分又可以分為：公共業務（單位，個人），待遇，報
表
b.需要不同開發技能的單元劃歸不同子系統:如報表系統與數據倉庫的獨立開發。
C.軟件工程管理的劃分：
1)兼顧工作量的相對均衡，進一步切分太大的子系統。交給不同的team進行并行開發。
2)同一類公用\復用模塊劃分為一個子系統：如規則引擎，簡單報表，css
theme管理，數據同步\交換，基礎平臺的二次開發(統一彈出式查詢,輸入校驗,頁面組件)等等。