可以看出，業務建模在ERP工程中被著重強調，而且ERP中的BPR已經成為一門獨立的學科。不僅如此，即便是在普通的信息系統中，業務建模也是非常重要的，所不同的，僅僅是它們的規模而已。這一點上，可能大家會不理解，如果你只是為企業的業務自動化建立應用，直接照搬企業模式不就行了嗎。這里有兩點原因，一是企業原有的業務模式在以人為主的環境中可能運行的很好，可是把這套模式原本不動的搬到計算機上就未必會適合了。人的能力和計算機的能力有很大的出入，所以流程必須經過調整以適應計算機；第二個原因是上面已經提到過的避免產生部門級的，部分功能區域的應用系統。
在RUP中，業務建模被作為下游流程的輸入重點強調：業務模型是需求工作流程的一種重要輸入，用來了解對系統的需求。業務實體是分析設計工作流程的一種輸入，用來確定設計模型中的實體類。（RUP）
3. 需求和業務建模
業務建模是需求工程中最初始的階段，也是整個項目的初始階段。需要指出的是，業務建模時間的跨度在不同的項目中有很大的差別的。在有些項目中，例如大型ERP系統，可能需要幾個月的時間。而對于普通的項目，業務建模的時間可能僅僅需要幾天的時間。
需求是技術無關（technology independent）的。在需求階段討論技術是沒有任何意義的。那只會讓你的注意力分散。技術的實現細節是在后面的分析、設計階段才需要考慮的事情。而在業務建模階段，不但要保證需求的技術無關性，還要保證你的需求不要深入細節。因為在業務建模階段，最重要的事情就是要了解業務的全貌，深入細節會浪費時間和精力。要知道，討論一個企業里的業務細節，就算給你一個月的時間也沒必能夠結束。
在實際中，這兩點都是很難做到的。例如企業原先有一個系統，這就不得不由你討論和新舊系統的兼容問題。這時候就要注意，如果你是討論就有系統的架構的話，那還是屬于技術無關的范疇，如果你一旦進而討論各具體模塊/組件的細節，那就非但不是技術無關，而且也深入細節了。在不深入細節的問題上，往往你很難禁止項目涉眾（Stakeholder）①不去討論一些相關的業務細節。這個時候你可以將這些細節記錄下來，然后再回到業務建模上。
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉眾是所有會受到項目結果重大影響的人。
4. 業務建模時期的主要任務
項目涉眾的共同愿景：要想項目成功，可離不開項目涉眾的支持。在項目一開始，不論是項目涉眾還是開發人員，對項目的任務、范圍都是模糊不清的。但隨著項目的深入，原來模糊的景象會慢慢清晰、立體起來。但是為了不浪費時間，我們有必要在項目射入之前，現在項目涉眾中豎立一個共同的愿景。
共同愿景的豎立可沒有想象中的那么簡單，因為每位涉眾都關心自己的利益，都有自己的評判標準。你可以把大家的意見都列在白板上，然后逐項集中討論，做出修正，直到大家的意見一致的時候為止。在共同遠景的豎立過程中，其實有兩件事情也已經同時做了，項目范圍（scope）和高階（high-level）需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
