怎樣做一個優秀的系統分析師？

筆者常常在思考一個問題,什麼是系統分析師?什麼樣的人是優秀的系統分析師?什麼樣的人是企業真正需要的系統分析師?系統分析師也許很神秘,也許很抽象,他有很多其他稱謂,比如需求分析師、分析師等等。你可以說系統分析師是IT技術專家,也可以說他是業務專家,甚至可以說系統分析師是管理專家,那麼他到底是什麼?

    也許,有一點我們可以確定,系統分析師串連著使用者的需求,系統分析師主導著開發的實現,系統分析師的素質高低對IT項目的成敗起到很重要的作用。 

    近年來,我國IT軟體產業發展規律迅猛,需要大量IT人才,尤其需要居於IT人才金字塔頂端的系統分析師人材,筆者以自己的做系統分析師一些經驗和對這個職業的理解，試圖用一些文字研究系統分析師的素質和能力模型，以饗讀者和廣大IT技術人員、系統分析師同仁。 

    要想成為一名優秀的系統分析師，首先必須弄明白與系統分析師相關的一些職業理念和相關的工作概念定義。 

    一、 如何理解系統、資訊系統、系統分析、系統設計、系統分析師？ 

    系統是一組為實現某些結果相互聯絡、相互作用的組件的集合體。而資訊系統是一組完成收集、處理、儲存資訊和以輸出完成商業任務所需資訊作為提交的系統。系統分析是理解並詳細說明資訊系統應該做什麼的過程。系統設計是詳細說明資訊系統的諸多組件在物理上是怎樣實施的過程。 

    系統分析師是使用資訊技術的商業專業人員，利用分析和設計技術解決業務問題。他是團隊中的一種角色,主要負責與涉眾客戶代表協同工作,以便對項目需求進行擷取、分析、編寫說明規格、確認和管理,也可稱需求分析師,業務分析員等。 

    做一名系統分析師，要首先認識什麼是系統分析師。對於同樣一件事物的認識，每個人都會不一樣，“一千個人有一千個哈姆雷特”，這關乎到認識論。其實,一個人的認識正好折射出了他的經驗、水平、層次、能力。一句話，大道由簡，我們也許熟悉了很多系統分析方面的技術，然後我們需要問自己是不是真的懂這個職業的本質含義所在，一定不要舍本求末。 

    上面的定義很簡單，但反映了一些基本的要素。系統分析師首先是商業人員，然後才是IT技術人員，但系統分析師不是程式員，他的使命是解決業務問題，手段是資訊技術。他不但要理解還要會詳細地說明，這意味著他的商業知識、理解分析能力以及表達能力是比較基礎的核心能力。還有, 系統分析最重要的是實踐過程。系統分析師最好和業務人員打成一片,這樣才會獲得使用者的信任。 

    順便需要說明的是，資訊系統有很多種類型,常見的有OLTP、 MIS、EIS、DSS。當然,你還可以談很多,其實，任何一個名詞都足夠寫一本書,你就大膽地講出你的理解吧。但一定要記得總結,用一句話能總結出來就不用兩句話,系統分析這個職位對思維的清晰要求頗高。 
 

    二、系統分析師需要哪些技能？ 

    首先，系統分析師應熟悉如何建立資訊系統，這要求相當高的資訊技術能力，包括軟體工程、主流技術架構、網路、資料庫技術等等。 

    第二,系統分析師應必須熟悉自己正為之工作的商業行業，以及該行業如何使用各種類型系統的情況。 

    最後，系統分析師應需要熟悉相當多的人及其工作方式，因為這些人是資訊系統的使用者，或者說是系統分析師的“客戶”。 

    系統分析師是“通才”，正是因為他們串連了IT和業務。優秀的分析師其實懂三種“世界”的語言，即電腦語言、商業語言、人的語言。 

    對於商業，有些分析師一生專門研究一個特定的商業行業，比如製造業、零售業、服務業或貿易行業。一個非常熟悉某特定行業的分析師能夠為這個行業的公司解決一些複雜的問題。

熟悉這個公司則需要花費一些時間，尤其是細節方面，包括組織圖、使命、成功的因素、戰略和計劃、企業文化和企業價值。 

    總之,系統分析師=行業業務專家+IT技術專家+管理專家。 

    三、系統分析師解決問題的大致過程是什嗎？ 

    系統分析師解決問題的大致過程一般如下： 

    （1）研究和理解問題。 

    （2）核實解決問題的效益大於成本。 

    （3）確定解決問題的需求。 

    （4）制定一套可能的解決方案，提供多種可供選擇的方法。 

    （5）決定最佳方案並推薦給決策層。 

    （6）詳細說明所選方案的細節。 

    （7）實施解決方案。 

    （8）監控結果是否達到預期結果。 

    這個是經過歸納的大致過程,實際還有其他經典的過程,與之的區別只是形式上不同，但求解問題的過程是一致的。 

    上面的步驟是經過歸納過的，也許不同類型的系統，不同類型的企業工作方法不盡相同，但從宏觀的角度看的確是類似的。

 

    四、系統分析原型法的意義 

    原型(Prototype) 即樣品、模型的意思。把系統主要功能和介面通過快速開發製作為“軟體樣品 ”，以可視化的形式展現給使用者，及時徵求使用者意見，從而明確無誤地確定使用者需求。另外，原型也可用於徵求內部意見，作為分析和設計的介面之一，可方便於溝通。 

    對原型的基本要求包括：體現主要的功能、提供基本的介面風格、展示比較模糊的部分以便於確認或進一步明確。原型最好是可啟動並執行，至少在各主要功能模組之間能夠建立相互串連。 

    原型法意義在於可視化、強化溝通、降低風險、節省後期變更成本、提高項目成功率。一般來說，採用原型法後可以改進需求品質。雖然投入了較多先期的時間，但可以顯著減少後期變更的時間。原型法投入的人力成本代價並不大，但可以節省後期成本。對於較大型的軟體項目來說，原型系統可以成為Team Dev的藍圖。另外，原型通過充分和客戶交流，還可以提高客戶滿意度。 

    原型法是在電腦技術發展到一定階段，使用者應用需求高漲的情況下發展的一種方法論，但它同時又是對開發人員有高要求的一種方法論。 

    原型法的基本思想如下: 原型法是確定需求策略，是對使用者需求進行抽取、描述和求精。它快速地、選代地建立最終系統工作模型，對問題定義採用啟發的方式，由使用者作出響應。原型法實際上是一種動態定義技術。

　　原型法被認為對於大多數企業的業務處理來說，需求定義幾乎總能通過建立目標系統的工作模型來很好地完成，而且這種方法和嚴格定義方法比較起來，成功可能性更大。 

    原型法開發策略基於如下的假設：

　（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 ）商業過程應該怎樣完成，即系統分析師該如何完成它,或者說需要哪些步驟 

    使用者談的是老系統的完成辦法,而系統分析師的核心是新系統應該如何支援這項功能,而不是在現有系統下如何執行。分析師重要的是超越現在,使新技術帶來的商業處理方法更高效。 

    （３）需要什麼樣的資訊，即為了完成商業過程，系統分析師要使用哪些資訊，使用什麼樣的表單或報告。 

    有價值的系統分析師有一套需求捕獲的手法，有價值的系統分析師一定會從理論到實際仔細研究需求分析的過程。 

    筆者在上面介紹的一些概念和理念，並不是使您成為一個優秀系統分析師的“金科玉律”或“武功秘笈”。筆者想藉助此文與讀者和同仁交流溝通。