怎樣做一個優秀的系統分析師？
作者：IT168 鐵在燒 發表日期：2007-03-14 08:55
筆者常常在思考一個問題,什么是系統分析師?什么樣的人是優秀的系統分析師?什么樣的人是企業真正需要的系統分析師?系統分析師也許很神秘,也許很抽象,他有很多其他稱謂,比如需求分析師、分析師等等。你可以說系統分析師是IT技術專家,也可以說他是業務專家,甚至可以說系統分析師是管理專家,那么他到底是什么?
也許,有一點我們可以確定,系統分析師連接著用戶的需求,系統分析師主導著開發的實現,系統分析師的素質高低對IT項目的成敗起到很重要的作用。
近年來,我國IT軟件產業發展規律迅猛,需要大量IT人才,尤其需要居于IT人才金字塔頂端的系統分析師人材,筆者以自己的做系統分析師一些經驗和對這個職業的理解，試圖用一些文字研究系統分析師的素質和能力模型，以饗讀者和廣大IT技術人員、系統分析師同仁。
要想成為一名優秀的系統分析師，首先必須弄明白與系統分析師相關的一些職業理念和相關的工作概念定義。
一、 如何理解系統、信息系統、系統分析、系統設計、系統分析師？
系統是一組為實現某些結果相互聯系、相互作用的部件的集合體。而信息系統是一組完成收集、處理、儲存信息和以輸出完成商業任務所需信息作為提交的系統。系統分析是理解并詳細說明信息系統應該做什么的過程。系統設計是詳細說明信息系統的諸多組件在物理上是怎樣實施的過程。
系統分析師是使用信息技術的商業專業人員，利用分析和設計技術解決業務問題。他是團隊中的一種角色,主要負責與涉眾客戶代表協同工作,以便對項目需求進行獲取、分析、編寫說明規格、確認和管理,也可稱需求分析師,業務分析員等。
做一名系統分析師，要首先認識什么是系統分析師。對于同樣一件事物的認識，每個人都會不一樣，“一千個人有一千個哈姆雷特”，這關乎到認識論。其實,一個人的認識正好折射出了他的經驗、水平、層次、能力。一句話，大道由簡，我們也許熟悉了很多系統分析方面的技術，然后我們需要問自己是不是真的懂這個職業的本質含義所在，一定不要舍本求末。
上面的定義很簡單，但反映了一些基本的要素。系統分析師首先是商業人員，然后才是IT技術人員，但系統分析師不是程序員，他的使命是解決業務問題，手段是信息技術。他不但要理解還要會詳細地說明，這意味著他的商業知識、理解分析能力以及表達能力是比較基礎的核心能力。還有, 系統分析最重要的是實踐過程。系統分析師最好和業務人員打成一片,這樣才會獲得用戶的信任。
順便需要說明的是，信息系統有很多種類型,常見的有OLTP、 MIS、EIS、DSS。當然,你還可以談很多,其實，任何一個名詞都足夠寫一本書,你就大膽地講出你的理解吧。但一定要記得總結,用一句話能總結出來就不用兩句話,系統分析這個職位對思維的清晰要求頗高。
二、系統分析師需要哪些技能？
首先，系統分析師應熟悉如何建立信息系統，這要求相當高的信息技術能力，包括軟件工程、主流技術架構、網絡、數據庫技術等等。
第二,系統分析師應必須熟悉自己正為之工作的商業行業，以及該行業如何使用各種類型系統的情況。
最后，系統分析師應需要熟悉相當多的人及其工作方式，因為這些人是信息系統的使用者，或者說是系統分析師的“客戶”。
系統分析師是“通才”，正是因為他們連接了IT和業務。優秀的分析師其實懂三種“世界”的語言，即計算機語言、商業語言、人的語言。
對于商業，有些分析師一生專門研究一個特定的商業行業，比如制造業、零售業、服務業或貿易行業。一個非常熟悉某特定行業的分析師能夠為這個行業的公司解決一些復雜的問題。
熟悉這個公司則需要花費一些時間，尤其是細節方面，包括組織結構、使命、成功的因素、戰略和計劃、企業文化和企業價值。
總之,系統分析師=行業業務專家+IT技術專家+管理專家。
三、系統分析師解決問題的大致過程是什么？
系統分析師解決問題的大致過程一般如下：
（1）研究和理解問題。
（2）核實解決問題的效益大于成本。
（3）確定解決問題的需求。
（4）制定一套可能的解決方案，提供多種可供選擇的方法。
（5）決定最佳方案并推薦給決策層。
（6）詳細說明所選方案的細節。
（7）實施解決方案。
（8）監控結果是否達到預期結果。
這個是經過歸納的大致過程,實際還有其他經典的過程,與之的區別只是形式上不同，但求解問題的過程是一致的。
上面的步驟是經過歸納過的，也許不同類型的系統，不同類型的企業工作方法不盡相同，但從宏觀的角度看的確是類似的。
四、系統分析原型法的意義
原型(Prototype) 即樣品、模型的意思。把系統主要功能和接口通過快速開發制作為“軟件樣品 ”，以可視化的形式展現給用戶，及時征求用戶意見，從而明確無誤地確定用戶需求。另外，原型也可用于征求內部意見，作為分析和設計的接口之一，可方便于溝通。
對原型的基本要求包括：體現主要的功能、提供基本的界面風格、展示比較模糊的部分以便于確認或進一步明確。原型最好是可運行的，至少在各主要功能模塊之間能夠建立相互連接。
原型法意義在于可視化、強化溝通、降低風險、節省后期變更成本、提高項目成功率。一般來說，采用原型法后可以改進需求質量。雖然投入了較多先期的時間，但可以顯著減少后期變更的時間。原型法投入的人力成本代價并不大，但可以節省后期成本。對于較大型的軟件項目來說，原型系統可以成為開發團隊的藍圖。另外，原型通過充分和客戶交流，還可以提高客戶滿意度。
原型法是在計算機技術發展到一定階段，用戶應用需求高漲的情況下發展的一種方法論，但它同時又是對開發人員有高要求的一種方法論。
原型法的基本思想如下: 原型法是確定需求策略，是對用戶需求進行抽取、描述和求精。它快速地、選代地建立最終系統工作模型，對問題定義采用啟發的方式，由用戶作出響應。原型法實際上是一種動態定義技術。
原型法被認為對于大多數企業的業務處理來說，需求定義幾乎總能通過建立目標系統的工作模型來很好地完成，而且這種方法和嚴格定義方法比較起來，成功可能性更大。
原型法開發策略基于如下的假設：
（1）并非所有的需求在系統開發以前都能準確地說明。
（2）有快速的系統建造工具。
（3）項目參加者之間通常都存在通信上的障礙。
（4）需要實際的、可供用戶參與的系統模型(system model)。
文字和靜態圖形是一種比較好的通信工具，然而其最大的缺點是缺乏直觀的、感性的特征，因而往往不易理解對象的全部含義。交互式原型系統能夠提供生動活潑的規格說明，用戶見到的是一個“活”的、運行著的系統。理解紙面上的系統和操作運行在機器上的系統，其差別是十分顯著的。因此，當能夠提供一個生動的規格說明成為可能的話，人們就不會滿足于一個靜止的、被動的規格說明。
總之，當提供一個活生生的系統模型時，人們對它的了解將比說明性材料好得多。
（5）需求一旦確定，就可以遵從嚴格的方法。
（6）大量的反復是不可避免的、必要的，應該加以鼓勵。
在信息系統設計的過程中，常用的各種不同形式的部分原型有：
（1） 對話原型
原型模擬預期的終端交互，使用戶可以從屏幕上查看他們將接收什么、進行的操作，并提出遺漏之處，從而加深正確的理解。終端對話的設計效果直接影響著系統的可用性和用戶對系統的接受程度。
（2） 數據輸入原型
建立數據輸入的原型，可以檢查數據的輸入速度和正確性，還能進行有效性和完整性的檢查。
（3） 報表系統原型
提供給用戶的各種報告應在整個系統實現之前給用戶看，報表子系統需要經常進行大量修改以滿足系統的需要，因此，可以把報表生成器作為原型。
（4） 數據系統原型
首先生成一個含有少量記錄的原型數據庫，這樣用戶和分析師與它可以進行交互，生成報表和顯示有用信息。這種交互經常導致產生對不同的數據類型、新的數據域或不同的數據組織方式的需求，還可以在原型化工具的幫助下探索用戶將如何使用信息以及數據庫是什么樣的。
（5） 計算和邏輯原型
有時一個應用邏輯或計算是復雜的。審計員、工程師、投資分析師和其他用戶可以使用高級程序設計語言建立他們所需的計算實例。這些實例可以組合在一起構成一個大的系統，與其它應用系統、數據庫或終端相連接，用戶可以使用這些計算原型檢驗他們所求結果的準確性。
（6） 應用程序包原型
在一個應用程序包和其它應用系統相連或實際使用之前，可以通過一個小組用戶來鑒定這個應用程序包是否令他們滿意，若不滿意可以進行大量的修改，直到令他們滿意。
（7） 概念原型
原型法是近年來流行的軟件需求捕獲方法之一。我們應該明白原型法是手段而不是目的。需要回答的要點是,原型法的背景、概念、定義、意義、如何實現原型、最好能夠舉例說明。
能夠回答這些問題才能說明你完全掌握了原型法。很顯然,提出這種問題的企業對這種方法在實際工作中是會相當倚重的，因此您不僅要知之還要行之。
以一個簡單的案例來說明，王五是某家大型電子商務貿易公司的系統分析師,他負責做了一個詢盤系統。由于詢盤系統牽涉到許多抽象專業知識,因此為了便于溝通, 王五經過一番研究制作了界面原型設計,并給出了解決方案,領導和客戶看了原型設計后通過該需求方案。這個案例說明,今天的需求分析,不再是分析師和客戶之間的訪談,更是一種通過實際原型(模型)互相啟發,從而發現需求,歸納總結需求的一個實踐過程。但我們可以看到,原型法只是一種手段,與用戶良好的互動和溝通是獲得需求的基本點所在。
六、如何進行有效的需求開發過程?
需求描述了客戶需要或目標,或者描述了為滿足這種需要或目標，產品必須具有的條件或能力,它是種特性,要求產品為涉眾提供價值。
系統需求是系統必須完成的功能和局限性。功能需求是描述系統必須完成的活動或過程的一種系統需求,它就是系統要投入的商業應用。用戶需求(User Requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例（Use Case）文檔或方案腳本（Scenario）說明中予以說明。功能需求(Functional Requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。而所謂特性(Feature)是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。
系統分析階段的活動則有如下幾種（表1）,同時列舉了其對應解決相應的關鍵問題。
表1
分析階段的活動
關鍵問題
收集信息
是否已經擁有了全部的信息來定義系統所必須完成的工作？
定義系統需求
需要系統做什么？
構建可行性的發現原型
可以證明此種技術能夠實現想讓它完成的那些功能嗎？
是否已經構建出一些原型讓用戶能夠完全理解新系統的潛在功能？
產生評估方案
創建系統的最好方案是什么？
與管理部門一起復查各種建議
是否應該繼續設計和實現我們提出的系統？
解決關鍵問題的方法，大致如下：
（1） 搞清楚系統相關者,通過組織結構圖找系統角色,他們是系統的主要使用力量。
（2） 系統開發的分析階段的目標是理解商業功能和獲得系統需求。
（3） 在改正舊系統到新系統的轉換過程中，關鍵是新系統。通過調查問卷，面談去理解新系統的限制。通過復查現有文檔，去理解信息的過程。通過研究商業過程和供應商，去理解新系統的功能。最終是為新系統開發出系統需求和模型。
以上的描述是一種系統分析的流程,下面介紹從需求角度看分析師的業務問題。
需求開發依先后順序可以分為：需求獲取（Elicitation）、分析(Analysis)、編寫規格說明（Specification）和驗證（Verification）四個階段。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。
需求開發活動包括以下幾個方面：
（1） 確定產品所期望的用戶類。
（2）獲取每個用戶類的需求。
（3） 了解實際用戶任務和目標以及這些任務所支持的業務需求。
（4）分析源于用戶的信息，以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。
（5）將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件。
（6）了解相關質量屬性的重要性。
（7）商討實施優先級的劃分。
（8）將所收集的用戶需求編寫成規格說明和模型。
（9）評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前將問題都要弄清楚。
需求分析（Requirement Analysis）包括提煉、分析和仔細審查已收集到的需求，以確保所有的風險承擔者都明白其含義并找出其中的錯誤、遺漏或其它不足的地方。分析的目的在于開發出高質量的需求，這樣你能做出實用的項目估算并可以進行設計、構造和測試。
通常把需求中的一部分用多種形式來描述，如同時用文本和圖形來描述。分析這些不同的視圖將揭示出一些更深的問題，這是單一視圖無法提供的。分析還包括與客戶的交流以澄清某些混淆，并明確哪些需求是更為重要的。其目的是確保所有風險承擔者盡早地對項目達成共識并對將來的產品有個相同而清晰的認識。下面是需求分析中經常使用的方法:
（1）繪制系統上下文示意圖
這種示意圖是用于定義系統與系統外部實體間的界限和接口的簡單模型。同時它也明確了通過接口的信息流和物質流。
（2）創建用戶接口原型
當開發人員或用戶不能確定需求時，開發一個用戶接口原型———個局部的可能實現——這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間的所有沖突之處。
（3）分析需求可行性
在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。
（4）確定需求的優先級別
應用分析方法來確定使用實例、產品特性或單項需求實現的優先級別。以優先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，并在那個版本計劃中作出需要的變更。
（5）為需求建立模型
需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系，以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
（6）創建數據字典
數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。
（7）使用質量功能調配
質量功能調配(Quality Function Deployment，QFD）是一種高級系統技術，它將產品特性、屬性與對用戶價值聯系起來。該技術提供了一種分析方法以明確哪些是客戶最為關注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備。
系統分析師需要掌握需求捕獲、需求分析和需求確認方法,并且要有一定的實踐經驗,因為需求分析是門需要實踐的學問。
需求捕獲的方法其實有多種,你可以熟悉每一種方法。通過文檔概要、面談、觀察、原型、調查表、供應商調查、聯合應用會議等等方法是可以獲得需求的。但在實際中,你不必十八般武藝樣樣都要使出來, 本質上持續不斷的捕獲高質量的需求的方法只有一個，就是和業務人員打成一片,這樣,不再是你去找需求,需求可能會來找你了,這是一種主動需求的方法,所以系統分析師一般都需要有良好的人際互動能力。
當然,需求捕獲還是有其自身的方法的, 要講需求捕獲必先談到收集信息, 信息不足則“巧婦難為無米之炊”。其實這里有三個經典的問題,會是系統分析師經常用到的或提到的問題。由信息收集到需求捕獲，再到需求分析是需求開發的中軸線,而能否收集到必要的有效的需求信息, 請仔細體會如下三個問題。
（1）商業過程和操作是什么，即你要干什么
系統分析師核心是理解商業過程,一般用戶只會對現狀回答,但分析師要能識別在改進的系統中哪些要保留，哪些要刪除。這個問題是溝通的第一步,回想當年筆者第一次就這樣問用戶：“你的流程是什么？你有什么問題”,何其愚也,從問用戶的問題可以看出這個分析師是不是有經驗。
（2 ）商業過程應該怎樣完成，即系統分析師該如何完成它,或者說需要哪些步驟
用戶談的是老系統的完成辦法,而系統分析師的核心是新系統應該如何支持這項功能,而不是在現有系統下如何執行。分析師重要的是超越現在,使新技術帶來的商業處理方法更高效。
（３）需要什么樣的信息，即為了完成商業過程，系統分析師要使用哪些信息，使用什么樣的表單或報告。
有價值的系統分析師有一套需求捕獲的手法，有價值的系統分析師一定會從理論到實際仔細研究需求分析的過程。
筆者在上面介紹的一些概念和理念，并不是使您成為一個優秀系統分析師的“金科玉律”或“武功秘笈”。筆者想借助此文與讀者和同仁交流溝通。