需求分析的概念

1、需求分析的概念 期數：第19期作者：楊清萍 【叡揚資訊金融資訊服務部經理】 前言 軟體開發(fā)的成功要素在於能夠充分了解需求，否則無論多麼好的系統(tǒng)設計或是多麼強的程式設計能力，都無法彌補因需求不夠明確對整體系統(tǒng)開發(fā)所造成的危害。 需求分析是一連串的處理過程，處理的精神在於找出使用者的需求，經過萃鍊，將需求資料的、功能的以及行為的需求模式化，最後產出一份需求規(guī)格。在過程中，系統(tǒng)開發(fā)者扮演的角色，是利用高度的溝通技巧，採各種不同的詢問角度肯定句、疑問句或不斷地重覆，將可能是被誤解或是模糊不清的訊息一一加以澄清。由以上對需求分析的定義，衍生出軟體需求分析的五大主要部份，分別為問題的認知、問題的評估及綜合

2、、模式化的過程、需求規(guī)格的產生及需求規(guī)格的審查。問題的認知：需求範圍的產生是來自於專案計畫中所定義的系統(tǒng)規(guī)格，系統(tǒng)開發(fā)人員即系統(tǒng)分析師必須對專案計畫有充分的了解，為促成系統(tǒng)分析師與使用者之間對系統(tǒng)開發(fā)基本問題的共識，可以透過召開專案計畫會議，邀請系統(tǒng)影響所及的相關人員及主管參與，針對系統(tǒng)的目標及效益及系統(tǒng)分析師所提出專案中可能的解決方案充分討論及協(xié)調，了解每個人在專案進行中所扮演的角色，凝聚雙方對專案成功的共識。問題的評估及綜合：系統(tǒng)分析師在這部分的工作著重於必須清楚地定義所有可觀察到的資料主體，評估資訊的流向及資訊的內容，定義及演化出應有的系統(tǒng)功能，了解系統(tǒng)如何因外來事件的觸發(fā)而有的正?；貞?/p>

3、，進而建立系統(tǒng)之間的介面，並能發(fā)掘一些未來系統(tǒng)設計的限制。在評估現(xiàn)有的問題及必須的輸入及輸出的訊息，系統(tǒng)分析師在整理這些相關的資料過程中，已慢慢釐出未來被建置的系統(tǒng)應有的功能架構。模式化的過程：主要在描述使用者需要些什麼、當系統(tǒng)完成時能驗證這些需求是否被滿足。系統(tǒng)分析師透過一些系統(tǒng)化的方法，創(chuàng)造出能被系統(tǒng)設計人員充分了解的有關資料流向、控制流向、功能處理、系統(tǒng)行為運作及資料內容的模式，利用這些模式產生的軟體需求規(guī)格做為進一步系統(tǒng)設計的基礎。模式化的核心，有賴於定義一致的資料辭典來包含軟體開發(fā)中所需的所有資料體的描述，藉由資料辭典做為需求分析溝通的共同語言。而模式化可分為三方面，一是資料模式，二

4、是功能模式，三是行為模式。常用來表示這三方面的分析模式有ERD(Entity Relationship Diagram)，DFD(Data Flow Diagram)，CFD(ControFlow Diagram)，STD(State Transition Diagram).等，系統(tǒng)分析的模式必須達成三個主要的目標: (1)描述使用者的需求，(2)建立基本的軟體設計環(huán)境，(3)定義軟體設計完成後驗證需求的方法。為了達成這三項主要目標所衍生出的結構化分析模式如圖一所示: 圖一 結構化分析模式 資料字典位於圖一的核心-存放所有輸入及輸出資料物件的敘述。圍繞於圖一核心的三種圖表其中的實體關係圖(En

5、tity-Relationship Diagram，ERD)，為描述資料物件之間的關係。ERD同時也用來表示資料模組之間的運作方式。資料物件敘述(Data Object Description)說明ERD中資料物件的屬性。資料流程圖(Data Flow Diagram，DFD)主要有二種目的: (1)顯示資料在系統(tǒng)中的流向，(2)描述處理資料流程的功能項目。DFD在資訊範圍的分析過程中可提供附加資訊並可將其當做是基本的功能模式。在DFD中每一個功能的敘述是在功能規(guī)格(Process Specification，PSPEC)中完成。 狀態(tài)轉換圖(State Transition Diagram，

6、STD)顯示系統(tǒng)對外部事件作何種反應。為此，STD顯示系統(tǒng)不同的行為狀態(tài)及狀態(tài)與狀態(tài)間轉換的不同方式。也可把STD當做是基本的行為模式。控制規(guī)格(Control Specification，CSPEC)則包括軟體控制觀點的其他相關資訊。這些模式分析的產出最終的目的在於讓需求分析的結果愈趨近於可被建置的系統(tǒng)。 需求規(guī)格的產生：系統(tǒng)分析師將需求以一種能被成功建置的方式展現(xiàn)給系統(tǒng)開發(fā)人員及使用者，透過需求規(guī)格的產生，將系統(tǒng)分析師對使用者需求的認知轉化成可閱讀及可被了解的文件，作為雙方對談及後續(xù)開發(fā)的基礎，需求規(guī)格的可讀性與系統(tǒng)分析師的文件表達能力有強烈的正相關?；镜男枨笠?guī)格架構涵蓋： ·

7、 系統(tǒng)概述：描述系統(tǒng)所欲達成的目標，使用何種電腦系統(tǒng)及規(guī)劃的軟體範圍。 · 資訊描述：提供軟體所要解決問題的詳細描述，包括資訊的內容，對應關係，流程及架構，並且以外部系統(tǒng)元件及內部軟體功能來描述軟硬體及人機介面。 · 功能描述：描述每項功能所能解決的問題及其相關程序，經由陳述並證實設計上的限制，及未來系統(tǒng)建置後可達成之系統(tǒng)執(zhí)行效率的耍求，並輔以多張圖表解釋整個系統(tǒng)的架構及系統(tǒng)功能與其他系統(tǒng)元件之間的相互關係。 · 行為模式的描述：如何因應外部事件的觸發(fā)及內部控制的特性而導致影響系統(tǒng)軟體操作所產生之結果。 · 驗證及標準：用以驗證軟體開發(fā)完成後之正確性。需要徹底地了解軟體需求方可明確地描述驗證方法及標準，做為重新檢視所有的需求之依據以求未來系統(tǒng)設計之完整性。 · 參考文獻及附錄。 需求規(guī)格的審查：應由系統(tǒng)分析師及使用者一起進行需求規(guī)格的審查，從宏觀及微觀的角度來檢視規(guī)格書的內容。從宏觀的角度應確認規(guī)格的完整性，一致性及正確性。從微觀的角度應審視規(guī)格書中的用字遣詞，是否有尚未發(fā)現(xiàn)的潛在問題存在。一旦審查完成，規(guī)格書即