來源：http://www.javaeye.com/topic/41745
沒有一個項目不是重視需求調查的。從第一天開始，開發人員就拿著一個筆記本，把用戶都拉到會議室，詢問他們的業務流程是什么樣的。知道了業務流程，開發者剩下的工作就明確了，一條一條的去實現他們，系統就OK了。但是，業務流程可以代替需求嗎？
實際上，在業務流程的背后，有一個更加根本的因素——商業需求。商業需求才是真正的需求，業務流程只是一種實現手段而已。
開發者詢問用戶：“你們的業務流程是什么樣的？”這個問題其實是很難回答的。業務流程的制定首先是要最大限度的滿足商業需求。并且，業務流程要受到各種條件的制約，IT系統也是這個條件之一。開發者問用戶業務流程是什么樣的，用戶也要問開發者系統的設計是什么樣的，能達到什么樣的性能指標，在這個基礎上才能制定合理的業務流程。
比如一家移動通信公司，在處理新用戶入網的時候采用了一個這樣的流程，按流程先后順序：
1：首先把SIM卡和號碼在交換網絡上做對應關系的注冊；
2：市場部把SIM卡存入一定的金額，發給銷售商，收取銷售商的貨款；
3：銷售商把卡賣給用戶，用戶填寫入網合同，SIM裝入手機可以立即通話；
4：銷售商把入網合同交給市場部，市場部資料錄入人員將用戶的資料錄入系統；
5：計費系統按照用戶選擇的資費對話單進行計費；
6、市場部按照用戶的消費情況給銷售商計算傭金和返利。
這個流程的制定并不是業務部門可以單獨確定的，他和IT系統有著很深的聯系。用戶買到SIM卡以后，需要立即可以通話，但是由于IT系統的條件有限，無法做到及時向交換網絡注冊SIM卡，所以就必須先把SIM卡和號碼在交換網絡上做好，再發放到銷售點去。由于采用了這樣的辦法，又產生了一個新的問題：買到SIM卡的用戶可以立刻打電話，但是在資料錄入人員錄入用戶的資料之前，他們在系統里是沒有資料的，也沒有計費策略，這是一段資料空白期。怎樣控制空白期的時間長度，怎樣對這些通話進行計費，怎樣防止空白期的惡意欠費。。。又形成了一個個新的問題，于是又要發明一個個業務流程來處理這個問題。
IT系統和業務流程是緊密關聯的，他們互相制約，也互相促進。如果希望先把業務流程定下來，再回頭去開發IT系統，這個難度是很大的。開發IT系統，需要把目光看的更深入一點：IT系統和業務流程是為什么服務的。
IT系統和業務流程都是為了更好的實現商業需求。商業需求是企業為用戶服務、與伙伴合作的過程中產生的需求，每個商業需求都是關系到實際的商業利益的。比如說剛才那個用戶入網的流程，如果按照商業需求來看，他是為了滿足下面幾點：
1、用戶買到SIM，可以立刻裝到手機里面打電話；
2、用戶的通話可以按照他選擇的資費策略進行計費；
3、用戶交的錢計入他的賬戶，通話費用從這個賬戶中扣除；
4、用戶填寫的合同歸檔，作為日后辦理相關事宜的依據；
5、營業員收的錢計入他自己的賬本，待稽核人員下班后核查；
6、市場部根據用戶的消費情況付給代理商傭金。
這幾點就是“入網”這個業務流程需要滿足的商業需求。企業在實現這些商業需求的過程中，一定是遇到了一些麻煩，于是希望有一個IT系統來幫助自己。IT系統的開發者要和企業用戶坐在一起，先把這些商業需求搞清楚。在這個基礎上，一方面要設計支持系統，另一方面要根據支持系統的情況來制定新的流程。最終實現自動化的業務流程，更好的滿足商業需求。
從商業需求中提取重要的元素，分析這些元素的行為和相互之間的關系，我們就可以得到一個重要的東西：領域模型。
領域模型應該來源于企業的商業活動，而不應該是IT系統的業務流程。
設計領域模型，最基本的方法就是抓住一些明顯的元素進行分析。更進一步，需要抓住一些隱含的元素。業務領域中有經驗的人員，他們在分析問題時候，有時候會隨手畫出一個草圖，寫下一些數值，或者查詢某個表單，這都是重要的領域元素。了解這些東西，可以使復雜的領域問題變得容易理解，使領域模型更加符合企業的實際情況。
當這個模型漸漸清晰的時候，開發者和用戶就可以一邊進行IT系統的設計，一邊設計出更加合理高效的業務流程。有了一個個實際的東西擺在面前，用戶也能很容易的回憶起商業活動中一些重要的細節。比如看到這個租機合同，開發者會問：“這個合同有什么用處？”用戶回答說：“我知道一個用處，用戶辦理資費變更的時候，需要檢查一下這個合同，有些資費形式是合同不允許的。”
于是開發者就在資費變更的流程中記下這樣的代碼：
IF
?
NOT
?用戶
->
合同
->
允許(資費)?
THEN
??EXCEPTION(
"
用戶的合同禁止該資費
"
)
END
?
IF
下一步的工作，就是繼續將這個商業需求的細節搞清楚。“合同如何判斷一個資費形式是否允許，是判斷這個資費的收益率，還是判斷他的品牌類型。。。”
不要被表面的業務流程所迷惑，透過表面，看到背后的商業需求，你會發現需求原來非常穩定，這么多年來其實變化不多。也不需要知道所有的細節性的需求，只要了解比較重要的20％的需求，其實就可以開始進行系統的設計和編碼了。把眼光放在商業需求上，最終的業務流程才能最大限度的滿足需要，IT系統也能面臨少一點的“需求變更”。