第三章需求擷取與分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

54、，將事件編號並依外部實(shí)體啟動(dòng)與被影響實(shí)體之方向?qū)⑹录l列式標(biāo)示於箭頭上。,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àn)椋赫页鐾獠繉?shí)體找出作業(yè)處理檢視外部實(shí)體繪製流程圖檢視流程圖,3.5.

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

56、境圖得知，在訂單送貨流程中，有三個(gè)外部實(shí)體參與，分別為：客戶、業(yè)務(wù)部與生產(chǎn)部。前兩項(xiàng)作業(yè)中有訂貨與送貨兩個(gè)基本作業(yè)處理、一個(gè)庫存檢核控制，以及產(chǎn)出三張基本表單：訂單、送貨單與生產(chǎn)需求。首先由客戶送出訂單來起始該流程，接著業(yè)務(wù)部進(jìn)行訂單處理、庫存檢核與送貨處理或輸出生產(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)需求或進(jìn)行送貨處理。訂單處理之處理描述名稱可命名為訂單處理與庫存判斷，該處理描述與庫存判斷之執(zhí)行程序與規(guī)則，可從上述需求描述摘述如表3-8。流程圖中，每一處理應(yīng)有一處理描述，每一處理描述應(yīng)有一致的表達(dá)格式。,表3- 8 訂單處理描述,處理描述1-1,3.5.3 需求塑?！?gòu)流程圖(5/6),藍(lán)圖1-1以訂單送貨流程之訂單為例，其藍(lán)圖基本上可以該公司目

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

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

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

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

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

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

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

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

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

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

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

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