第3章 需求分析.

Presentation on theme: "第3章 需求分析."— Presentation transcript:

1 第3章 需求分析

2 本章大綱 學習目標 3.1 導論 3.2 需求擷取方式 3.3 需求表達工具與方法 3.4 需求分析結果與文件樣版 3.5 需求分析個案
3.1 導論 3.2 需求擷取方式 3.3 需求表達工具與方法 3.4 需求分析結果與文件樣版 3.5 需求分析個案 3.6 結論

3 學習目標 詳讀本章，你至少能瞭解： 需求分析步驟與應注意事項。 常見的六種需求擷取方式及執行要點。
何謂環境圖、事件、流程圖、處理描述、藍圖與資料詞彙。 如何以環境圖、流程圖、處理描述、藍圖與資料詞彙進行需求塑模。 需求分析之重要工作與文件樣板為何。

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

5 3.1 導論(2/5) Hooper與Hsia(1982)認為系統開發過程中的需求分析階段主要包括三個活動： 需求判斷
強調如何判斷真正的需求及需求的正確性。 需求分析 重視在分析已有的需求下，所產生的不一致、不完整或矛盾等問題。 需求溝通 重視以最佳的方式組織及描述需求，使需求令人容易瞭解，並經由相互溝通達到需求確認的目的。

6 3.1 導論(3/5) Grosz(1992)認為需求分析階段可分為兩大步驟： 需求擷取
主要是對系統範圍內之各種事物與相關現象，加以瞭解、判斷及選擇，並設計成描述性綱目。 需求轉換 主要將描述性綱目以系統模式語法轉換成概念性綱目。

7 圖3-1 需求分析之重要步驟

8 3.1 導論(4/5) Byrd等人(1992)指出，需求分析是使用者與系統分析師相互合作努力，將資訊系統所需的資料加以判斷和描述。需求分析階段之重要工作包括： 建立組織資訊處理需求 發展資訊系統目標 設計及評估資訊系統發展方案 整理系統分析師、其他分析師、使用者和其管理者溝通分析的結果 從事系統審核

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

10 3.1 導論 需求分析階段之重要工作包括： 瞭解現有問題 瞭解新系統目標 瞭解新系統之限制 瞭解使用者巨觀之需求等

11 定義問題 兩種處理態度 被動式(reaction)
在問題發生時，開始尋找問題發生的主因，然後尋求解決的方法。這種態度是一般人最常用的，也稱之為例外管理(management by exception)。 契機搜尋式(opportunistic surveillance) 採取較積極的態度，不斷尋找對於組織有利的機會，以尋求組織持續的改善。

12 應完成的工作內容 確定問題的主體 主要是要確定到底研究的是什麼問題？這個問題的內容是什麼？以及用什麼名稱來將此問題命名較為恰當。 了解問題發生的原因 主要是希望系統分析人員知悉問題發生的背景與原委。 確定要達成的目標 主要是明確地設定系統完成後，希望能達成的結果。目標定義明確可以避免系統分析人員在規劃新系統時產生方向偏差。

13 確定問題涵蓋的處理範圍 主要是讓系統分析人員知道問題的界限，如此可將問題單純化而變得易於解決，以避免在規劃的過程中遺漏了某些重要、應加以考慮的因素。

14 蒐集系統背景資料 資料來源分類 主要的資料來源 是指現場作業人員、系統操作人員、使用者、管理人員等相關人員 訪談與問卷調查 次要的資料來源
是指經由蒐集、分析所得到的文件資料，如與本系統有關的操作手冊、系統文件、作業程序、輸出入表單等。 文件 蒐集系統背景資料可藉由主要資料來源與次要資料來源兩方面資料的蒐集，使資料有較好的完整性。

15 蒐集系統背景資料的目的 是讓系統分析人員知道與系統相關的問題，以及各問題發生的因果關係，以便系統分析人員在往後系統開發時，能加以控制或解決。

16 3.2 需求擷取方式 在擷取使用者需求之前，必須先瞭解系統之潛在使用者及可能之人機互動。
接著蒐集欲電腦化之作業處理程序及其輸出入資料內容、數量、格式、目標、規則與限制等。 常用的需求擷取方式有查閱文件、觀察、問卷、訪談、開會討論與聯合開發六種，這些方式可單獨應用亦可互相搭配使用。

17 3.2.1 查閱文件 係指研究企業的內部文件，例如工作說明書(Job Description)、企業表單(Business Forms)與手冊(Manuals)等，是瞭解企業運作邏輯之初步工作。 然而，組織中很少有完整的文件能詳細描述系統全貌，再加上系統可能已經過多次修改，文件未能同步更新，所以文件與實際情況常有出入。 以此方式蒐集之資訊常有過時之慮。

18 3.2.2 觀察 一般來說，實地觀察所獲得的資料正確性會比查閱文件為高，亦能驗證所蒐集資料之正確性及補充不完整的部分，透過觀察可以獲得第一手的資料。 僅用觀察仍無法完整地反映出組織的真實情況與需求，例如被觀察者的行為可能改變。或無法長期持續的觀察，導致可能僅觀察部份或特定的區域，從而得到不完整的片段印象與看法。 選擇正常與例外情況之時機或對象來作觀察，可獲得各種可能的資料。(如買房子時選擇下雨天觀看)

19 3.2.3 訪談(1/7) 訪談是需求擷取方式中最有效且最普遍的資料蒐集方法。訪談時，系統分析師將親自與使用部門的主管或相關作業人員面對面討論實際作業的情況、所需報表和資訊需求等。 訪談期間，系統分析師蒐集到的可能是事實、選擇或推測，並可觀察到人們的肢體語言、情緒和他們對於現行系統之觀感。

20 3.2.3 訪談(2/7) 訪談可分成兩種方式： 開放式訪談(Open Interview)
系統分析師不事先預定表格、問卷或固定的標準程序，訪談過程全由使用者自由談論其工作。 主要應用在系統分析師對問題領域不熟悉的情況。 結構化訪談(Structured Interview) 又稱為標準化訪談或導向式訪談，其訪談過程近似詢問(Interrogation)而非交談(Conversation)，所要求資訊的深度與專業程度亦較深。 特點是把問題標準化，然後由受訪者回答或選擇。

21 3.2.3 訪談(3/7) 所有的受訪者都回答同一形式的問題，其作法如下：
每討論一個主題時，先由系統分析師依其現有瞭解的知識，提出簡短敘述。 使用者針對主題作深度分析，但系統分析師應在深入到適當程度時加以中止。 對某個主題有初步瞭解，就可以進行另一主題的訪談。

22 3.2.3 訪談(4/7) 訪談之問題依其性質可分成兩種： 開放性問題(如問答題)
用來探索系統分析師無法明確詢問受訪者或對受訪者之回答無法預期之問題。 優點： 能讓先前不知道的資訊浮現出來。 受訪者感覺較輕鬆。 受訪者有機會參與和控制整個訪談的過程。 缺點：回答問題所花的時間較長，也較難做結論。

23 3.2.3 訪談(5/7) 2. 封閉性問題(如選擇題、是非題) 適用於問題可預期且回答可明確描述之情況。
2. 封閉性問題(如選擇題、是非題) 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，討論的問題較廣泛。 缺點：所列之回答選項未必包含受訪者所要回答的答案。 封閉性問題有下列幾種設計形式： 對與錯的選擇方式。 多重選擇的方式。 李克特(Likert)量表的衡量方式。

24 3.2.3 訪談(6/7) 訪談前需有周詳的規劃。 一些有助於訪談進行之準則包括：
要仔細地聆聽受訪者的回答，同時將重點記錄下來，在得到允諾的情況下，還可以將訪問的內容用錄音機或錄影機錄下來，以有效地掌握訪談內容。 訪談結束後，須在48小時之內將訪談內容整理出來，因為經過48小時之後，訪談的內容會慢慢的從記憶中消失。

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

26 3.2.4 問卷(1/5) 當潛在使用者太多或分布太廣時，可考慮以問卷之方式擷取需求。
一般來說，問卷調查適合於大型企業或公眾資訊系統的設計，因為它所涉及的作業範圍或對象太廣，系統分析師無法逐一親自調查，故利用問卷方式來蒐集使用者需求較為可行。 設計一份好的問卷需有相當的練習與經驗，因為問卷上的問題是以文字靜態的表達，故問題之語意與邏輯必須很清楚且有條理。

27 3.2.4 問卷(2/5) 問卷設計時也可以用各種不同的方法來問同一個問題，以觀察各種可能的答案。 進行正式問卷調查前需有先導測試。
經由先導測試之檢討與回饋可進一步修飾問卷，及早發現問卷可能之問題，對提升問卷之效度有很大的幫助。 正式問卷調查時必須決定哪些族群是調查的對象。對象選取之抽樣方法主要分成： 機率抽樣(Probability Sampling) 非機率抽樣(Nonprobability Sampling)

28 3.2.4 問卷(3/5) 機率抽樣方法 簡單隨機抽樣(Simple Random Sampling)
將系統使用者的名單逐一給予編號，再以摸彩法或亂數表來抽樣，以決定哪些人將成為受測的對象。 分層抽樣(Stratified Sampling) 先將所有可能之系統使用者分成若干互斥的組或層，然後再從各組或各層中隨機抽選預定數目之使用者為受測對象。

29 3.2.4 問卷(4/5) 非機率抽樣方法 便利抽樣(Convenience Sampling)
以方便性為抽樣之主要考量，這些抽樣之對象可能是最容易找到的系統使用者、願意接受調查的人或是動機高的使用者。 判斷抽樣(Judgment Sampling) 又稱立意抽樣(Purposive Sampling)，係根據抽樣設計者的判斷來選擇受測之使用者。設計者必須對使用者之特徵有相當地瞭解，然後針對符合某些特徵的名單抽樣，例如針對使用系統已經兩年以上的使用者或者是經常使用的人。

30 3.2.4 問卷(5/5) 上述抽樣策略可單獨使用，亦可混合使用。當問卷回收後，應該逐一檢查回收問卷之回答是否完整，並去除異常之問卷，以便進行資料分析。 綜言之，問卷調查與訪談相比較，問卷調查的優點是成本比較低，蒐集的資料較為廣泛，但也有問卷回收率不高、問卷設計不易、答題人不願意依據事實填寫等缺點。此外，在資訊的內容上，問卷所獲得的資訊可能比訪談來得少。

31 3.2.5 開會討論 開會討論是一種很有效率的資料蒐集方式。使用者代表與系統開發人員齊聚一堂，將所知道的事實、觀念說出，讓與會人員一起相互溝通意見。 優點是較易獲得正確的資料，縱使有不正確的意見或觀念，經眾人研究後亦能加以修正。此外，多人同時聚集一起，可發揮腦力激盪的效果。 缺點是要安排共同的時間來進行，在溝通與協調上較困難。

32 3.2.6 聯合開發(1/5) 聯合開發(Joint Application Development, JAD)之主要精神，是透過一個2～5天的集會，讓開發者與顧客能夠快速、有效且深入地檢討需求，進而取得共識。 聯合開發的具體結果是產生完整的需求文件。

33 3.2.6 聯合開發(2/5) JAD 依下列五個步驟來進行(Wood and Silver, 1995)： 範圍界定 關鍵人員的熟悉
會議準備 會議進行 文件產生

34 3.2.6 聯合開發(3/5) 範圍界定 先由專案出資單位的高階主管定義專案範圍，以文字記載後，由高階主管和JAD 召集人一起簽訂契約。
關鍵人員的熟悉 JAD 召集人要花一些時間訪談關鍵性的使用者及管理人員，以瞭解專案的背景資料及重要的需求。

35 3.2.6 聯合開發(4/5) 會議準備 JAD 會議前的準備工作應包括下列項目： 整理需求文件草稿 分送需求文件草稿 安排助理人員
準備會議室 會議進行 會議進行時，召集人引導大家充分利用各種視覺上的輔助工具，如白板、圖表或簡報檔等，將使用者與企業需求表達出來，並做有效地溝通及達成共識。

36 3.2.6 聯合開發(5/5) 文件產生 最後階段須在2、3天內將JAD 會議所蒐集的需求，整理成需求文件。
最後再召開一次審查會議，確認需求文件的內容。

37 3.3 需求表達工具與方法(1/3) 企業員工每天需依企業程序(Business Procedure)執行處理活動，以完成企業功能(Business Function)。企業處理是指企業中最基本的活動單元，也就是說該活動已夠單純，不必再分割。 需求分析階段重點工作是先擷取使用者需求(或企業)的巨觀需求，並以使用者觀點應用具有完整定義的(Well-Defined)工具、圖形、或語言表達出來，再進一步對需求進行合理化，最後經由使用者確認，以作為系統分析與設計的基礎。 上述從使用者需求之擷取與修飾，並將最終需求以工具、圖形或語言表達之整體活動，稱為需求塑模(Requirement Modeling)。 以結構化之系統分析與設計而言，主要是考量企業流程塑模與資料塑模。

38 圖3-2 需求塑模 環 境 圖 流 程 圖 處 理 描 述 藍 圖 資 料 詞 彙

39 3.3 需求表達工具與方法(2/3) 流程塑模與資料塑模的工具包括： 環境圖(Context Diagram)
主要表達系統與所在環境之關係。 流程圖(Flow Chart) 主要表達實體之作業程序及所需資訊間之關係。 事件(Event) 表示外部實體所啟動且系統必須回應之刺激。 處理描述 表示流程圖中作業處理之執行程序與規則、相關之資料輸出入資訊以及處理之限制與備註。

40 3.3 需求表達工具與方法(3/3) 藍圖 (Drawing) 主要表示流程圖中資訊之展示格式與內容。例如表單之格線與縱橫項目。
資料詞彙 (Data Glossary) 主要描述藍圖內資訊之詳細內容與規則。

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

42 3.3.1 事件(2/3) 控制導向之事件是由非預設時間之某些刺激或狀態所引發。例如系統之開或關等
事件之集合稱為事件列(Event List)，一般來說，系統與外部實體之關係可用事件列來表示。 對資料流導向之事件其命名與編碼原則如下： 對每一外部實體給予一個唯一的名稱與編號。 事件以文句之方式命名，主詞為與系統互動之外部實體（行為者）或系統，是事件之起始者或參與者。動詞是外部實體或系統之動作，可描述事件要處理的工作。受詞表示事件完成之工作項目、表單或格式等。亦可將與主詞互動之外部實體放在句尾並括號之。此外，事件之命名要有意義，可使之一目了然。 事件之編碼可由啟動事件之外部實體編號加流水碼表示之，以方便辨識。 例如客戶下訂單（業務部）可編碼為A01。

43 3.3.1 事件(3/3) 事件最好亦能描述所涉及資料之內容。例如： 客戶下訂單之事件描述：
客戶以打電話、傳真、郵寄、或以Web-based系統向業務部下訂單。 業務部處理訂貨資料。 訂單主要內容為：客戶名稱、訂購日期、訂購產品之品名、規格、數量、交貨地點、交貨日期。

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

45 表3-1 環境圖之元件

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

47 3.3.2 環境圖(3/6) 處理與資訊流 處理與資訊流是以箭頭連結系統與外部實體，表示資訊之輸出入處理或事件之方向。
環境圖製作常以系統為中心，以星狀形式表示系統與外部實體之關係，並將兩者互動之事件列標示在箭頭上。環境圖中不表達資料儲存。 環境圖之建構步驟為： 整理事件條列式 找出外部實體 找出系統與外部實體之關係 繪製環境圖

48 3.3.2 環境圖(4/6) 整理事件條列式 將使用者與企業需求描述整理成更簡潔的事件條列式，其中應表達事件之起始者、動作及參與動作之物件等，描述格式可表達如下： 主詞＋動詞＋受詞 主詞是與系統互動之外部實體（行為者）或系統 動詞是外部實體或系統之動作，可描述事件要處理的工作 受詞表示件完成之工作項目、表單或格式等。

49 3.3.2 環境圖(5/6) 2. 找出外部實體 可從使用者與企業需求描述中之名詞、代名詞與名詞片語等，找出合乎外部實體定義的人、組織、物件或相關系統，也就是環境中與系統有互動或交換訊息之任何人或物。 3. 找出系統與外部實體之關係 由於系統與外部實體之關係可用事件列來表示，因此系統與外部實體之關係可由步驟(1)所整理出之簡潔的事件條列式來找出。

50 3.3.2 環境圖(6/6) 4. 繪製環境圖 繪製步驟為先繪出系統與所有外部實體，再將系統與外部實體間有互動者以箭頭線段連結。
4. 繪製環境圖 繪製步驟為先繪出系統與所有外部實體，再將系統與外部實體間有互動者以箭頭線段連結。 若一事件由外部實體所啟動，則關係之箭頭由外部實體指向系統；若一事件是由系統回應外部實體，則關係之箭頭由系統指向外部實體。 完成環境圖之繪製後，可用流程圖表達系統之執行順序。

51 夢幻系統環境圖 系統 客　　戶 業務部 主　　管 廠　　商 倉　　庫 生產部 將外部實體、系統及事件啟動與影響方向(箭頭)繪製成環境圖

52 3.3.3 流程圖(1/4) 流程圖(Flow Chart)為一圖形化表達工具，用以描述企業作業流程，其可分為系統流程圖及程式流程圖兩類。
系統流程圖(System Flow Chart)用以描述整個工作系統中，各單位之間的作業關係。 程式流程圖(Program Flow Chart)則用以表示程式中的處理過程。 程式流程圖是流程圖中較常用之表示方法，因此本節將介紹程式流程圖為主。

53 表3-2 流程圖之元件 (ANSI, 1970)

54 3.3.3.1 流程圖之元件(1/2) 作業處理(Processing) 為真實世界的一個動作處理、一組動作程序、或是可執行的一段副程式。
一個作業處理是流程的基本單位，不能再被分解且此動作之執行不能被中斷。 作業處理以矩形表示，內部標示流程名稱。 決策(Decision) 是用於表達有多個選擇路徑，但僅能依條件選擇其中一個路徑執行，條件通常包含Yes/No或True/False這類的問題。 決策是以一菱形外加一條流入菱形之箭頭與多條流出菱形之箭頭表示。

55 3.3.3.1 流程圖之元件(2/2) 報告(Report) 可用於描述某一個流程之輸出入資訊。 流程方向(Flow of Control)
用以表達控制流。 接點(Connector) 當流程圖過於龐大或複雜時，可使用接點(Connector)將流程圖轉到另一頁，此舉可避免流程方向之箭頭交叉，亦可避免流程太過冗長，增加流程圖之易讀性。 註解(Annotation) 用以表達流程圖之補充與說明。

56 流程圖製作程與準則 流程圖之建構步驟包括： 找出外部實體 找出作業處理 檢視外部實體 繪製流程圖 檢視流程圖

57 3.3.3 流程圖(2/4) 找出外部實體 流程圖之外部實體即環境圖之外部實體，每一流程圖必有起始之外部實體及與之互動的其他外部實體。可由事件條列式整理出該流程所涉及之實體，例如人、團隊、組織、部門或其他系統。 找出作業處理 先整理出系統範圍內所涉及之企業功能或企業程序，企業功能盡可能再分解成有意義且有關聯的企業處理(Business Process)。 作業處理可由執行該處理或與該處理有互動關係的實體來找出，每一處理應有清楚的輸入，新增或修改後的資料為其輸出。

58 3.3.3 流程圖(3/4) 找出作業處理，如在進銷存系統中，其企業流程之基本單元可定為訂單處理與送貨處理，訂單處理之輸入為訂單，而其輸出是否要送貨或生產通知等，盡量避免用銷貨處理，因為銷貨處理可能包含訂貨與送貨等工作。 檢視外部實體 逐一檢討每一實體，以找出會主動引發刺激(Stimuli)或事件(Event)之主要實體。一個主要實體可能會有一至多個主動刺激，並由每一刺激或事件開始找出其所引發之一系列高度相關之處理步驟，以形成一個流程圖。例如訂單處理後會緊接著送貨處理，因此兩者應在同一流程圖中。

59 3.3.3 流程圖(4/4) 繪製流程圖 繪製流程圖時，應由流程圖之上方或左上方開始畫起，接著依企業作業流程之發生順序畫出作業處理及流程方向，而在流程的最後以一結束符號作為流程之結束。 檢視流程圖 檢查所有流程圖之完整性，也就是所有流程圖是否涵蓋整個系統範圍。

60 3.3.4 處理描述 流程圖雖可表達實體與作業處理之程序及所需資訊間之關係，但無法表達每一處理之內部行為。
處理描述進一步地表達每個處理之執行步驟、規則、控制等，並說明其資料之輸入和輸出內容與所涉及之外部實體。 每個處理描述之名稱應與流程圖中之作業處理同名，處理描述之表達形式可如下所示。 處 理 描 述 樣 板

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

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

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

64 3.3.6 資料詞彙(3/3) 客戶訂單＝客戶名稱 ＋訂單編號 ＋〔送貨地址｜自行取貨〕 ＋（售貨員） ＋｛訂單項目｝
以下範例說明客戶訂單的資料元素可被定義成如下之組合(Composition)、架構(Structure)及意義(Meaning)： 定義客戶訂單後，需再對其中之資料元素提供適當的說明。因此，資料字典應再包含對訂單項目的定義。例如： 客戶訂單＝客戶名稱 　　　　　＋訂單編號 　　　　　＋〔送貨地址｜自行取貨〕 　　　　　＋（售貨員） 　　　　　＋｛訂單項目｝ 訂單項目＝零件號碼＋（零件名稱）＋數量＋單價＋（折扣）

65 3.4 需求分析結果與文件樣板(1/2) 完成需求分析與確認後，需求分析結果之文件應包括該階段中重要工作結果之摘述。
需求分析結果之文件樣板如下：

66 3.4 需求分析結果與文件樣板(2/2) 完成需求分析與確認後，需求分析之文件至少須包括該階段所屬重要工作結果之描述：
問題描述：描述目前電腦化系統及人工作業系統、作業上的問題、缺少的功能、超出的成本、生產率問題與可靠度問題等，並排出其重要性或解決之優先順序。 新系統目標：針對上述問題描述新系統欲完成之功能、補救之缺陷即將增加或修改之特色。 新系統限制：新系統須能在所描述的限制內完成目標，限制可來自高層管理者、使用者、生產率…。 使用者需求：以流程圖配合處理描述、藍圖及資料辭彙等工具表達使用者巨觀之需求。

67 3.5 需求分析個案 需求分析依3.1節概念分為需求擷取與需求轉換兩大步驟，其中，需求轉換主要以流程圖配合藍圖、資料詞彙與環境圖等進行需求塑模。 本節將以一「鉦鈦有限公司之ERP導入系統（以下簡稱鉦鈦系統）」為例，針對其使用者與企業巨觀需求，介紹如何以環境圖、流程圖、處理描述、藍圖與資料詞彙表達其欲電腦化的環境、作業程序與範圍、輸入與輸出所需資訊或表單及系統目標、限制和主要功能。

68  3.5.1 案例介紹與需求描述(1/4) 系統開發背景 鉦鈦公司從事國際間廢鐵進出口暨汽機車零件買賣，其為掌握市場，決定建置一管理資訊系統，並將系統委由WULAB 公司進行資訊系統之開發。 鉦鈦公司之專案指導團隊與WULAB 公司之專案開發團隊經多次討論，將鉦鈦系統的目標與限制、使用者與企業需求描述分別整理如下：

69  3.5.1 案例介紹與需求描述(2/4) 系統目標與限制 建立一Web-based管理資訊系統，使鉦鈦公司之客戶、生產部與業務部能在線上完成所有的營運管理。 此管理資訊系統須提供表單資料維護的功能。 鉦鈦公司之客戶、生產部與業務部不論使用哪一種瀏覽器上網，須看到相同的介面，並於權限內執行所有的操作功能。

70 3.5.1 案例介紹與需求描述(3/4) 使用者與企業需求描述
 3.5.1 案例介紹與需求描述(3/4) 使用者與企業需求描述 客戶以系統新增訂單後，由業務部負責接收。當接到客戶的訂貨通知時，須先進行訂貨資料登錄，並作成品庫存檢核。若成品庫存不足，則傳送生產需求通知生產部，以便進行生產計畫。 若成品庫存充足，則業務部直接進行送貨處理，如計算送貨總金額、遞送成品等，並傳送送貨單給客戶確認。 業務部收到客戶欲退回已銷售之成品通知（銷退單），需記錄客戶編號及銷退之成品數量、單價，並計算銷退單之銷退總金額等。

71 3.5.1 案例介紹與需求描述(4/4) 業務部向客戶請款： 針對各客戶之本期送貨資料，計算出本期應收帳款。
 3.5.1 案例介紹與需求描述(4/4) 業務部向客戶請款： 針對各客戶之本期送貨資料，計算出本期應收帳款。 每月請款一次，請款日期為每月25日。 合計上期未收款項及本期應收帳款後，傳送請款單請客戶付款。 業務部收到客戶之付款證明，登錄客戶編號及付款資料後，儲存該次登帳紀錄（付款單）。

72  3.5.2 需求塑模—建構環境圖(1/3) 整理事件條列式，如表3-7所示。

73  3.5.2 需求塑模—建構環境圖(2/3) 找出外部實體 由使用者與企業需求描述中之名詞、代名詞與名詞片語等，找出合乎外部實體定義的人、組織、物件或相關系統。 上表之更簡潔事件條列式中的名詞包括客戶、訂單、業務部、訂貨通知、訂貨資料、成品庫存、生產需求、生產部等，其中只有客戶、業務部和生產部與系統有互動關係，合乎外部實體的定義，為本案例中之外部實體。

74 3.5.2 需求塑模—建構環境圖(3/3) 找出系統與外部實體之關係
 3.5.2 需求塑模—建構環境圖(3/3) 找出系統與外部實體之關係 系統與外部實體之關係可由更簡潔的事件條列式來找出，例如第一項事件條列式是由客戶所啟動，其他事件條列式以此類推。 繪製環境圖 完成事件之整理工作並找出外部實體及其與系統之關係後，便可將外部實體與系統繪製成環境圖，將事件編號並依外部實體啟動與被影響實體之方向將事件條列式標示於箭頭上。

75 圖3-3鉦鈦資訊系統環境圖 A01.客戶＋新增＋訂單 A03.客戶＋新增＋銷退單 A05.客戶＋新增＋付款證明 …

76 3.5.3 需求塑模—建構流程圖(1/6) 建構流程圖之步驟依序為： 找出外部實體 找出作業處理 檢視外部實體 繪製流程圖 檢視流程圖

77 3.5.3 需求塑模—建構流程圖(2/6) 由使用者與企業需求描述和事件條列式得知，前兩項作業可連續發生，也就是客戶訂貨，若無足夠庫存，則進行生產計畫；若有足夠庫存，則可馬上送貨，其餘三項作業均各自獨立。 可將前兩項使用者與企業需求合併為訂單送貨流程，而其餘三項需求分別為銷退處理流程、請款處理流程與登帳處理流程。 以訂單送貨流程為例，其流程圖、處理描述、藍圖和詞彙說明如下。

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

79 圖3-4 訂單送貨流程圖 流程圖1

80 3.5.3 需求塑模—建構流程圖(4/6) 處理描述1-1 以訂單送貨流程之訂單處理為例（參考圖3-4），其資料來源為客戶之訂單，且產出為生產部之生產需求或進行送貨處理。 訂單處理之處理描述名稱可命名為訂單處理與庫存判斷，該處理描述與庫存判斷之執行程序與規則，可從上述需求描述摘述如表3-8。 流程圖中，每一處理應有一處理描述，每一處理描述應有一致的表達格式。

81 表3- 8 訂單處理描述 處理描述1-1

82 3.5.3 需求塑模—建構流程圖(5/6) 藍圖1-1 以訂單送貨流程之訂單為例，其藍圖基本上可以該公司目前之訂單報表為基礎，再進一步對訂單上的每一欄位，以由上而下、由左至右之原則編號，例如客戶編號為A、地址為B，依序至總金額為O等，詳如右表所示。 鉦鈦有限公司

83 3.5.3 需求塑模—建構流程圖(6/6) 資料詞彙1-1 每張藍圖應有一份資料詞彙，且藍圖中之每一欄位在資料詞彙中應有一記錄描述之。
因此以鉦鈦公司之訂單藍圖為例（參表3-9），採用資料詞彙樣板（參表3-4），再經由訪談整理後，其訂單藍圖之資料詞彙可整理如表3-10。

84 表3-10 訂單資料詞彙 資料詞彙1-1

85 圖3-5 銷退處理流程圖 流程圖2 客 戶 業 務 部 銷退單 銷退處理 銷退紀錄

86 表3-11 銷退處理描述 處理描述2-1 錄客戶編號及銷退之成品數量、單價、並計算銷退單之 銷退總金額。 處理名稱 銷退處理 執行程序與規則
表3-11 銷退處理描述 處理描述2-1 處理名稱 銷退處理 執行程序與規則 業務部收到客戶預退回以銷售之成品通知(銷退單)，須記 錄客戶編號及銷退之成品數量、單價、並計算銷退單之 銷退總金額。 資料輸入／來源 銷退單／客戶 資料輸出／目的地 銷退紀錄／業務部 限制與備註

87 圖3-6 請款處理流程圖 流程圖3 業 務 部 客 戶 送貨資料記錄 請款單 請款處理

88 表3-12 請款處理描述 處理描述3-1 2. 每月請款一次，請款日期為每月25日。 3.合計上期為收款項及本期應收帳款後，傳送請款單
表3-12 請款處理描述 處理描述3-1 處理名稱 請款處理 執行程序與規則 1. 針對各客戶之本期送貨資料，計算出本期應收帳款。 2. 每月請款一次，請款日期為每月25日。 3.合計上期為收款項及本期應收帳款後，傳送請款單 請客戶付款。 資料輸入／來源 送貨資料記錄／業務部 資料輸出／目的地 請款單／客戶 限制與備註

89 表3-13 請款單藍圖 藍圖3-1 鉦 鈦 有 限 公 司 請款單 第 17 頁 請款日期 A － B 列印日期 客戶名稱 C 住 址 D
表3-13 請款單藍圖 藍圖3-1 鉦 鈦 有 限 公 司 請款單 第 17 頁 請款日期 A － B 列印日期 客戶名稱 C 住 址 D 送貨單編號 送貨單日期 送貨單金額 E F G /01/ ,200 /02/ ,500 /02/ ,900 本期應收 H 上期未收 I 合 計 J

90 表3-14 請款單資料詞彙 資料詞彙3-1 編號 欄位名稱 長度/型態 鍵 規則/格式/範圍/公式 範例 A 請款開始日期 Date
表3-14 請款單資料詞彙 資料詞彙3-1 編號 欄位名稱 長度/型態 鍵 規則/格式/範圍/公式 範例 A 請款開始日期 Date YYYY/MM/DD 2009/08/02 B 請款結束日期 C 客戶名稱 Char(30) 立大 D 地址 Char(50) 高雄市蓮海路30號 E 送貨單編號 Char(8)  年+月+日+流水號 YYMMDD01~ YYMMDD99 F 送貨單日期 2009/01/13 G 送貨單金額 Int(21) 6,200 H 本期應收 Int(22) 送貨單金額總合 33,600 I 上期未收 上期未收送貨單金額總合 10,000 J 合計 Int(23) 本期應收+上期未收 43,600

91 圖3-7 登帳處理流程圖 流程圖4 客 戶 業 務 部 付款證明 登帳處理 付款單

92 表3-15 登帳處理描述 處理描述4-1 後，儲存該次登帳紀錄(付款單)。 處理名稱 登帳處理 執行程序與規則
表3-15 登帳處理描述 處理描述4-1 處理名稱 登帳處理 執行程序與規則 業務部收到客戶之付款證明，登錄客戶編號及付款資料 後，儲存該次登帳紀錄(付款單)。 資料輸入／來源 付款證明／客戶 資料輸出／目的地 付款單／業務部 限制與備註

93 3.6 結論(1/2) 需求分析的過程主要是擷取與表達使用者之巨觀需求，這包括欲電腦化之環境、作業處理、輸出與輸入所需之資訊或表單與系統主要功能等。 需求分析階段對問題領域之瞭解範圍應盡可能地廣泛，到了分析與設計階段再縮小到專案範圍，如此有助於對新系統之瞭解與規劃。

94 3.6 結論(1/2) 以目前之開發工具來說，需求分析工作約占整個專案時間的25%左右，且需求分析往往無法在一個階段內完全做完，常在分析與設計階段仍有需求分析工作之進行。 系統分析師之專業知識與經驗，對需求分析之成效有密切之影響。

95 補充 －－ 可行性研究 可行性研究的目的 可行性研究的評估層面 可行性研究的文件製作

96 可行性研究的目的 可行性研究的目的 是根據系統的需求，分析問題的特性與範圍，並估算系統發展所需的各項資源、費用成本以及工作時程，藉此評價系統是否有繼續進行的價值，對現行環境適不適合或可不可行。

97 可行性研究的評估層面 五種可行性評估層面：

98 技術可行性(technical feasibility)
目的 在於評估完成新系統的技術是否專案人員有能力可以達成，以及進行此新系統所冒的風險。 內容 新系統目標所需要的週邊設備是否已經具備？ 開發新系統所需要的技術，專案小組成員是否已經具有開發之能力？ 新系統所需要的效能是否可以達成？ 是否有其他人員可以提供我們相關支援，來完成這個系統？

99 經濟可行性(economic feasibility)
目的 在於評估新系統經濟效益方面的得失，以便公司高階主管判斷值不值得投資，其重點在於公司的成本效益分析。 內容 評估推行此系統所需增加的費用支出與以後的使用費用。 評估系統完成後，對現行作業之效益分析與實質服務品質的改善。 比較前項之開發成本與後項之運轉效益，並評估系統的得失。

100 法律可行性(legal feasibility)
目的 在於評估新系統進行的內容是否違反了現行的法令。 內容 新系統的內容是否為現行法令所不允許？ 是否侵犯了他人的權益？ 是否違反了著作權法或智慧財產權？ 軟體開發契約的訂立，與雙方的權利與義務？

101 作業可行性(operational feasibility)
目的 在於評估新系統的推行是否為使用者所接受？是否管理階層同意？現行作業是否可以配合。 內容 所推行的系統對現行作業環境的影響。 系統是否為使用者所接受？ 管理階層是否接受此專案？是否支持？是否能配合實施？

102 時程可行性(schedule feasibility)
目的 在於評估新系統是否能於預估的時限內完成。 內容 系統開發的工作時程安排是否合理？ 系統工作時程的安排專案小組成員是否可以如期完成？ 系統完工之時效性是否可以被管理人員接納？

103

104 可行性研究的文件製作 可行性研究的步驟 成立負責專案小組 蒐集與系統有關的資料 設計各種可行性方案 評估各種可行性方案 選擇最適可行性方案
撰寫可行性研究報告

105 可行性研究報告撰寫的目的 主要在於將可行性研究之內容、結果與建議，以文字的表達方式，呈給公司最高管理階層主管審閱，供最高階層主管用以判斷應採取的方案，同時，也讓公司最高階層主管了解所選擇的方案對組織的影響。

106 可行性研究報告的內容 緒論 說明此可行性研究的目的與研究的範圍、系統的緣由以及為什麼會有這個專案。 系統目標與需求 說明系統的目標，要具備那些功能？需要的操作條件如何？完工的期限是什麼時候？公司願意提供的開發經費是多少。 現行作業說明 說明目前組織的結構如何？現行組織的工作環境如何？與系統有關的現行作業有那些？現行組織的工作環境中有那些軟體、硬體設備？

107 可行性方案研擬與說明 列出符合前述系統需求的可行性方案，說明各可行性方案的架構與內容、各方案的軟硬體設備需求、各方案所需的經費以及各方案的工期如何。 可行性方案評估 將前述列舉的可行性方案，依照可行性研究的判斷條件逐項評估，評估的項目必需包含有技術可行性、經濟可行性、法律可行性、作業可行性、時程可行性。在本節中，必須詳細說明各方案的評估結果。

108 結論與建議 說明專案小組的評估結果，建議公司應選擇的方案，並說明為何選擇此方案，此方案對公司的影響層面如何？同時並對公司未來可採取的措施，提出具體的建議。 參考資料 列出在此報告中曾經參考過的資料與書目，必須詳細列出參考資料的出處。 附錄 敘述報告本文中所不足而需要補充的內容。

109 一、系統簡介 1.1 簡述 1.2 系統目標 1.3 系統範圍 1.4 系統主要功能 二、現行作業分析 2.1 現行組織圖 2.2 各相關單位作業說明 2.3 現行環境的軟硬體架構 三、可行性方案研擬與說明 3.1 各項方案說明 3.1.1 方案構想說明 3.1.2 方案架構 3.1.3 方案的軟硬體需求 3.1.4 方案運作的環境與流程 3.2 各項方案評估 3.2.1 技術可行性 3.2.2 經濟可行性 3.2.3 法律可行性 3.2.4 作業可行性 3.2.5 時程可行性 四、結論與建議 參考資料 附錄