首先，我們應該明確進行需求分析的目的。我認為，進行業務需求分析的直接目的就是為了進行信息系統的開發，所謂的需求，就是信息系統建設的需求。如果一個業務不需要信息系統就能有效開展，就不需要進行需求分析，直接開展業務就行。進行需求分析，是為開發信息系統服務。是為了讓系統開發者明白，需要開發一個怎樣的信息系統。如，需要什麽樣的功能，有什麽樣的輸入輸出，有什麽樣的交互界面，業務處理的規則是什麽等等。當然，在需求分析過程中，有可能使得業務人員更加清晰其原來對業務的考慮，進而對其業務進行重新定義。但歸根結底，進行業務需求分析還是為了開發出一個信息系統，支持業務的開展。

其次，我們要問，怎樣進行業務需求分析，才能有效地表達需求。所謂的有效地表達需求，就是讓業務部門知道，他的業務得到了準確而完整的描述，讓系統開發部門也明白，看得懂關於業務的描述，從而讓技術人員能夠開發出符合業務開展需要的信息系統。這是一個很專業的工作。而從事需求分析的人員，必須精通業務和技術兩頭的工作。否則無法起到一個橋梁的作用，幫助企業把信息系統建立起來，推動業務的發展。他的產出，一定是業務和技術兩方面都能看得懂的。產出只有一方能看的懂的東西，不叫業務需求。做業務需求，好比一個翻譯器，把業務人員描述的東西，翻譯成技術人員能看得動的東西。就好像把英語翻譯成漢語一樣。如果翻譯官的水平不高，翻譯的效果可能就會大打折扣。就會出現把Mr Green翻譯成綠色先生的情況。

為了能做出有效的業務需求，可以通過一些約定好的方法來進行。通過這些約定好的方法，開發出業務需求產出物。技術人員就能大致地知道想要建立一個什麽樣的系統。業務部門也知道，他的業務會不會被系統有效地支持。由此，這個約定的，制作業務需求的方法，就很關鍵。從計算機系統被研制出來到今天，已經產生了很多方法和體系，對於不同的企業，其方法和體系也不盡相同。但都不排除一些共性。做業務需求，首先就得明確一個大家都知道的方法，否則容易產生混亂。如果你這邊講活動，我那講用例，就無法高效地建立信息系統，支持業務發展了。

本文簡要討論一下，根據工作經驗總結出的一個支持需求開發的方法。其實，一篇文章不足以完整描述一套業務需求方法。在此只是基於一個已開發出的企業架構管理系統做一個介紹。說是企業架構管理系統，其實就是一個需求描述和分析的系統。把做業務需求的方法固化到了系統中。通過一個獨立的信息系統（工具）來管理（或者說建立）一個具有復雜業務的企業的業務需求，以支持開發整個企業所需要的信息系統。

對於一個如銀行這樣的大型企業，僅僅靠傳統的需求文檔，已經很難支持其高效地開發完整的信息系統。所以必須有工具來支持。其實市場上早已有了若幹需求管理工具，但是大多數都只是把傳統的需求分析文檔電子化，然後分了個類。不足以動態支持從需求分析到系統設計的整個過程。我們開發的這個企業架構管理系統，正是基於曾經經歷的信息系統建設的經驗，把企業建立信息系統的從需求描述到系統設計整個過程進行有效的支持。所有的工作件都得到動態的展示，然後還能有效地分析和管理，十分明確地知道業務是否得到了完整有效描述，系統設計是不是完全支持了業務開展的需要。而不是需要人工去看文檔才知道。

我們一開始就需要明確地是，大家約定了什麽方法來描述業務需求。這個約定的方法，可以叫做企業架構元模型，如果只是描述業務部分的，叫業務架構元模型，只是描述技術部分的，叫技術架構元模型。這只是一個大概的分類，從細分的角度，還可以分為，應用架構，數據架構的原模型等。所以這些分類，必須是一個完整的，結構清晰的整體，才能有效支持開發企業需要的信息系統。否則將陷於一片混亂。下圖為企業架構元模型的一部份。

從圖中可以看到，要開發出一個完整的企業信息系統，就要對其進行完整的描述。描述的要素很多。各要數之間的關系也很復雜。大概很少有人能夠把所有的要素及其相互之間的關系都記在大腦裏面。因此，依靠專業的信息系統來進行記錄和管理就很有必要。他保證了方法和規則的唯一性。盡管每個人對系統的理解可能會不一樣，但是至少有一個地方整體地記錄了所有的環節。從而盡可能地避免了理解上的歧義。從整體上，描述系統的要素很多，一個人只能掌握其中的一小部分，而由系統來保證了所有人的理解是一致的。這就是企業架構系統的作用所在。

基於企業架構系統，相關業務人員和技術人員在上面開展工作，各自發揮出自己的專長，設計出最好的產出成果。然後開發出企業需要的信息系統。保證企業的業務的發展。由此，企業架構系統的功能，就很關鍵。

首先，他要能夠定義 各種元素 ，用以描述所需要建立的信息系統。比如，我們需要把企業的業務分成各個領域，就要能夠在系統上定制出“業務領域”的概念，我們還要定義各種流程，就要在系統上定義“活動”，“任務”，“步驟”，“事件”的概念，為了描述系統本身，我們還需要定義出“業務功能”，“系統用例”，“構件”的概念，如此等等。根據不同的情況，定義不同的概念，這是企業架構系統的一個基本功能。這種功能很多工具都有。

其次，各元素定義好以後，還需要描述各元素之間的關系。上圖中所有的連線，就是關系的一種示意。具體的關系的表達，還需要在架構系統內部進行詳細的定義。比如我們可以通過列表的形式，來描述各元素之間的關系。一方面是便於使用者進行查閱，一方面是讓系統能夠根據規則自動進行相互間邏輯的檢查，從而保證了一致性。

對於大部分人來說，不會關心系統所有的方面，對於業務專家，他只關心業務邏輯是什麽樣的，甚至他只關心其所涉及的領域的業務邏輯，比如風險專家只關心風險模型。資產負債管理專家關心資金轉移定價。而應用架構專家關心交易線，數據專家只關心數據模型，系統設計人員關心有哪些構件、接口、工作流，項目管理專家只關心項目進展，而企業高管，只關心有哪些業務組件 等等。因此，架構系統需要根據不同的人群建立不同的視圖，只展現其所關心的那部分工作內容，而不是把所有的信息全部都展現給他，否則會產生幹擾和信息冗余。當然，也會存在那種關心所有要素的人員，要麽確實在信息系統建設方面很資深，要麽就是好奇打醬油的。本人雖然一直關心所有的要素，但至今也沒能夠把所有的要素和關系理清晰。不過在架構系統的幫助下，整體功能一定會井然有序。

把所有元素和關系表達清楚，仍然不能保證信息的完整性，因為你不知道他所表達的業務的邏輯對還是不對。靠眼睛看能解決一部分問題，但畢竟有限。如果等系統建設好了才發現邏輯錯誤，或者在系統開發過程中發現錯誤，耽誤的功夫就比較大了。因此，我們在需求分析階段，就希望知道業務需求提供的信息是否是充分和必要的。為此，架構系統提供了一個模擬仿真功能。用報表，流程引擎，規則引擎的方式方法，把目標系統模擬地運行分析一遍，看看哪個環節出會出問題。最終形成一個完整的經過嚴格驗證的圖紙。這樣業務人員能很直觀地知道為他所設計的系統是什麽樣，技術人員也很放心地明白他所拿到的開發需求是經過了嚴格驗證的。

定義元素，定義關系，建立視圖，模擬仿真，是架構系統的幾個核心功能，根據這些功能，就能開發出業務需求，支持業務信息系統的建設。此外還有系統管理，版本管理，用戶管理，報表功能等一些通用功能。

通過架構系統，我們能夠有效地進行業務的描述，分析，仿真，系統的設計等工作。以保證信息系統建設的成功。當然，關鍵的因素，還是人的因素。系統是起到一個幫助的作用，人的智慧的發揮，才是最重要的，不用心去做，再好的系統也是屠龍刀而已。

如何進行業務需求分析