我們將從客戶調研現場拿回來的需求，經過一番功能角色分析，整個系統的整體脈絡與輪廓已經被勾畫出來。在這個過程中，我們首先將系統劃分成了幾個功能模組（如果系統規模較大，還應先劃分為幾個子系統，然後再劃分出各個功能模組）。然後，我們為每個功能模組繪製用例圖。用例圖是站在使用者角度去觀察的系統，即系統為使用者提供了哪些功能，這就是功能分析。同時，這些功能是為哪些使用者服務的，這就是角色分析。我們繪製的用例圖應當能夠為使用者所理解，這也是uml其中的一項核心思想——與客戶形成統一的、能夠相互理解的語言，這對於需求分析過程中與客戶的溝通是大有好處的。
但形成對系統的整體輪廓，對於軟體的需求分析來說是遠遠不夠的。許多軟體最終失敗的非常重要的原因就是對需求分析過於草率、浮於表面，而沒有深入細緻地去分析，往往到了專案後期才把需求搞懂，才發現真正的需求與起初的認識大相徑庭，才恍然大悟需求原來是這樣，而往往那時已經追悔莫及了。這樣的經歷相信你也有過吧。所以，我們一定要沉下氣來認真仔細地做需求分析，一定要做到位。
同樣，細化需求也需要一定的方法與思路。一般來說，我們可以有兩個方向細化需求：業務流程分析與業務領域分析。這裡，我們先談談業務流程分析吧。
如果我們現在做的需求分析是乙個企業資訊化管理系統，毫不疑問，我們的軟體系統就是在模擬企業已有的那些業務流程。在現實世界中，企業是按照怎樣的流程來管理，我們的軟體就應當去模擬這樣的流程。但是，我們的軟體不可能也不必要完全去模擬這樣的流程，在這個流程中的有些環節是應當由軟體去模擬的，但有些環節則是應當在系統之外，由人工去完成的。我們進行流程分析，就是要求分析哪些是系統之內的，哪些是系統之外的。
我曾經做過乙個疑點資訊庫系統。該系統模擬的原有業務流程是這樣的：高層紀檢方面的領導通過信訪、舉報、資料查詢分析等方式發現了一批問題，然後將這批問題製作成一套調查清冊，親自或者交由下級相關單位，下到基層去調查問題。直到調查工作完成以後，才從基層回到自己單位，填寫調查工作底稿，詳細描述調查情況，並結束調查工作。
首先，我們應當拋開軟體實現，對這樣乙個流程進行梳理，形成這樣乙個步驟：
1. 高層領導通過信訪、舉報、資料查詢分析等方式發現一批問題；
2. 將這批問題製作成乙個調查清冊；
3. 自查或將清冊下派給下級去調查；
4. 下到基層執行調查；
5. 從基層回到自己的單位，填寫調查工作底稿，詳細描述調查情況，並結束調查工作。
然後，在對原始需求分析的基礎上，分析我們的軟體能做什麼事：
第一步：信訪和舉報雖然有自己的操作流程，但那些都在這個系統之外，在這個系統中僅僅只需錄入最後的結果。資料查詢分析過去只是業務人員在相關業務系統中根據自己的經驗執行各種查詢，現在則可以上一套資料採集和分析系統，提高資料分析的質量。
第二步：形成調查清冊，可以在系統中設計乙個功能實現。
第三步：自查或下派，可以在系統中設計乙個流程實現。
第四步：下到基層執行調查，由於網路條件等因素的限制，業務人員不可能也不必要在系統中去完成調查，只需要執行乙個標誌調查工作開始的操作，並列印或匯出調查清冊，然後去基層調查。最終，這部分被設計成乙個「開始實地核查」的操作，並提供列印匯出功能。
第五步：調查人員從基層回到自己的單位都是系統外的事情，而填寫調查工作底稿，詳細描述調查情況，並結束調查工作，則是系統內的功能。最終，這部分被設計成乙個「調查完結」功能，標誌調查工作結束，並提供工作底稿的填寫功能。
計算機資訊化管理並不是萬能的，它並不能代替現實世界中的所有工作。因此，我們進行業務流程分析，就是要分析業務流程中哪些是需要資訊化管理的，而哪些則不需要。資訊化管理過細，無疑會加重基層業務人員的負擔（這也正是為什麼許多基層業務人員會排斥資訊化系統的原因），而適當的資訊化管理則可以提高工作效率。試想一下，如果你工作中的每乙個步驟都必須在計算機中操作一下，怎麼不讓人煩呢？而如果在工作中一旦需要先查乙個什麼資訊，或者需要計算一下，系統立即可以替你完成這些工作，或者那些過去****的操作，現在立馬通過資訊化就傳遞過去了，怎麼不讓人舒心呢？我們做資訊化管理，不是要加重人的負擔，而應是降低人的負擔。以這樣的思路去進行流程分析才能設計出優秀的、人見人愛的管理系統出來。因此，我做需求分析，最喜歡下到基層去了解基層業務人員的需求，去分析怎樣設計流程才能提高他們的工作效率，而避免加重他們的負擔。「水能載舟，也能覆舟。」一套系統是否能順利推行下去，基層人員是否支援往往起到十分重要的作用。
[url=我們應當怎樣做需求分析[/url]
[url=我們應當怎樣做需求調研：初識[/url]
[url=我們應當怎樣做需求調研：拜訪[/url]
[url=我們應當怎樣做需求調研：研討會[/url]
[url=我們應當怎樣做需求調研：需求研討[/url]
[url=我們應當怎樣做需求調研：迭代[/url]
[url=我們應當怎樣做需求調研：需求捕獲（上）[/url]
[url=我們應當怎樣做需求調研：需求捕獲（下）[/url]
[url=我們應當怎樣做需求分析：功能角色分析與用例圖[/url]
[url=我們應當怎樣做需求分析：業務流程分析（上）[/url]
[url=我們應當怎樣做需求分析：業務流程分析（下）[/url]
[url=我們應當怎樣做需求分析：用例說明[/url]
[url=我們應當怎樣做需求分析：查詢報表分析[/url]
[url=我們應當怎樣做需求分析：子用例與擴充套件用例[/url]
[url=我們應當怎樣做需求分析：行**和狀態圖[/url]
[url=我們應當怎樣做需求分析：業務領域分析[/url]
[url=我們應當怎樣做需求分析：原文分析法[/url]
[url=我們應當怎樣做需求分析：領域驅動設計[/url]
[url=我們應當怎樣做需求分析：非功能需求[/url]
[url=我們應當怎樣做需求確認：需求列表[/url]
[url=我們應當怎樣做需求確認：乙個需求列表的例項[/url]
[url=我們應當怎樣做需求確認：快速原型法[/url]
[url=我們應當怎樣做需求確認：需求規格說明書[/url]
[url=我們應當怎樣做需求確認：評審與簽字確認會[/url]
（續）
我們應當怎樣做需求分析 業務流程分析（下）
另外，業務流程分析的另乙個重要的分析內容就是流程差異化分析。不同的領導有不同的思路，不同的單位有不同的情況。因此，我們在進行流程分析的時候，常常面臨流程差異化的問題。我們說企業資訊化就是一次改革，這首先體現在業務流程的規範化操作，也就是消除這種流程差異。但不同的單位有不同的情況，這特別體現在不同地域...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...