首先，我們應該明確進行需求分析的目的。我認為，進行業務需求分析的直接目的就是為了進行資訊系統的開發，所謂的需求，就是資訊系統建設的需求。如果乙個業務不需要資訊系統就能有效開展，就不需要進行需求分析，直接開展業務就行。進行需求分析，是為開發資訊系統服務。是為了讓系統開發者明白，需要開發乙個怎樣的資訊系統。如，需要什麼樣的功能，有什麼樣的輸入輸出，有什麼樣的互動介面，業務處理的規則是什麼等等。當然，在需求分析過程中，有可能使得業務人員更加清晰其原來對業務的考慮，進而對其業務進行重新定義。但歸根結底，進行業務需求分析還是為了開發出乙個資訊系統，支援業務的開展。
其次，我們要問，怎樣進行業務需求分析，才能有效地表達需求。所謂的有效地表達需求，就是讓業務部門知道，他的業務得到了準確而完整的描述，讓系統開發部門也明白，看得懂關於業務的描述，從而讓技術人員能夠開發出符合業務開展需要的資訊系統。這是乙個很專業的工作。而從事需求分析的人員，必須精通業務和技術兩頭的工作。否則無法起到乙個橋梁的作用，幫助企業把資訊系統建立起來，推動業務的發展。他的產出，一定是業務和技術兩方面都能看得懂的。產出只有一方能看的懂的東西，不叫業務需求。做業務需求，好比乙個翻譯器，把業務人員描述的東西，翻譯成技術人員能看得動的東西。就好像把英語翻譯成漢語一樣。如果翻譯官的水平不高，翻譯的效果可能就會大打折扣。就會出現把mr green翻譯成綠色先生的情況。
為了能做出有效的業務需求，可以通過一些約定好的方法來進行。通過這些約定好的方法，開發出業務需求產出物。技術人員就能大致地知道想要建立乙個什麼樣的系統。業務部門也知道，他的業務會不會被系統有效地支援。由此，這個約定的，製作業務需求的方法，就很關鍵。從計算機系統被研製出來到今天，已經產生了很多方法和體系，對於不同的企業，其方法和體系也不盡相同。但都不排除一些共性。做業務需求，首先就得明確乙個大家都知道的方法，否則容易產生混亂。如果你這邊講活動，我那講用例，就無法高效地建立資訊系統，支援業務發展了。
本文簡要討論一下，根據工作經驗總結出的乙個支援需求開發的方法。其實，一篇文章不足以完整描述一套業務需求方法。在此只是基於乙個已開發出的企業架構管理系統做乙個介紹。說是企業架構管理系統，其實就是乙個需求描述和分析的系統。把做業務需求的方法固化到了系統中。通過乙個獨立的資訊系統（工具）來管理（或者說建立）乙個具有複雜業務的企業的業務需求，以支援開發整個企業所需要的資訊系統。
對於乙個如銀行這樣的大型企業，僅僅靠傳統的需求文件，已經很難支援其高效地開發完整的資訊系統。所以必須有工具來支援。其實市場上早已有了若干需求管理工具，但是大多數都只是把傳統的需求分析文件電子化，然後分了個類。不足以動態支援從需求分析到系統設計的整個過程。我們開發的這個企業架構管理系統，正是基於曾經經歷的資訊系統建設的經驗，把企業建立資訊系統的從需求描述到系統設計整個過程進行有效的支援。所有的工作件都得到動態的展示，然後還能有效地分析和管理，十分明確地知道業務是否得到了完整有效描述，系統設計是不是完全支援了業務開展的需要。而不是需要人工去看文件才知道。
我們一開始就需要明確地是，大家約定了什麼方法來描述業務需求。這個約定的方法，可以叫做企業架構元模型，如果只是描述業務部分的，叫業務架構元模型，只是描述技術部分的，叫技術架構元模型。這只是乙個大概的分類，從細分的角度，還可以分為，應用架構，資料架構的原模型等。所以這些分類，必須是乙個完整的，結構清晰的整體，才能有效支援開發企業需要的資訊系統。否則將陷於一片混亂。下圖為企業架構元模型的一部份。
從圖中可以看到，要開發出乙個完整的企業資訊系統，就要對其進行完整的描述。描述的要素很多。各要數之間的關係也很複雜。大概很少有人能夠把所有的要素及其相互之間的關係都記在大腦裡面。因此，依靠專業的資訊系統來進行記錄和管理就很有必要。他保證了方法和規則的唯一性。儘管每個人對系統的理解可能會不一樣，但是至少有乙個地方整體地記錄了所有的環節。從而盡可能地避免了理解上的歧義。從整體上，描述系統的要素很多，乙個人只能掌握其中的一小部分，而由系統來保證了所有人的理解是一致的。這就是企業架構系統的作用所在。
基於企業架構系統，相關業務人員和技術人員在上面開展工作，各自發揮出自己的專長，設計出最好的產出成果。然後開發出企業需要的資訊系統。保證企業的業務的發展。由此，企業架構系統的功能，就很關鍵。
首先，他要能夠定義 各種元素 ，用以描述所需要建立的資訊系統。比如，我們需要把企業的業務分成各個領域，就要能夠在系統上定製出「業務領域」的概念，我們還要定義各種流程，就要在系統上定義「活動」，「任務」，「步驟」，「事件」的概念，為了描述系統本身，我們還需要定義出「業務功能」，「系統用例」，「構件」的概念，如此等等。根據不同的情況，定義不同的概念，這是企業架構系統的乙個基本功能。這種功能很多任務具都有。
其次，各元素定義好以後，還需要描述各元素之間的關係。上圖中所有的連線，就是關係的一種示意。具體的關係的表達，還需要在架構系統內部進行詳細的定義。比如我們可以通過列表的形式，來描述各元素之間的關係。一方面是便於使用者進行查閱，一方面是讓系統能夠根據規則自動進行相互間邏輯的檢查，從而保證了一致性。
對於大部分人來說，不會關心系統所有的方面，對於業務專家，他只關心業務邏輯是什麼樣的，甚至他只關心其所涉及的領域的業務邏輯，比如風險專家只關心風險模型。資產負債管理專家關心資金轉移定價。而應用架構專家關心交易線，資料專家只關心資料模型，系統設計人員關心有哪些構件、介面、工作流，專案管理專家只關心專案進展，而企業高管，只關心有哪些業務元件 等等。因此，架構系統需要根據不同的人群建立不同的檢視，只展現其所關心的那部分工作內容，而不是把所有的資訊全部都展現給他，否則會產生干擾和資訊冗餘。當然，也會存在那種關心所有要素的人員，要麼確實在資訊系統建設方面很資深，要麼就是好奇打醬油的。本人雖然一直關心所有的要素，但至今也沒能夠把所有的要素和關係理清晰。不過在架構系統的幫助下，整體功能一定會井然有序。
把所有元素和關係表達清楚，仍然不能保證資訊的完整性，因為你不知道他所表達的業務的邏輯對還是不對。靠眼睛看能解決一部分問題，但畢竟有限。如果等系統建設好了才發現邏輯錯誤，或者在系統開發過程中發現錯誤，耽誤的功夫就比較大了。因此，我們在需求分析階段，就希望知道業務需求提供的資訊是否是充分和必要的。為此，架構系統提供了乙個模擬**功能。用報表，流程引擎，規則引擎的方式方法，把目標系統模擬地執行分析一遍，看看哪個環節出會出問題。最終形成乙個完整的經過嚴格驗證的圖紙。這樣業務人員能很直觀地知道為他所設計的系統是什麼樣，技術人員也很放心地明白他所拿到的開發需求是經過了嚴格驗證的。
定義元素，定義關係，建立檢視，模擬**，是架構系統的幾個核心功能，根據這些功能，就能開發出業務需求，支援業務資訊系統的建設。此外還有系統管理，版本管理，使用者管理，報表功能等一些通用功能。
通過架構系統，我們能夠有效地進行業務的描述，分析，**，系統的設計等工作。以保證資訊系統建設的成功。當然，關鍵的因素，還是人的因素。系統是起到乙個幫助的作用，人的智慧型的發揮，才是最重要的，不用心去做，再好的系統也是屠龍刀而已。
如何進行軟體需求分析
概念 需求的定義包括從使用者角度 系統的外部行為 以及從 開發者角度 一些內部特性 來闡述需求。關鍵的問題是一定要編寫需求文件。我曾經目睹過乙個專案中途更換了所有的 開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說 我們想與你談談你的需求。客戶的第一反應便是 我已經將我的要求都告訴你們前任...
如何進行軟體需求分析
如何進行軟體需求分析 1 概念 需求的定義包括從使用者角度 系統的外部行為 以及從開發者角度 一些內部特性 來闡述需求。關鍵的問題是一定要編寫需求文件。我曾經目睹過乙個專案中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說 我們想與你談談你的需求。客戶的第一反應便是 我已經將...
軟體測試如何進行需求分析
需求的分類 業務需求 反應了客戶對系統，產品的高層次的目標要求，在專案檢視和範圍文件中予以說明。功能需求 定義了開發人員必須實現的軟體功能，使得使用者能夠完成他們的任務，從而滿足了業務需求。使用者需求 文件描述了使用者使用產品必須要完成的任務，在使用者說明書明確體現。eg 業務需求 企業內部要有自己...