第三章需求擷取與分析

1、第3章 需求分析,本章大綱,學習目標3.1 導論3.2 需求擷取方式3.3 需求表達工具與方法3.4 需求分析結(jié)果與文件樣版3.5 需求分析個案3.6 結(jié)論,學習目標,詳讀本章，你至少能瞭解：需求分析步驟與應注意事項。常見的六種需求擷取方式及執(zhí)行要點。何謂環(huán)境圖、事件、流程圖、處理描述、藍圖與資料詞彙。如何以環(huán)境圖、流程圖、處理描述、藍圖與資料詞彙進行需求塑模。需求分析之重要

2、工作與文件樣板為何。,3.1 導論(1/5),使用者需求，係指使用者期待系統(tǒng)解決的問題與希望從系統(tǒng)獲得之資訊。使用者需求是資訊系統(tǒng)開發(fā)過程中最關鍵、最重要且最容易發(fā)生錯誤的部分，亦是資訊系統(tǒng)失敗的主因之一。需求分析是使用者與分析師均必須重視之議題。該階段之主要工作是應用已通過驗證之原理(Principles)、技術(Techniques)、語言(Languages)與工具(Tools)，幫助分析師瞭解問題或描述與新系統(tǒng)互動之外部行

3、為。,3.1 導論(2/5),Hooper與Hsia(1982)認為系統(tǒng)開發(fā)過程中的需求分析階段主要包括三個活動：需求判斷強調(diào)如何判斷真正的需求及需求的正確性。需求分析重視在分析已有的需求下，所產(chǎn)生的不一致、不完整或矛盾等問題。需求溝通重視以最佳的方式組織及描述需求，使需求令人容易瞭解，並經(jīng)由相互溝通達到需求確認的目的。,3.1 導論(3/5),Grosz(1992)認為需求分析階段可分為兩大步驟：需求擷取主要是對系統(tǒng)範

4、圍內(nèi)之各種事物與相關現(xiàn)象，加以瞭解、判斷及選擇，並設計成描述性綱目。需求轉(zhuǎn)換主要將描述性綱目以系統(tǒng)模式語法轉(zhuǎn)換成概念性綱目。,3-7,,圖3-1 需求分析之重要步驟,3.1 導論(4/5),Byrd等人(1992)指出，需求分析是使用者與系統(tǒng)分析師相互合作努力，將資訊系統(tǒng)所需的資料加以判斷和描述。需求分析階段之重要工作包括：建立組織資訊處理需求發(fā)展資訊系統(tǒng)目標設計及評估資訊系統(tǒng)發(fā)展方案整理系統(tǒng)分析師、其他分析師、使用者和其管

5、理者溝通分析的結(jié)果從事系統(tǒng)審核,3.1 導論(5/5),使用者需求可分為：巨觀需求包括欲電腦化之環(huán)境、作業(yè)程序與範圍、輸出與輸入所需之資訊或表單及系統(tǒng)目標、限制和主要功能等，這些需求應盡可能地在需求分析階段釐清與確定。微觀需求指的是電腦化之微觀範圍，包括使用者介面要求、例外狀況處理與錯誤及輔助訊息顯示等需求，這些需求通常需到設計階段才較容易處理，在此之前這些細部需求不易被掌握。,3.1 導論,需求分析階段之重要工作包括：瞭解

6、現(xiàn)有問題瞭解新系統(tǒng)目標瞭解新系統(tǒng)之限制瞭解使用者巨觀之需求等,定義問題,兩種處理態(tài)度被動式(reaction)在問題發(fā)生時，開始尋找問題發(fā)生的主因，然後尋求解決的方法。這種態(tài)度是一般人最常用的，也稱之為例外管理(management by exception)。契機搜尋式(opportunistic surveillance)採取較積極的態(tài)度，不斷尋找對於組織有利的機會，以尋求組織持續(xù)的改善。,應完成的工作內(nèi)容確定問題的

7、主體主要是要確定到底研究的是什麼問題？這個問題的內(nèi)容是什麼？以及用什麼名稱來將此問題命名較為恰當。了解問題發(fā)生的原因主要是希望系統(tǒng)分析人員知悉問題發(fā)生的背景與原委。確定要達成的目標主要是明確地設定系統(tǒng)完成後，希望能達成的結(jié)果。目標定義明確可以避免系統(tǒng)分析人員在規(guī)劃新系統(tǒng)時產(chǎn)生方向偏差。,確定問題涵蓋的處理範圍主要是讓系統(tǒng)分析人員知道問題的界限，如此可將問題單純化而變得易於解決，以避免在規(guī)劃的過程中遺漏了某些重要、應加以考慮的

8、因素。,蒐集系統(tǒng)背景資料,資料來源分類主要的資料來源是指現(xiàn)場作業(yè)人員、系統(tǒng)操作人員、使用者、管理人員等相關人員訪談與問卷調(diào)查次要的資料來源是指經(jīng)由蒐集、分析所得到的文件資料，如與本系統(tǒng)有關的操作手冊、系統(tǒng)文件、作業(yè)程序、輸出入表單等。文件蒐集系統(tǒng)背景資料可藉由主要資料來源與次要資料來源兩方面資料的蒐集，使資料有較好的完整性。,蒐集系統(tǒng)背景資料的目的是讓系統(tǒng)分析人員知道與系統(tǒng)相關的問題，以及各問題發(fā)生的因果關係，以便系統(tǒng)分

9、析人員在往後系統(tǒng)開發(fā)時，能加以控制或解決。,3.2 需求擷取方式,在擷取使用者需求之前，必須先瞭解系統(tǒng)之潛在使用者及可能之人機互動。接著蒐集欲電腦化之作業(yè)處理程序及其輸出入資料內(nèi)容、數(shù)量、格式、目標、規(guī)則與限制等。常用的需求擷取方式有查閱文件、觀察、問卷、訪談、開會討論與聯(lián)合開發(fā)六種，這些方式可單獨應用亦可互相搭配使用。,係指研究企業(yè)的內(nèi)部文件，例如工作說明書(Job Description)、企業(yè)表單(Business Forms

10、)與手冊(Manuals)等，是瞭解企業(yè)運作邏輯之初步工作。 然而，組織中很少有完整的文件能詳細描述系統(tǒng)全貌，再加上系統(tǒng)可能已經(jīng)過多次修改，文件未能同步更新，所以文件與實際情況常有出入。以此方式蒐集之資訊常有過時之慮。,3.2.1 查閱文件,一般來說，實地觀察所獲得的資料正確性會比查閱文件為高，亦能驗證所蒐集資料之正確性及補充不完整的部分，透過觀察可以獲得第一手的資料。僅用觀察仍無法完整地反映出組織的真實情況與需求，例如被觀察者的

11、行為可能改變?；驘o法長期持續(xù)的觀察，導致可能僅觀察部份或特定的區(qū)域，從而得到不完整的片段印象與看法。選擇正常與例外情況之時機或?qū)ο髞碜饔^察，可獲得各種可能的資料。(如買房子時選擇下雨天觀看),3.2.2 觀察,3.2.3 訪談(1/7),訪談是需求擷取方式中最有效且最普遍的資料蒐集方法。訪談時，系統(tǒng)分析師將親自與使用部門的主管或相關作業(yè)人員面對面討論實際作業(yè)的情況、所需報表和資訊需求等。訪談期間，系統(tǒng)分析師蒐集到的可能是事實、選擇或

12、推測，並可觀察到人們的肢體語言、情緒和他們對於現(xiàn)行系統(tǒng)之觀感。,3.2.3 訪談(2/7),訪談可分成兩種方式：開放式訪談(Open Interview)系統(tǒng)分析師不事先預定表格、問卷或固定的標準程序，訪談過程全由使用者自由談論其工作。 主要應用在系統(tǒng)分析師對問題領域不熟悉的情況。結(jié)構(gòu)化訪談(Structured Interview)又稱為標準化訪談或?qū)蚴皆L談，其訪談過程近似詢問(Interrogation)而非交談(Con

13、versation)，所要求資訊的深度與專業(yè)程度亦較深。特點是把問題標準化，然後由受訪者回答或選擇。,3.2.3 訪談(3/7),所有的受訪者都回答同一形式的問題，其作法如下：每討論一個主題時，先由系統(tǒng)分析師依其現(xiàn)有瞭解的知識，提出簡短敘述。使用者針對主題作深度分析，但系統(tǒng)分析師應在深入到適當程度時加以中止。對某個主題有初步瞭解，就可以進行另一主題的訪談。,3.2.3 訪談(4/7),訪談之問題依其性質(zhì)可分成兩種：開放性問題(

14、如問答題)用來探索系統(tǒng)分析師無法明確詢問受訪者或?qū)κ茉L者之回答無法預期之問題。優(yōu)點：能讓先前不知道的資訊浮現(xiàn)出來。受訪者感覺較輕鬆。受訪者有機會參與和控制整個訪談的過程。缺點：回答問題所花的時間較長，也較難做結(jié)論。,3.2.3 訪談(5/7),2.封閉性問題(如選擇題、是非題)適用於問題可預期且回答可明確描述之情況。優(yōu)點：訪談的時間較短，討論的問題較廣泛。缺點：所列之回答選項未必包含受訪者所要回答的答案。封閉性問題

15、有下列幾種設計形式：對與錯的選擇方式。多重選擇的方式。李克特(Likert)量表的衡量方式。,3.2.3 訪談(6/7),訪談前需有周詳?shù)囊?guī)劃。一些有助於訪談進行之準則包括：要仔細地聆聽受訪者的回答，同時將重點記錄下來，在得到允諾的情況下，還可以將訪問的內(nèi)容用錄音機或錄影機錄下來，以有效地掌握訪談內(nèi)容。訪談結(jié)束後，須在48小時之內(nèi)將訪談內(nèi)容整理出來，因為經(jīng)過48小時之後，訪談的內(nèi)容會慢慢的從記憶中消失。,3.2.3 訪談(7

16、/7),不管是面對開放性或是封閉性的問題，系統(tǒng)分析師不要強調(diào)問題答案的對或錯。 在訪談時，不要對新的系統(tǒng)做任何預期的想法。需讓受訪者知道他們的意見會被仔細地考慮，並讓受訪者知道專案的完成需要很多的步驟，同時還有很多人的觀點都需要一起考慮。從系統(tǒng)潛在的使用者、管理者與對現(xiàn)行系統(tǒng)有經(jīng)驗的專業(yè)人員等尋找各式各樣的觀點，以對新系統(tǒng)做全盤性的瞭解，如此才能設計出大多數(shù)使用者都可接受的系統(tǒng)。,3.2.4 問卷(1/5),當潛在使用者太多或分布太

17、廣時，可考慮以問卷之方式擷取需求。一般來說，問卷調(diào)查適合於大型企業(yè)或公眾資訊系統(tǒng)的設計，因為它所涉及的作業(yè)範圍或?qū)ο筇珡V，系統(tǒng)分析師無法逐一親自調(diào)查，故利用問卷方式來蒐集使用者需求較為可行。設計一份好的問卷需有相當?shù)木毩暸c經(jīng)驗，因為問卷上的問題是以文字靜態(tài)的表達，故問題之語意與邏輯必須很清楚且有條理。,問卷設計時也可以用各種不同的方法來問同一個問題，以觀察各種可能的答案。進行正式問卷調(diào)查前需有先導測試。經(jīng)由先導測試之檢討與回饋可

18、進一步修飾問卷，及早發(fā)現(xiàn)問卷可能之問題，對提升問卷之效度有很大的幫助。正式問卷調(diào)查時必須決定哪些族群是調(diào)查的對象。對象選取之抽樣方法主要分成：機率抽樣(Probability Sampling)非機率抽樣(Nonprobability Sampling),3.2.4 問卷(2/5),3.2.4 問卷(3/5),機率抽樣方法簡單隨機抽樣(Simple Random Sampling)將系統(tǒng)使用者的名單逐一給予編號，再以摸彩法或亂

19、數(shù)表來抽樣，以決定哪些人將成為受測的對象。分層抽樣(Stratified Sampling)先將所有可能之系統(tǒng)使用者分成若干互斥的組或?qū)?，然後再從各組或各層中隨機抽選預定數(shù)目之使用者為受測對象。,3.2.4 問卷(4/5),非機率抽樣方法便利抽樣(Convenience Sampling)以方便性為抽樣之主要考量，這些抽樣之對象可能是最容易找到的系統(tǒng)使用者、願意接受調(diào)查的人或是動機高的使用者。判斷抽樣(Judgment Sam

20、pling)又稱立意抽樣(Purposive Sampling)，係根據(jù)抽樣設計者的判斷來選擇受測之使用者。設計者必須對使用者之特徵有相當?shù)夭t解，然後針對符合某些特徵的名單抽樣，例如針對使用系統(tǒng)已經(jīng)兩年以上的使用者或者是經(jīng)常使用的人。,3.2.4 問卷(5/5),上述抽樣策略可單獨使用，亦可混合使用。當問卷回收後，應該逐一檢查回收問卷之回答是否完整，並去除異常之問卷，以便進行資料分析。綜言之，問卷調(diào)查與訪談相比較，問卷調(diào)查的優(yōu)點是成

21、本比較低，蒐集的資料較為廣泛，但也有問卷回收率不高、問卷設計不易、答題人不願意依據(jù)事實填寫等缺點。此外，在資訊的內(nèi)容上，問卷所獲得的資訊可能比訪談來得少。,3.2.5 開會討論,開會討論是一種很有效率的資料蒐集方式。使用者代表與系統(tǒng)開發(fā)人員齊聚一堂，將所知道的事實、觀念說出，讓與會人員一起相互溝通意見。優(yōu)點是較易獲得正確的資料，縱使有不正確的意見或觀念，經(jīng)眾人研究後亦能加以修正。此外，多人同時聚集一起，可發(fā)揮腦力激盪的效果。缺點是要

22、安排共同的時間來進行，在溝通與協(xié)調(diào)上較困難。,3.2.6 聯(lián)合開發(fā)(1/5),聯(lián)合開發(fā)(Joint Application Development, JAD)之主要精神，是透過一個2～5天的集會，讓開發(fā)者與顧客能夠快速、有效且深入地檢討需求，進而取得共識。 聯(lián)合開發(fā)的具體結(jié)果是產(chǎn)生完整的需求文件。,3.2.6 聯(lián)合開發(fā)(2/5),JAD 依下列五個步驟來進行(Wood and Silver, 1995)： 範圍界定 關鍵人員的熟悉

23、會議準備會議進行 文件產(chǎn)生,3.2.6 聯(lián)合開發(fā)(3/5),範圍界定先由專案出資單位的高階主管定義專案範圍，以文字記載後，由高階主管和JAD 召集人一起簽訂契約。這個步驟使JAD 召集人得到進行需求分析的授權，對於目標與範圍也有了約定。關鍵人員的熟悉JAD 召集人要花一些時間訪談關鍵性的使用者及管理人員，以瞭解專案的背景資料及重要的需求。,3.2.6 聯(lián)合開發(fā)(4/5),會議準備JAD 會議前的準備工作應包括下列項目：

24、整理需求文件草稿 分送需求文件草稿安排助理人員 準備會議室 會議進行會議進行時，召集人引導大家充分利用各種視覺上的輔助工具，如白板、圖表或簡報檔等，將使用者與企業(yè)需求表達出來，並做有效地溝通及達成共識。,3.2.6 聯(lián)合開發(fā)(5/5),文件產(chǎn)生最後階段須在2、3天內(nèi)將JAD 會議所蒐集的需求，整理成需求文件。最後再召開一次審查會議，確認需求文件的內(nèi)容。,3.3 需求表達工具與方法(1/3),企業(yè)員工每天需依企業(yè)程序(Bu

25、siness Procedure)執(zhí)行處理活動，以完成企業(yè)功能(Business Function)。企業(yè)處理是指企業(yè)中最基本的活動單元，也就是說該活動已夠單純，不必再分割。需求分析階段重點工作是先擷取使用者需求(或企業(yè))的巨觀需求，並以使用者觀點應用具有完整定義的(Well-Defined)工具、圖形、或語言表達出來，再進一步對需求進行合理化，最後經(jīng)由使用者確認，以作為系統(tǒng)分析與設計的基礎。 上述從使用者需求之擷取與修飾，並將最終

26、需求以工具、圖形或語言表達之整體活動，稱為需求塑模(Requirement Modeling)。 以結(jié)構(gòu)化之系統(tǒng)分析與設計而言，主要是考量企業(yè)流程塑模與資料塑模。,,,圖3-2 需求塑模,環(huán) 境 圖流 程 圖處 理 描 述藍 圖資 料 詞 彙,3.3 需求表達工具與方法(2/3),流程塑模與資料塑模的工具包括：環(huán)境圖(Context Diagram)主要表達系統(tǒng)與所在環(huán)境之關係。流程圖(Flow Chart)主要表達實體

27、之作業(yè)程序及所需資訊間之關係。事件(Event)表示外部實體所啟動且系統(tǒng)必須回應之刺激。處理描述表示流程圖中作業(yè)處理之執(zhí)行程序與規(guī)則、相關之資料輸出入資訊以及處理之限制與備註。,3.3 需求表達工具與方法(3/3),藍圖 (Drawing)主要表示流程圖中資訊之展示格式與內(nèi)容。例如表單之格線與縱橫項目。資料詞彙 (Data Glossary)主要描述藍圖內(nèi)資訊之詳細內(nèi)容與規(guī)則。,3.3.1 事件(1/3),事件(Event

28、)表示外部實體所啟動且系統(tǒng)必須回應之「刺激(Stimuli)」。如客戶下訂單的事件由外部實體(客戶)所引發(fā)。事件可分為資料流導向、時間導向與控制導向事件三種。資料流導向之事件是系統(tǒng)藉由接收到資料之輸入而知道事件已發(fā)生。例如系統(tǒng)收到客戶輸入代號時，啟動驗證是否為有效客戶之事件時間導向之事件指預設之時間到時，該事件被啟動。例如在系統(tǒng)內(nèi)建一時鐘，當時間到達時，系統(tǒng)便會自動啟動簽發(fā)支票事件,3.3.1 事件(2/3),控制導向之事件是

29、由非預設時間之某些刺激或狀態(tài)所引發(fā)。例如系統(tǒng)之開或關等事件之集合稱為事件列(Event List)，一般來說，系統(tǒng)與外部實體之關係可用事件列來表示。對資料流導向之事件其命名與編碼原則如下：對每一外部實體給予一個唯一的名稱與編號。事件以文句之方式命名，主詞為與系統(tǒng)互動之外部實體（行為者）或系統(tǒng)，是事件之起始者或參與者。動詞是外部實體或系統(tǒng)之動作，可描述事件要處理的工作。受詞表示事件完成之工作項目、表單或格式等。亦可將與主詞互動之外

30、部實體放在句尾並括號之。此外，事件之命名要有意義，可使之一目了然。事件之編碼可由啟動事件之外部實體編號加流水碼表示之，以方便辨識。例如客戶下訂單（業(yè)務部）可編碼為A01。,3.3.1 事件(3/3),事件最好亦能描述所涉及資料之內(nèi)容。例如：客戶下訂單之事件描述：客戶以打電話、傳真、郵寄、或以Web-based系統(tǒng)向業(yè)務部下訂單。業(yè)務部處理訂貨資料。訂單主要內(nèi)容為：客戶名稱、訂購日期、訂購產(chǎn)品之品名、規(guī)格、數(shù)量、交貨地點、交貨

31、日期。,3.3.2 環(huán)境圖(1/6),環(huán)境圖(Context Diagram)用來表達系統(tǒng)所在之環(huán)境及其與環(huán)境間之關係，這包括與系統(tǒng)有關之外部實體及系統(tǒng)與外部實體間之互動，例如資訊之輸出入與處理等。環(huán)境圖常用於表達系統(tǒng)之巨觀範圍，以幫助我們瞭解系統(tǒng)所在之環(huán)境及兩者間之互動關係，其重要內(nèi)容有：與系統(tǒng)互動之外部實體系統(tǒng)從環(huán)境中接受的資訊或刺激系統(tǒng)所產(chǎn)生及輸出給環(huán)境之資訊系統(tǒng)與環(huán)境之界線等，以幫助我們瞭解系統(tǒng)所存在之環(huán)境及兩者互動之

32、關係,表3-1 環(huán)境圖之元件,3.3.2 環(huán)境圖(2/6),系統(tǒng)環(huán)境圖中係以圓形來表示系統(tǒng)，並於其中註明系統(tǒng)名稱。例如，若以環(huán)境圖表達便利商店之進銷存系統(tǒng)及其所在之環(huán)境，則以圓形表示該進銷存系統(tǒng)。外部實體外部實體可以是任何組織、物件或相關系統(tǒng)，是環(huán)境中與系統(tǒng)有互動或交換訊息之任何人或物。環(huán)境圖中以矩形表示外部實體，且於其中註明外部實體之名稱。例如使用進銷存系統(tǒng)之管理者、廠商等。,3.3.2 環(huán)境圖(3/6),處理與資訊流處

33、理與資訊流是以箭頭連結(jié)系統(tǒng)與外部實體，表示資訊之輸出入處理或事件之方向。環(huán)境圖製作常以系統(tǒng)為中心，以星狀形式表示系統(tǒng)與外部實體之關係，並將兩者互動之事件列標示在箭頭上。環(huán)境圖中不表達資料儲存。 環(huán)境圖之建構(gòu)步驟為：整理事件條列式找出外部實體找出系統(tǒng)與外部實體之關係繪製環(huán)境圖,整理事件條列式將使用者與企業(yè)需求描述整理成更簡潔的事件條列式，其中應表達事件之起始者、動作及參與動作之物件等，描述格式可表達如下：

34、 主詞＋動詞＋受詞主詞是與系統(tǒng)互動之外部實體（行為者）或系統(tǒng)動詞是外部實體或系統(tǒng)之動作，可描述事件要處理的工作受詞表示件完成之工作項目、表單或格式等。,3.3.2 環(huán)境圖(4/6),3.3.2 環(huán)境圖(5/6),2. 找出外部實體可從使用者與企業(yè)需求描述中之名詞、代名詞與名詞片語等，找出合乎外部實體定義的人、組織、物件或相關系統(tǒng)，也就是環(huán)境中與系統(tǒng)有互動或交換訊息之任何

35、人或物。3. 找出系統(tǒng)與外部實體之關係由於系統(tǒng)與外部實體之關係可用事件列來表示，因此系統(tǒng)與外部實體之關係可由步驟(1)所整理出之簡潔的事件條列式來找出。,3.3.2 環(huán)境圖(6/6),4. 繪製環(huán)境圖繪製步驟為先繪出系統(tǒng)與所有外部實體，再將系統(tǒng)與外部實體間有互動者以箭頭線段連結(jié)。若一事件由外部實體所啟動，則關係之箭頭由外部實體指向系統(tǒng)；若一事件是由系統(tǒng)回應外部實體，則關係之箭頭由系統(tǒng)指向外部實體。完成環(huán)境圖之繪製後，可用流

36、程圖表達系統(tǒng)之執(zhí)行順序。,夢幻系統(tǒng)環(huán)境圖,將外部實體、系統(tǒng)及事件啟動與影響方向(箭頭)繪製成環(huán)境圖,3.3.3 流程圖(1/4),流程圖(Flow Chart)為一圖形化表達工具，用以描述企業(yè)作業(yè)流程，其可分為系統(tǒng)流程圖及程式流程圖兩類。系統(tǒng)流程圖(System Flow Chart)用以描述整個工作系統(tǒng)中，各單位之間的作業(yè)關係。程式流程圖(Program Flow Chart)則用以表示程式中的處理過程。程式流程圖是流程圖中較常

37、用之表示方法，因此本節(jié)將介紹程式流程圖為主。,表3-2 流程圖之元件 (ANSI, 1970),3.3.3.1 流程圖之元件(1/2),作業(yè)處理(Processing)為真實世界的一個動作處理、一組動作程序、或是可執(zhí)行的一段副程式。一個作業(yè)處理是流程的基本單位，不能再被分解且此動作之執(zhí)行不能被中斷。作業(yè)處理以矩形表示，內(nèi)部標示流程名稱。決策(Decision)是用於表達有多個選擇路徑，但僅能依條件選擇其中一個路徑執(zhí)行，條件通常

38、包含Yes/No或True/False這類的問題。決策是以一菱形外加一條流入菱形之箭頭與多條流出菱形之箭頭表示。,3.3.3.1 流程圖之元件(2/2),報告(Report)可用於描述某一個流程之輸出入資訊。流程方向(Flow of Control)用以表達控制流。接點(Connector)當流程圖過於龐大或複雜時，可使用接點(Connector)將流程圖轉(zhuǎn)到另一頁，此舉可避免流程方向之箭頭交叉，亦可避免流程太過冗長，增加流

39、程圖之易讀性。註解(Annotation)用以表達流程圖之補充與說明。,3.3.3.2 流程圖製作程與準則,流程圖之建構(gòu)步驟包括：找出外部實體找出作業(yè)處理檢視外部實體繪製流程圖檢視流程圖,3.3.3 流程圖(2/4),找出外部實體流程圖之外部實體即環(huán)境圖之外部實體，每一流程圖必有起始之外部實體及與之互動的其他外部實體?？捎墒录l列式整理出該流程所涉及之實體，例如人、團隊、組織、部門或其他系統(tǒng)。找出作業(yè)處理先整理出系統(tǒng)

40、範圍內(nèi)所涉及之企業(yè)功能或企業(yè)程序，企業(yè)功能盡可能再分解成有意義且有關聯(lián)的企業(yè)處理(Business Process)。作業(yè)處理可由執(zhí)行該處理或與該處理有互動關係的實體來找出，每一處理應有清楚的輸入，新增或修改後的資料為其輸出。,3.3.3 流程圖(3/4),找出作業(yè)處理，如在進銷存系統(tǒng)中，其企業(yè)流程之基本單元可定為訂單處理與送貨處理，訂單處理之輸入為訂單，而其輸出是否要送貨或生產(chǎn)通知等，盡量避免用銷貨處理，因為銷貨處理可能包含訂貨與送

41、貨等工作。檢視外部實體逐一檢討每一實體，以找出會主動引發(fā)刺激(Stimuli)或事件(Event)之主要實體。一個主要實體可能會有一至多個主動刺激，並由每一刺激或事件開始找出其所引發(fā)之一系列高度相關之處理步驟，以形成一個流程圖。例如訂單處理後會緊接著送貨處理，因此兩者應在同一流程圖中。,3.3.3 流程圖(4/4),繪製流程圖繪製流程圖時，應由流程圖之上方或左上方開始畫起，接著依企業(yè)作業(yè)流程之發(fā)生順序畫出作業(yè)處理及流程方向，而在流

42、程的最後以一結(jié)束符號作為流程之結(jié)束。檢視流程圖檢查所有流程圖之完整性，也就是所有流程圖是否涵蓋整個系統(tǒng)範圍。,流程圖雖可表達實體與作業(yè)處理之程序及所需資訊間之關係，但無法表達每一處理之內(nèi)部行為。處理描述進一步地表達每個處理之執(zhí)行步驟、規(guī)則、控制等，並說明其資料之輸入和輸出內(nèi)容與所涉及之外部實體。每個處理描述之名稱應與流程圖中之作業(yè)處理同名，處理描述之表達形式可如下所示。 處 理 描 述 樣 板,3.3.4 處理

43、描述,藍圖主要用於表達流程圖中，有關之表單、介面等各項資訊需求之名稱、展示位置、格線、圖表與說明等，這些資訊常無法在流程圖上具體地表達，因此須另以藍圖進一步的表示。藍圖可用原始表單表達或以徒手或工具畫出具體的外觀與內(nèi)涵。每ㄧ藍圖應有名稱，名稱命名應唯一且有意義；藍圖中每ㄧ欄位應給予編號(由左而右、由上而下)，以便作為資料詞彙對欄位內(nèi)容進ㄧ步描述時之參考。,3.3.5 藍圖(Drawing),資料詞彙(Data Glossary)進一步

44、說明藍圖無法表達之內(nèi)容，如資訊之長度、型態(tài)、格式、公式、規(guī)則、範圍與限制等，並分別舉例說明之。 基本上，一張藍圖有其對應之資料詞彙，藍圖中每一欄位在資料詞彙中應有一記錄描述之。資料詞彙之內(nèi)容與格式之考量，應以能具體掌握與進一步表達資訊需求為原則。資料詞彙之內(nèi)容項目除了藍圖中之欄位編號與名稱外，欄位資料之長度與型態(tài)，資料是否唯一，資料產(chǎn)生之規(guī)則、格式、範圍、公式等資訊，均有助於系統(tǒng)分析與設計，因此均可列入資料詞彙中，其形式可表達如表

45、3-4。 資 料 詞 彙 樣 板,3.3.6 資料詞彙(1/3),資料詞彙中，規(guī)則、格式、範圍、公式等資訊可使用資料字典的格式來表達。資料字典以文字的方式輔助資訊之顯示，其為系統(tǒng)所有資料元素定義之集合。資料字典之表達符號與意義如下,3.3.6 資料詞彙(2/3),+表示必要之組合中括號[]中之元素表示，也就是從其中之元素選出一項小括號()中之元素表示單選項，也就是其內(nèi)容可有可無大括號{}表示重複項，由零或多個元素所組成,3

46、.3.6 資料詞彙(3/3),以下範例說明客戶訂單的資料元素可被定義成如下之組合(Composition)、架構(gòu)(Structure)及意義(Meaning)：定義客戶訂單後，需再對其中之資料元素提供適當?shù)恼f明。因此，資料字典應再包含對訂單項目的定義。例如：,客戶訂單＝客戶名稱　　　　?。唵尉幪枴　　　　。菜拓浀刂罚孕腥∝洝场　　　　。ㄊ圬泦T）　　　　?。唵雾椖浚?訂單項目＝零件號碼＋（零件名稱）＋數(shù)量＋

47、單價＋（折扣）,3.4 需求分析結(jié)果與文件樣板(1/2),完成需求分析與確認後，需求分析結(jié)果之文件應包括該階段中重要工作結(jié)果之摘述。需求分析結(jié)果之文件樣板如下：,3.4 需求分析結(jié)果與文件樣板(2/2),完成需求分析與確認後，需求分析之文件至少須包括該階段所屬重要工作結(jié)果之描述：問題描述：描述目前電腦化系統(tǒng)及人工作業(yè)系統(tǒng)、作業(yè)上的問題、缺少的功能、超出的成本、生產(chǎn)率問題與可靠度問題等，並排出其重要性或解決之優(yōu)先順序。新系統(tǒng)目標：針

48、對上述問題描述新系統(tǒng)欲完成之功能、補救之缺陷即將增加或修改之特色。新系統(tǒng)限制：新系統(tǒng)須能在所描述的限制內(nèi)完成目標，限制可來自高層管理者、使用者、生產(chǎn)率…。使用者需求：以流程圖配合處理描述、藍圖及資料辭彙等工具表達使用者巨觀之需求。,需求分析依3.1節(jié)概念分為需求擷取與需求轉(zhuǎn)換兩大步驟，其中，需求轉(zhuǎn)換主要以流程圖配合藍圖、資料詞彙與環(huán)境圖等進行需求塑模。本節(jié)將以一「鉦鈦有限公司之ERP導入系統(tǒng)（以下簡稱鉦鈦系統(tǒng)）」為例，針對其使用者

49、與企業(yè)巨觀需求，介紹如何以環(huán)境圖、流程圖、處理描述、藍圖與資料詞彙表達其欲電腦化的環(huán)境、作業(yè)程序與範圍、輸入與輸出所需資訊或表單及系統(tǒng)目標、限制和主要功能。,3.5 需求分析個案,3.5.1 案例介紹與需求描述(1/4),系統(tǒng)開發(fā)背景鉦鈦公司從事國際間廢鐵進出口暨汽機車零件買賣，其為掌握市場，決定建置一管理資訊系統(tǒng)，並將系統(tǒng)委由WULAB 公司進行資訊系統(tǒng)之開發(fā)。鉦鈦公司之專案指導團隊與WULAB 公司之專案開發(fā)團隊經(jīng)多次討論，將鉦

50、鈦系統(tǒng)的目標與限制、使用者與企業(yè)需求描述分別整理如下：,3.5.1 案例介紹與需求描述(2/4),系統(tǒng)目標與限制建立一Web-based管理資訊系統(tǒng)，使鉦鈦公司之客戶、生產(chǎn)部與業(yè)務部能在線上完成所有的營運管理。此管理資訊系統(tǒng)須提供表單資料維護的功能。鉦鈦公司之客戶、生產(chǎn)部與業(yè)務部不論使用哪一種瀏覽器上網(wǎng)，須看到相同的介面，並於權限內(nèi)執(zhí)行所有的操作功能。,3.5.1 案例介紹與需求描述(3/4),使用者與企業(yè)需求描述客戶以系統(tǒng)新增

51、訂單後，由業(yè)務部負責接收。當接到客戶的訂貨通知時，須先進行訂貨資料登錄，並作成品庫存檢核。若成品庫存不足，則傳送生產(chǎn)需求通知生產(chǎn)部，以便進行生產(chǎn)計畫。若成品庫存充足，則業(yè)務部直接進行送貨處理，如計算送貨總金額、遞送成品等，並傳送送貨單給客戶確認。業(yè)務部收到客戶欲退回已銷售之成品通知（銷退單），需記錄客戶編號及銷退之成品數(shù)量、單價，並計算銷退單之銷退總金額等。,3.5.1 案例介紹與需求描述(4/4),業(yè)務部向客戶請款：針對各客戶之

52、本期送貨資料，計算出本期應收帳款。每月請款一次，請款日期為每月25日。合計上期未收款項及本期應收帳款後，傳送請款單請客戶付款。業(yè)務部收到客戶之付款證明，登錄客戶編號及付款資料後，儲存該次登帳紀錄（付款單）。,3.5.2 需求塑模—建構(gòu)環(huán)境圖(1/3),整理事件條列式，如表3-7所示。,找出外部實體由使用者與企業(yè)需求描述中之名詞、代名詞與名詞片語等，找出合乎外部實體定義的人、組織、物件或相關系統(tǒng)。上表之更簡潔事件條列式中的名詞包

53、括客戶、訂單、業(yè)務部、訂貨通知、訂貨資料、成品庫存、生產(chǎn)需求、生產(chǎn)部等，其中只有客戶、業(yè)務部和生產(chǎn)部與系統(tǒng)有互動關係，合乎外部實體的定義，為本案例中之外部實體。,3.5.2 需求塑模—建構(gòu)環(huán)境圖(2/3),找出系統(tǒng)與外部實體之關係系統(tǒng)與外部實體之關係可由更簡潔的事件條列式來找出，例如第一項事件條列式是由客戶所啟動，其他事件條列式以此類推。繪製環(huán)境圖完成事件之整理工作並找出外部實體及其與系統(tǒng)之關係後，便可將外部實體與系統(tǒng)繪製成環(huán)境圖

54、，將事件編號並依外部實體啟動與被影響實體之方向?qū)⑹录l列式標示於箭頭上。,3.5.2 需求塑模—建構(gòu)環(huán)境圖(3/3),,A01.客戶＋新增＋訂單A03.客戶＋新增＋銷退單A05.客戶＋新增＋付款證明…,A02.客戶＋接收＋送貨單A04.客戶＋接收＋請款單…,圖3-3鉦鈦資訊系統(tǒng)環(huán)境圖,3.5.3 需求塑模—建構(gòu)流程圖(1/6),建構(gòu)流程圖之步驟依序為：找出外部實體找出作業(yè)處理檢視外部實體繪製流程圖檢視流程圖,3.5.

55、3 需求塑?！?gòu)流程圖(2/6),由使用者與企業(yè)需求描述和事件條列式得知，前兩項作業(yè)可連續(xù)發(fā)生，也就是客戶訂貨，若無足夠庫存，則進行生產(chǎn)計畫；若有足夠庫存，則可馬上送貨，其餘三項作業(yè)均各自獨立?？蓪⑶皟身検褂谜吲c企業(yè)需求合併為訂單送貨流程，而其餘三項需求分別為銷退處理流程、請款處理流程與登帳處理流程。以訂單送貨流程為例，其流程圖、處理描述、藍圖和詞彙說明如下。,3.5.3 需求塑模—建構(gòu)流程圖(3/6),流程圖1由事件條列式與環(huán)

56、境圖得知，在訂單送貨流程中，有三個外部實體參與，分別為：客戶、業(yè)務部與生產(chǎn)部。前兩項作業(yè)中有訂貨與送貨兩個基本作業(yè)處理、一個庫存檢核控制，以及產(chǎn)出三張基本表單：訂單、送貨單與生產(chǎn)需求。首先由客戶送出訂單來起始該流程，接著業(yè)務部進行訂單處理、庫存檢核與送貨處理或輸出生產(chǎn)需求。最後，流程終止於客戶收到送貨單或生產(chǎn)部收到生產(chǎn)需求。,,圖3-4 訂單送貨流程圖,流程圖1,3.5.3 需求塑模—建構(gòu)流程圖(4/6),處理描述1-1以訂單送貨

57、流程之訂單處理為例（參考圖3-4），其資料來源為客戶之訂單，且產(chǎn)出為生產(chǎn)部之生產(chǎn)需求或進行送貨處理。訂單處理之處理描述名稱可命名為訂單處理與庫存判斷，該處理描述與庫存判斷之執(zhí)行程序與規(guī)則，可從上述需求描述摘述如表3-8。流程圖中，每一處理應有一處理描述，每一處理描述應有一致的表達格式。,表3- 8 訂單處理描述,處理描述1-1,3.5.3 需求塑模—建構(gòu)流程圖(5/6),藍圖1-1以訂單送貨流程之訂單為例，其藍圖基本上可以該公司目

58、前之訂單報表為基礎，再進一步對訂單上的每一欄位，以由上而下、由左至右之原則編號，例如客戶編號為A、地址為B，依序至總金額為O等，詳如右表所示。,鉦鈦有限公司,3.5.3 需求塑模—建構(gòu)流程圖(6/6),資料詞彙1-1每張藍圖應有一份資料詞彙，且藍圖中之每一欄位在資料詞彙中應有一記錄描述之。因此以鉦鈦公司之訂單藍圖為例（參表3-9），採用資料詞彙樣板（參表3-4），再經(jīng)由訪談整理後，其訂單藍圖之資料詞彙可整理如表3-10。,表3-10

59、 訂單資料詞彙,資料詞彙1-1,,圖3-5 銷退處理流程圖,流程圖2,銷退單,銷退處理,銷退紀錄,客 戶,業(yè) 務 部,,,,,表3-11 銷退處理描述,處理描述2-1,,圖3-6 請款處理流程圖,流程圖3,送貨資料記錄,請款處理,請款單,客 戶,業(yè) 務 部,,,,,表3-12 請款處理描述,處理描述3-1,表3-13 請款單藍圖,藍圖3-1,表3-14 請款單資料詞彙,資料詞彙3-1,,圖3-7 登帳處理流程圖,

60、流程圖4,付款證明,登帳處理,付款單,客 戶,業(yè) 務 部,,,,,表3-15 登帳處理描述,處理描述4-1,3.6 結(jié)論(1/2),需求分析的過程主要是擷取與表達使用者之巨觀需求，這包括欲電腦化之環(huán)境、作業(yè)處理、輸出與輸入所需之資訊或表單與系統(tǒng)主要功能等。 需求分析階段對問題領域之瞭解範圍應盡可能地廣泛，到了分析與設計階段再縮小到專案範圍，如此有助於對新系統(tǒng)之瞭解與規(guī)劃。,3.6 結(jié)論(1/2),以目前之開發(fā)工具來說，需求分

61、析工作約占整個專案時間的25%左右，且需求分析往往無法在一個階段內(nèi)完全做完，常在分析與設計階段仍有需求分析工作之進行。系統(tǒng)分析師之專業(yè)知識與經(jīng)驗，對需求分析之成效有密切之影響。,補充 －－ 可行性研究,可行性研究的目的可行性研究的評估層面可行性研究的文件製作,?可行性研究的目的,可行性研究的目的是根據(jù)系統(tǒng)的需求，分析問題的特性與範圍，並估算系統(tǒng)發(fā)展所需的各項資源、費用成本以及工作時程，藉此評價系統(tǒng)是否有繼續(xù)進行的價值，對現(xiàn)行環(huán)境

62、適不適合或可不可行。,?可行性研究的評估層面,五種可行性評估層面：,技術可行性(technical feasibility)目的在於評估完成新系統(tǒng)的技術是否專案人員有能力可以達成，以及進行此新系統(tǒng)所冒的風險。內(nèi)容新系統(tǒng)目標所需要的週邊設備是否已經(jīng)具備？開發(fā)新系統(tǒng)所需要的技術，專案小組成員是否已經(jīng)具有開發(fā)之能力？新系統(tǒng)所需要的效能是否可以達成？是否有其他人員可以提供我們相關支援，來完成這個系統(tǒng)？,經(jīng)濟可行性(economic

63、 feasibility)目的在於評估新系統(tǒng)經(jīng)濟效益方面的得失，以便公司高階主管判斷值不值得投資，其重點在於公司的成本效益分析。內(nèi)容評估推行此系統(tǒng)所需增加的費用支出與以後的使用費用。評估系統(tǒng)完成後，對現(xiàn)行作業(yè)之效益分析與實質(zhì)服務品質(zhì)的改善。比較前項之開發(fā)成本與後項之運轉(zhuǎn)效益，並評估系統(tǒng)的得失。,法律可行性(legal feasibility)目的在於評估新系統(tǒng)進行的內(nèi)容是否違反了現(xiàn)行的法令。內(nèi)容新系統(tǒng)的內(nèi)容是否為現(xiàn)行

64、法令所不允許？是否侵犯了他人的權益？是否違反了著作權法或智慧財產(chǎn)權？軟體開發(fā)契約的訂立，與雙方的權利與義務？,作業(yè)可行性(operational feasibility)目的在於評估新系統(tǒng)的推行是否為使用者所接受？是否管理階層同意？現(xiàn)行作業(yè)是否可以配合。內(nèi)容所推行的系統(tǒng)對現(xiàn)行作業(yè)環(huán)境的影響。系統(tǒng)是否為使用者所接受？管理階層是否接受此專案？是否支持？是否能配合實施？,時程可行性(schedule feasibility)

65、目的在於評估新系統(tǒng)是否能於預估的時限內(nèi)完成。內(nèi)容系統(tǒng)開發(fā)的工作時程安排是否合理？系統(tǒng)工作時程的安排專案小組成員是否可以如期完成？系統(tǒng)完工之時效性是否可以被管理人員接納？,?可行性研究的文件製作,可行性研究的步驟成立負責專案小組蒐集與系統(tǒng)有關的資料設計各種可行性方案評估各種可行性方案選擇最適可行性方案撰寫可行性研究報告,可行性研究報告撰寫的目的主要在於將可行性研究之內(nèi)容、結(jié)果與建議，以文字的表達方式，呈給公司最高

66、管理階層主管審閱，供最高階層主管用以判斷應採取的方案，同時，也讓公司最高階層主管了解所選擇的方案對組織的影響。,可行性研究報告的內(nèi)容緒論說明此可行性研究的目的與研究的範圍、系統(tǒng)的緣由以及為什麼會有這個專案。系統(tǒng)目標與需求說明系統(tǒng)的目標，要具備那些功能？需要的操作條件如何？完工的期限是什麼時候？公司願意提供的開發(fā)經(jīng)費是多少?，F(xiàn)行作業(yè)說明說明目前組織的結(jié)構(gòu)如何？現(xiàn)行組織的工作環(huán)境如何？與系統(tǒng)有關的現(xiàn)行作業(yè)有那些？現(xiàn)行組織的工作環(huán)

67、境中有那些軟體、硬體設備？,可行性方案研擬與說明列出符合前述系統(tǒng)需求的可行性方案，說明各可行性方案的架構(gòu)與內(nèi)容、各方案的軟硬體設備需求、各方案所需的經(jīng)費以及各方案的工期如何?？尚行苑桨冈u估將前述列舉的可行性方案，依照可行性研究的判斷條件逐項評估，評估的項目必需包含有技術可行性、經(jīng)濟可行性、法律可行性、作業(yè)可行性、時程可行性。在本節(jié)中，必須詳細說明各方案的評估結(jié)果。,結(jié)論與建議說明專案小組的評估結(jié)果，建議公司應選擇的方案，並說明為

68、何選擇此方案，此方案對公司的影響層面如何？同時並對公司未來可採取的措施，提出具體的建議。參考資料列出在此報告中曾經(jīng)參考過的資料與書目，必須詳細列出參考資料的出處。附錄敘述報告本文中所不足而需要補充的內(nèi)容。,一、系統(tǒng)簡介 1.1 簡述 1.2 系統(tǒng)目標 1.3 系統(tǒng)範圍 1.4 系統(tǒng)主要功能 二、現(xiàn)行作業(yè)分析 2.1 現(xiàn)行組織圖 2.2 各

69、相關單位作業(yè)說明 2.3 現(xiàn)行環(huán)境的軟硬體架構(gòu) 三、可行性方案研擬與說明 3.1 各項方案說明 3.1.1 方案構(gòu)想說明 3.1.2 方案架構(gòu) 3.1.3 方案的軟硬體需求 3.1.4 方案運作的環(huán)境與流程 3.2 各項方案評估 3.2.1 技術可行性 3.2.2