以上大家可以理解，我們有沒有更深的理解呢？我先從業務主角和業務角色說起業務建模，在業務建模中主要有業務主角（BUSINESS ACTOR）和業務角色（BUSINESS WORKER），對此我們有什么了解呢。我先做出定義：業務主角是服務對象，如對商店進行業務建模， 業務主角是顧客。業務角色是服務人員或系統，如對商店進行業務建模，業務角色是售貨員。業務主角是為誰提供服務，產生了用例。業務角色是提供服務，完成了用例�？梢宰屑毧纯碦UPCN。這兩個東西它們在ROSE中圖形的表示也不一樣。
但大家有沒有想過，業務建模更深的意義，我們在傳統的軟件工程來說并沒有類似業務建模這個概念，而RATIONAL公司又要將此放入，在軟件工程中，它又到底起了什么作用呢？
一般說來，我們做一個軟件項目基本上都是從需求調研后就到需求建模和需求分析了，沒怎么去想業務建模。而大家有沒有想過，我們對需求的處理比較表象，如界面、功能和數據，對業務處理過程缺少規范的說明，而這正是開發必須的。你有沒有覺得你以前很多開發沒有準確反應需求，是否有一個原因，不是需求不清，而是對需求的實現過程不清，即沒有了解好業務，從RUP的角度來說，也就是缺少了業務建模這一關鍵環節。我曾經思索過業務建模最主要解決什么問題，我的看法就是業務建模就是創建業務處理模型，是進行需求分析的依據。而需求分析的結果，將要確定一個開發規范，正確的實現業務處理過程應當是它的一個重要內容，而我們在需求調研時，往往忽視了這一點。
那么，在需求調研中，需求建模與業務建模誰先誰后呢？個人認為，業務是本來就存在的，不管有沒有這個軟件或項目，它都存在，它都在按一定的模式運作，因此業務建模與需求調研、需求建模是無關的，立項之前業務模型就可以存在. 或是立項以前，業務建模就可以完成的。 然而，實際并非如此，用戶只知道如何處理業務，卻很少有一個完整的業務模型，當立項時，就需求承建方邦助客戶創建它。因為承建方不了解客戶的業務過程是不能建模的， 又必須了解客戶的業務。
對于軟件開發過程，從軟件工程的角度來說大多數人都清楚從需求調研，到需求建模，需求分析，系統分析，系統結構設計，系統代碼設計，系統測試，系統維護這一過程，我參與過的項目，讓我感到，有些項目失敗或是非常難做，不在于以上這些環節沒做好，而在于少了業務的環節。
很多人也許會說，業務不就是需求嗎，沒錯，但更多的時候我們關注的是界面、功能、和數據，卻很少注意功能之間的聯系即業務過程。
有沒有想過，我們將軟件所有的功能做成菜單，讓用戶自己選擇他們要做什么，而沒有一個業務過程的概念，用戶要自己知道用了某個功能后下一個該用哪個。這樣的系統其實不是應用系統，只是一個數據處理機或者說是一個比較復雜的計算機器。它把業務過程分解為一些獨立/分散的功能，而沒有把這些功能組織起來。因此，有必要將業務從需求中分離而進行強調。我想，這也就是RATIONAL 公司引入業務建模這個重要的概念吧，
無論是從我的經驗、觀點和教訓來說，還是看了RUP的觀點來年，我個人認為新的軟件開發過程是：業務調研，業務建模(業務分析)，(業務模型分析)需求調研（這時，已經有一部分需求可從來務模型中獲得）, 需求建模，需求分析……因為建模的過程也是分析的過程，所以業務建模和業務分析可能交叉在一起。如果遇到一個客戶，規范到已經有了現成的業務模型，那么直接就拿來就可以了。如果業務建模與需求調研是同一班人，那么需求調研中的業務模型分析工作就比較容易了。
業務建模當中又要注意什么呢？我個人的看法是：千萬別把業務建模和需示分析混在一起啦。如網上訂單系統，一個人下了訂單，當然此訂單是通過系統自動完成，并沒有后臺人員的支持，此時，業務主角當然是下訂單的人，那業務角色呢 是否是沒有，還是下訂單的人？ 對于系統來說，業務主角當然是下訂單的人，而業務角色呢？不太可能是系統自已吧？ 而我的看法是業務角色就是系統自已，那不是很矛盾嗎？其實，關鍵一點是業務建模你不能有需求分析的概念，在這里，系統并不是軟件系統，而是完成業務主角的訂單，即一個用例的東西，根據業務建模的概念，完成了訂單這個用例只能是訂單系統，那么業務角色也就是訂單系統。因為它是下訂單這一業務中。
無論業務角色還是業務主角，都是對角色的抽象，不能具體到某個人的。而一個具體的事務，可能會兼任兩個不同的角色，但此時，大部分發生了身份或崗位的轉移。
zingers 2003-10-31
關于業務建模，Craig larman在他的名著中倒是有所提到，作者在把它歸納在用例分析中了，比如他始終強調關鍵業務角色的利益所得和相對趨勢。我在一個省級檢測機構作項目時，就自覺得把系統對人的影響和角色對系統的期待，以及它們之間的反復作用放在一個很重要的層面上來考慮，盡管這種做法還無法按步就班地操作，就是先研究現有業務流程，把確定性和不確定性的因素考慮周到，再設想系統實現和人的反應性之間的關系。然后再在設計時注意軟件的可變動性。這樣的一個好處是項目相對比較順利，和各方面打交道比較順暢，真正讓軟件有使用價值，而不是變成一堆代碼的尸體。
clamp 2004-12-30
呵呵，這個帖子好象響應的人不多啊。
我勉強也可以算是做業務需求的吧。
目前我把它分成以下幾塊內容（主要針對企業定制應用）
1、客戶方基本信息。
包括客戶信息、組織結構、用戶、用戶關系等
2、客戶方業務流程和業務信息
3、客戶方管理和生產模式
4、客戶方的變化和發展方向
以上這幾部分其實更接近于咨詢所要了解的內容。
5、哪些部分需要使用系統？系統的邊界和范圍是什么？系統的涉眾是什么？
6、系統對應哪些業務流程和業務信息，引入系統以后新的業務流程和業務信息是什么？？
7、引入系統以后新的管理和生產模式是什么？？
以上這三個問題我認為是一個項目最核心的問題
大到橫跨整個企業的ERP，小到針對一個人的信息管理，都要考慮這三個問題。
8、對引入系統以后新的業務流程和業務信息進行概念建模
9、對引入系統以后新的管理和生產模式以客戶方內部規范的形式固定下來
這一步也很重要
10、獲取具體對象和用例
11、獲取對象關系和用例關系
注意：以上的步驟不是先后執行的，根據實際的情況會有調整。
事實上在實際操作的時候往往是從第10步和第11步開始，但是只有這兩步是不夠的……
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
