需求撷取与分析课件

1、第三章 需求擷取與分析內容大綱學習目標第一節 導論第二節 需求擷取方式第三節需求表達工具第四節 需求分析個案第五節 需求分析之重要工作與文件樣板第六節 結論 學習目標詳讀本章，你至少能瞭解：常見的六種需求擷取方式及其執行要點。以流程圖為主之需求表達工具與這些工具之表達原則。需求分析之步驟與應注意之事項。需求分析之重要工作與文件樣板。 導論所謂使用者需求，係指使用者期待系統解決的問題與希望從系統獲得之資訊。使用者需求是資訊系統開發最關鍵、最重要且最容易發生錯誤的部分，亦是資訊系統失敗的主因之一。需求分析是資訊系統發展過程中之一項非常重要的活動，亦是一個重要之階段。理論上，該階段之主要工作是應用已

2、通過驗證之原理、技術、語言與工具，以幫助系統分析師瞭解問題或描述新系統之外部行為。導論 （續）Hooper 與 Hsia (1982)認為需求分析階段主要包括三個活動： 需求判斷：強調如何判斷真正的需求及需求的正確性。 需求分析：重視在分析已有的需求下所產生的不一致、不完整、矛盾等問題。 需求溝通：重視以最佳的方式組織及描述需求，使需求容易令人瞭解，並經由相互溝通達到需求確認的目的。 導論 （續1）Grosz(1992)認為，需求分析階段可分為兩大步驟：需求擷取與需求轉換（如圖 3-1）。 需求擷取主要是對系統範圍內之各種事物與相關現象，加以瞭解、判斷及選擇，並設計成描述性綱目。需求轉換主要將

3、描述性綱目以系統模式語法轉換成概念性綱目。圖3-1 需求分析之重要步驟擷取轉換各種事物現象描述性綱目概念性綱目導論 （續2）Byrd等人(1992)指出，需求分析是使用者與系統分析師相互合作努力，將資訊系統所需的資料加以判斷和描述，其主要工作內容包括： 建立組織資訊處理需求。發展資訊系統目標。設計及評估資訊系統發展方案。整理資訊系統分析師與上級、其它分析師及使用者溝通分析的結果。從事系統審核。導論 （續3）使用者需求可分為巨觀需求與微觀需求。巨觀需求包括欲電腦化之環境、作業程序與範圍、輸出與輸入所需之資訊或表單及系統目標、限制、主要功能等，這些需求應盡可能的在需求分析階段中釐清與確定。微觀需求

4、指的是電腦化之微觀範圍，可包括使用者介面之要求、例外狀況之處理與錯誤及輔助訊息之顯示等要求，這些需求通常需到設計階段才較容易處理，在此之前這些細部需求不易被掌握。導論 （續4）需求分析階段之重要工作包括：瞭解現有問題瞭解新系統目標瞭解新系統之限制瞭解使用者巨觀之需求等可行性研究 可行性研究的目的可行性研究的評估層面可行性研究的文件製作可行性研究的目的可行性研究的目的是根據系統的需求，分析問題的特性與範圍，並估算系統發展所需的各項資源、費用成本以及工作時程，藉此評價系統是否有繼續進行的價值，對現行環境適不適合或可不可行。可行性研究的評估層面五種可行性評估層面：技術可行性(technical fe

5、asibility)目的在於評估完成新系統的技術是否專案人員有能力可以達成，以及進行此新系統所冒的風險。內容新系統目標所需要的週邊設備是否已經具備？開發新系統所需要的技術，專案小組成員是否已經具有開發之能力？新系統所需要的效能是否可以達成？是否有其他人員可以提供我們相關支援，來完成這個系統？經濟可行性(economic feasibility)目的在於評估新系統經濟效益方面的得失，以便公司高階主管判斷值不值得投資，其重點在於公司的成本效益分析。內容評估推行此系統所需增加的費用支出與以後的使用費用。評估系統完成後，對現行作業之效益分析與實質服務品質的改善。比較前項之開發成本與後項之運轉效益，並評

6、估系統的得失。法律可行性(legal feasibility)目的在於評估新系統進行的內容是否違反了現行的法令。內容新系統的內容是否為現行法令所不允許？是否侵犯了他人的權益？是否違反了著作權法或智慧財產權？軟體開發契約的訂立，與雙方的權利與義務？作業可行性(operational feasibility)目的在於評估新系統的推行是否為使用者所接受？是否管理階層同意？現行作業是否可以配合。內容所推行的系統對現行作業環境的影響。系統是否為使用者所接受？管理階層是否接受此專案？是否支持？是否能配合實施？時程可行性(schedule feasibility)目的在於評估新系統是否能於預估的時限內完成。

7、內容系統開發的工作時程安排是否合理？系統工作時程的安排專案小組成員是否可以如期完成？系統完工之時效性是否可以被管理人員接納？可行性研究的文件製作可行性研究的步驟成立負責專案小組蒐集與系統有關的資料設計各種可行性方案評估各種可行性方案選擇最適可行性方案撰寫可行性研究報告可行性研究報告撰寫的目的主要在於將可行性研究之內容、結果與建議，以文字的表達方式，呈給公司最高管理階層主管審閱，供最高階層主管用以判斷應採取的方案，同時，也讓公司最高階層主管了解所選擇的方案對組織的影響。 可行性研究報告的內容緒論說明此可行性研究的目的與研究的範圍、系統的緣由以及為什麼會有這個專案。系統目標與需求說明系統的目標，要

8、具備那些功能？需要的操作條件如何？完工的期限是什麼時候？公司願意提供的開發經費是多少。現行作業說明說明目前組織的結構如何？現行組織的工作環境如何？與系統有關的現行作業有那些？現行組織的工作環境中有那些軟體、硬體設備？可行性方案研擬與說明列出符合前述系統需求的可行性方案，說明各可行性方案的架構與內容、各方案的軟硬體設備需求、各方案所需的經費以及各方案的工期如何。可行性方案評估將前述列舉的可行性方案，依照可行性研究的判斷條件逐項評估，評估的項目必需包含有技術可行性、經濟可行性、法律可行性、作業可行性、時程可行性。在本節中，必須詳細說明各方案的評估結果。結論與建議說明專案小組的評估結果，建議公司應選

9、擇的方案，並說明為何選擇此方案，此方案對公司的影響層面如何？同時並對公司未來可採取的措施，提出具體的建議。參考資料列出在此報告中曾經參考過的資料與書目，必須詳細列出參考資料的出處。附錄敘述報告本文中所不足而需要補充的內容。 一、系統簡介 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

10、技術可行性 3.2.2 經濟可行性 3.2.3 法律可行性 3.2.4 作業可行性 3.2.5 時程可行性 四、結論與建議 參考資料 附錄定義問題兩種處理態度被動式(reaction)在問題發生時，開始尋找問題發生的主因，然後尋求解決的方法。這種態度是一般人最常用的，也稱之為例外管理(management by exception)。契機搜尋式(opportunistic surveillance)採取較積極的態度，不斷尋找對於組織有利的機會，以尋求組織持續的改善。 應完成的工作內容確定問題的主體主要是要確定到底研究的是什麼問題？這個問題的內容是什麼？以及用什麼名稱來將此問題命名較為恰當。了解

11、問題發生的原因主要是希望系統分析人員知悉問題發生的背景與原委。確定要達成的目標主要是明確地設定系統完成後，希望能達成的結果。目標定義明確可以避免系統分析人員在規劃新系統時產生方向偏差。確定問題涵蓋的處理範圍主要是讓系統分析人員知道問題的界限，如此可將問題單純化而變得易於解決，以避免在規劃的過程中遺漏了某些重要、應加以考慮的因素。蒐集系統背景資料資料來源分類主要的資料來源是指現場作業人員、系統操作人員、使用者、管理人員等相關人員訪談與問卷調查次要的資料來源是指經由蒐集、分析所得到的文件資料，如與本系統有關的操作手冊、系統文件、作業程序、輸出入表單等。文件蒐集系統背景資料可藉由主要資料來源與次要資

12、料來源兩方面資料的蒐集，使資料有較好的完整性。蒐集系統背景資料的目的是讓系統分析人員知道與系統相關的問題，以及各問題發生的因果關係，以便系統分析人員在往後系統開發時，能加以控制或解決。需求擷取方式在擷取使用者需求之前，必須瞭解系統之潛在使用者及可能之人機互動。常用的需求擷取方式有查閱文件、觀察、問卷、訪談、開會討論與聯合開發等六種，這些方式可單獨應用亦可混合使用。查閱文件研究企業的內部文件，例如工作說明書(Job Description)、企業表單(Business Forms)與手冊(Manuals)等，是瞭解企業運作邏輯之初步工作。 一般來說，組織中很少有完整的文件詳細地描述出系統之全貌，

13、加上系統可能已經過多次的修改，文件往往未能配合更新，因此以該方式蒐集之資訊常有過時之慮。 觀察一般來說，實地觀察所獲得的資料正確性會比查閱文件為高，亦能驗證所蒐集資料之正確性及補充不完整的部分，透過觀察可以獲得第一手的資料。僅用觀察仍無法完整地反映出組織的真實情況與需求，例如被觀察者的行為可能改變。或無法長期持續的觀察，導致可能僅觀察部份或特定的區域，從而得到不完整的片段印象與看法。選擇正常與例外情況之時機或對象來作觀察，可獲得各種可能的資料。(如買房子時選擇下雨天觀看) 訪談訪談是系統分析最有效且最普遍的資料蒐集方法。訪談時，系統分析師親自與使用部門的主管或相關作業人員面對面討論實際作業的情

14、況、報表和資訊需求等。 在訪談期間，系統分析師蒐集到的可能是事實、選擇或推測，並且可觀察到人們的肢體語言、情緒和他們對於現行系統之觀感等。 訪談（續）訪談可分成兩種方式：開放式訪談(Open Interview)結構化訪談(Structured Interview)開放式訪談系統分析師事先不預定表格、問卷或固定的標準程序，訪談過程全由使用者自由談論其工作。 適用於系統分析師對問題領域不熟悉或無法預期之情況。訪談 （續1）結構化訪談結構化訪談又稱為標準化訪談或導向式訪談，其訪談過程近似於詢問(Interrogation)而非交談(Conversation)，所要求資訊的深度、專門程度亦較深。這種

15、方式的特點是把問題標準化，然後由受訪者回答或選擇。訪談（續2）所有的受訪者都回答同一形式的問題，其作法如下：每討論一個主題時，先由系統分析師依其現有瞭解的知識，提出簡短敘述。使用者針對主題作深度分析，但系統分析師應在深入到適當程度時加以中止。對某個主題有初步瞭解，就可以進行另一主題的訪談。訪談（續3）訪談之問題依其性質可分成開放性與封閉性問題兩種：開放性問題(如問答題)用來探索系統分析師無法預期的回答或明確詢問之問題。優點：能讓先前不知道的資訊浮現出來，系統分析師可以用一些非預期中的問題，不斷地來探究新的資訊。缺點：回答問題所花的時間較長，也較難作結論。訪談（續4）封閉性問題(如選擇題、是非題

16、)適用於問題可預期且回答可明確描述之情況。優點：訪談的時間較短，問題可較廣泛。缺點：所列之選項未必包含受訪者所要回答的答案。訪談 （續5）封閉性問題可以有下列幾種設計形式：對與錯的選擇方式。多重選擇的方式。Likert尺度的衡量方式。用一些級距來衡量受訪者意見的強弱程度，例如用很好、好、普通、差與很差五個等級。訪談 （續6）訪談前需有周詳的規劃。一些有助於訪談進行之準則包括：要仔細地聆聽受訪者的回答，同時將重點記錄下來，在得到允諾的情況下，還可以將訪問的內容用錄音機或錄影機錄下來，以有效地掌握訪談內容。訪談結束後，須在48小時之內將訪談內容整理出來，因為經過48小時之後，訪談的內容會慢慢的從記

17、憶中消失。 訪談（續7）不管是面對開放性或是封閉性的問題，系統分析師不要強調問題答案的對或錯。 在訪談時，不要對新的系統做任何預期的想法。需讓受訪者知道他們的意見會被仔細地考慮，並讓受訪者知道專案的完成需要很多的步驟，同時還有很多人的觀點都需要一起考慮。從系統潛在的使用者、管理者與對現行系統有經驗的專業人員等尋找各式各樣的觀點，以對新系統做全盤性的瞭解，如此才能設計出大多數使用者都可接受的系統。問卷當潛在使用者太多或分布太廣時，可考慮以問卷之方式擷取需求。一般來說，問卷調查適合於大型企業或公眾資訊系統的設計，因為它所涉及的作業範圍或對象太廣，系統分析師無法逐一親自調查，故利用問卷方式來蒐集使用

18、者需求較為可行。設計一份好的問卷需有相當的練習與經驗，因為問卷上的問題是以文字靜態的表達，故問題之語意與邏輯必須很清楚且有條理。 問卷（續）問卷設計時也可以用各種不同的方法來問同一個問題，以觀察各種可能的答案。進行正式問卷調查前需有先導測試。經由先導測試之檢討與回饋可進一步修飾問卷，及早發現問卷可能之問題，對提升問卷之效度有很大的幫助。正式問卷調查時必須決定哪些族群是調查的對象。對象選取之抽樣方法主要分成：機率抽樣(Probability Sampling)非機率抽樣(Nonprobability Sampling)問卷（續1） 機率抽樣方法簡單隨機抽樣(Simple Random Sampl

19、ing)將系統使用者的名單逐一給予編號，再以摸彩法或亂數表來抽樣，以決定哪些人將成為受測的對象。分層抽樣(Stratified Sampling)先將所有可能之系統使用者分成若干互斥的組或層，然後再從各組或各層中隨機抽選預定數目之使用者為受測對象。問卷 （續2）非機率抽樣方法便利抽樣(Convenience Sampling)以方便性為抽樣之主要考量，這些抽樣之對象可能是最容易找到的系統使用者、願意接受調查的人或是動機高的使用者。判斷抽樣(Judgment Sampling)又稱立意抽樣(Purposive Sampling)，係根據抽樣設計者的判斷來選擇受測之使用者。設計者必須對使用者之特徵

20、有相當地瞭解，然後針對符合某些特徵的名單抽樣，例如針對使用系統已經兩年以上的使用者或者是經常使用的人。 問卷 （續3）上述抽樣策略可單獨使用，亦可混合使用。當問卷回收後，應該逐一檢查回收問卷之回答是否完整，並去除異常之問卷，以便進行資料分析。綜言之，問卷調查與訪談相比較，問卷調查的優點是成本比較低，蒐集的資料較為廣泛，但也有問卷回收率不高、問卷設計不易、答題人不願意依據事實填寫等缺點。此外，在資訊的內容上，問卷所獲得的資訊可能比訪談來得少。開會討論開會討論是一種很有效率的資料蒐集方式。使用者代表與系統開發人員齊聚一堂，將所知道的事實、觀念說出，讓所有與會人員一起相互溝通意見。此方法的優點是較易

21、獲得正確的資料，即使有不同的意見與觀念，經由眾人研究亦能加以修正。此外，亦可發揮腦力激盪的效果。缺點是要安排共同的時間來進行，在溝通與協調上較困難。 聯合開發聯合開發(Joint Application Development,JAD)主要之精神是透過一個二至五天的集會，讓開發者與顧客能夠快速有效，而且深入地檢討需求並取得共識。 聯合開發的具體結果是產生完整的需求文件。 聯合開發（續）JAD依下列五個步驟來進行： 範圍界定：首先，由專案出資單位的高階主管定義專案的範圍，並以文字記載，且由高階主管和JAD的召集人一起簽訂契約。這個步驟使JAD的召集人得到授權來進行需求分析，對於目標與範圍也有了約

22、定。 關鍵人員的熟悉：JAD的召集人要花一些時間訪談關鍵性的使用者及管理人員，以瞭解專案的背景資料及重要的需求。聯合開發（續1）會議準備JAD會議事前的準備工作應包括下列項目： 整理需求文件草稿分送需求文件草稿 安排助理人員 準備會議室 會議進行會議進行時，召集人引導大家充分利用各種視覺上的輔助工具，如貼紙、白板、投影片、圖表或簡報檔等，將需求表達出來並做有效地溝通及共識的達成。聯合開發（續2） 文件產生最後階段將JAD會議所蒐集的需求整理成需求文件，為達到會議的效果，需求文件的準備要非常快速，例如二、三天。最後再召開一次審查會議，以確認需求文件的內容。 需求表達工具企業員工每天需依企業程序(

23、Business Procedure)執行處理活動，以完成企業功能(Business Function)。企業處理是指企業中最基本的活動單元，也就是說該活動已夠單純，不必再分割。需求分析階段重點工作是先擷取使用者需求，並以使用者觀點應用工具、圖形、或語言表達出來，再進一步對需求進行合理化，最後經由使用者確認，以作為系統分析與設計的基礎。 上述從使用者需求之擷取與修飾，並將最終需求以工具、圖形或語言表達之整體活動稱為需求塑模(Requirement Modeling)。如下圖3-2。圖3-2 需求塑模需求擷取需求轉換使用者與企業需求使用個案圖活動圖(或流程圖)藍 圖資料詞彙需求表達工具（續）結構

24、化之系統分析與設計主要是考量流程塑模與資料塑模。流程塑模與資料塑模的工具包括：流程圖(Flow Chart)：主要表達實體與作業程序及所需資訊間之關係。處理描述：表示流程圖中之作業處理、程序與規則及其相關之資訊輸入與輸出等。藍圖(Drawing)：主要表示資訊之展示格式與內容等，例如表單之格線與縱橫項目。資料詞彙(Data Glossary)：主要描述藍圖內資訊之詳細內容與規則等。圖3-3 流程圖之主要符號符號意義作業處理流程控制資訊之展示與儲存作業處理或資訊進行方向流程圖 流程圖可經下列步驟來建立：先整理出系統範圍內所涉及之實體、資訊與企業功能或企業程序。 逐一檢討每一實體，以找出會主動引發

25、刺激之主要實體（一個主要實體至少會有一個主動刺激，亦可能會有多個），並由每一刺激開始找出其所引發之一系列高度相關之處理步驟（這些處理之集合可完成某一功能），以形成一個流程圖。 例如訂單處理後會緊接著送貨處理，因此兩者應在同一流程圖中。流程圖 （續）劃流程圖時，原則上實體應在上方，而其相關之作業處理及資訊分別表示在其下方，並以文字描述其未盡之情節。 檢查所有流程圖之完整性，也就是所有流程圖是否涵蓋整個系統範圍。 處理描述流程圖雖可表達實體與作業處理之程序及所需資訊間之關係，但無法表達每處理之內部行為。處理描述進一步的表達每個處理之執行步驟、法則、控制等，並說明其資料之輸入和輸出內容與所涉及之實體

26、等。每個處理描述之名稱應與流程圖中之處理同名，處理描述之表達形式可如表 3-1。表3-1 處理描述樣板處理名稱執行程序與規則1.2.資料輸入來源資料輸出目的地限制與備註藍圖(Drawing)藍圖主要用於表達流程圖中，有關之表單、介面等各項資訊需求之名稱、展示位置、格線、圖表與說明等，這些資訊常無法在流程圖上具體地表達，因此須另以藍圖進一步的表示。 藍圖可用原使表單表達或以徒手或工具畫出具體的外觀與內涵。每藍圖應有名稱，名稱命名應唯一且有意義；藍圖中每欄位應給予編號(由左而右、由上而下)，以便作為資料詞彙對欄位內容進步描述時之參考。資料詞彙(Data Glossary)資料詞彙進一步說明藍圖所無

27、法表達之內容，如資訊之長度、型態、格式、公式、規則、範圍與限制等 ，並分別舉例說明之。 資料詞彙之內容項目除了藍圖中之欄位編號與名稱外，欄位資料之長度與型態，資料是否唯一，資料產生之規則、格式、範圍、公式等資訊，均有助於系統分析與設計，因此均可列入資料詞彙中，其形式可表達如表 3-2。表3-2 資料詞彙樣板編號欄位名稱長度型態鍵規則格式範圍公式範例需求分析個案夢幻公司銷售作業業務部門負責接訂貨單，並進行訂貨資料登錄，減合成品庫存；若庫存充足，則直接進行送貨處理，反之，則送生產需求通知給生產部，以便進行產品生產計劃。業務部亦負責送貨與進行送貨資料處理，如計算總價，並產出送或單給客戶確認。需求分析

28、個案流程圖（圖3-4 銷售作業流程圖範例）業 務 部訂單處理成品庫存是否足夠？Y送貨處理訂 單送貨單生產需求客 戶生 產 部N需求分析個案（續）處理描述（表3-3 訂單處理與庫存判斷描述範例）處理名稱訂單處理與庫存判斷執行程序與規則1.業務部收到客戶訂單後，須做客戶資料登錄與檢核。2.業務部檢查訂貨之成品庫存，若成品庫存充足，則進行送貨處理；若成品庫存不足，則通知生產部進行生產計畫之規劃。 資料輸入來源訂單客戶資料輸出目的地送貨訊息業務部或生產需求生產部限制與備註需求分析個案（續1）藍圖（表3-4 訂單藍圖範例）夢幻企業股份有限公司訂單客戶：地址：電話：編號：日期：貨品編號品名顏色規格單價金額

29、FGHIJKLMN10000006 太空梭模型綠25kgS3個417.601,252.8010000005 鐵釘紅25kgL1支200.00200.0010000006 太空梭模型綠25kgS1個200.00200.0010000002 坐墊綠50kgS1粒6,000.006,000.0010000003 方向盤黑50kgM2個600.001,200.0010000004鐵蛋紅100kgM1粒200.00200.00客戶簽章：總金額：9,052 O註：套色區域表示須套印表單之部分。尺寸數量單位DEABC需求分析個案（續2）資料詞彙（表3-5 訂單資料詞彙範例）編號 欄位名稱 長度型態 鍵 規則格式範圍公式 範例 A 客戶名稱 20C 王大明 B 地址 40C 高雄市鼓山區蓮海路70號 C 電話 10C 07-5252000 D 編號 8N 年+月+日+流水號 YYMMDD99 98090101 E 送貨日期 6D 日期 87年9月1日F 貨品編號 8C 99999999 10000003 G 品名