第三章 需求擷取與分析 一、導論 二、需求擷取方法 三、需求表達工具 四、需求分析文件樣板 查閱文件、觀察、訪談、問卷 開會討論、聯合開發 流程圖、處理描述、藍圖、資料詞彙 四、需求分析文件樣板

一、導論 使用者需求 係指使用者期待系統解決的問題，與希望從系統獲得之資訊。 是資訊系統開發最關鍵、最重要且最容易發生錯誤的部份，亦是資訊系統失敗的主因之一。

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

需求分析之重要步驟

二、需求擷取方式 常用的需求擷取方式有以下六種，這些方式可單獨應用亦可混合使用。 查閱文件 觀察 問卷 訪談 開會討論 聯合開發

(1) 查閱文件 研究企業的內部文件，是瞭解企業運作邏輯之初步工作 缺點 如工作說明書(Job Description)、企業表單(Business Forms)與手冊(Manuals) 缺點 組織中很少有完整的文件詳細地描述出完整系統之全貌 文件往往未能配合更新，因此以該方式收集之資訊常有過時之慮

重複資料分析 了解每一種報表的資料內容及其相互間的重複情形，如：

表報使用分析 詳列每一種報表的編製單位、週期、使用單位、保存期限、編製份數等，例如：

(2) 觀察 實地觀察(Observation) 缺點 可以獲得第一手的資料，因此所獲得的資料其正確性會比查閱文件為高 選擇正常與例外情況之時機或對象來做觀察，可獲得更多的資料。 缺點 可能使人們改變原來的工作方式 只能觀察到部份的人或特定之區域

實例：銷售辦公室現場工作流程圖

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

訪談的兩種方式 開放式訪談(Open Interview) 結構化訪談(Structured Interview) 分析師事先不預定表格、問卷或固定的標準程序，訪談過程全部由使用者自由談論其工作 結構化訪談(Structured Interview) 訪談過程近似於詢問(Interrogation)而非交談 (Conversation)，所要求資訊的深度、專門程度亦較深 這種方式的特點是把問題標準化，然後由受訪者回答或選擇

開放性與封閉性訪談問題 開放性問題 封閉性問題 用來探索分析師無法預期的回答 對與錯方式；多重選擇方式； Likert尺度的衡量方式 例如現有資訊系統對你提供最大的幫助為何？你最常使用哪三種報表？ 封閉性問題 對與錯方式；多重選擇方式； Likert尺度的衡量方式 用一些級距來衡量受訪者意見的強弱程度 例如用很好、好、普通、差與很差五個等級。

開放式性與封閉性問題之比較 開放性問題的優點 開放性問題的缺點 分析師可用一些非預期中的問題，不斷的來探究新的資訊。 封閉性問題的主要缺點是分析師所列的選項中，未必包含受訪者所要回答的答案。 開放性問題的缺點 所花的時間較長，也較難做出結論

成功訪談之進行原則 仔細的聆聽受訪者的回答，同時將重點記錄下來 訪談結束後，需在48小時之內將訪談內容整理出來 在得到允諾的情況下，可將訪問內容用錄音機或錄影機錄下來，以有效的掌握訪談內容。 訪談結束後，需在48小時之內將訪談內容整理出來 因為經過48小時之後，訪談的內容會慢慢的從記憶中消失。

成功訪談之進行原則 (Cont.) 不管是開放性或是封閉性的問題，分析師不要強調問題答案的對或錯 在訪談時，不要對新的系統做任何預期的想法 需讓受訪者知道其意見會被仔細考慮 對新系統做全盤性的瞭解 從系統潛在的使用者、管理者與對現行系統有經驗的專業人員等尋找不同觀點

(4) 問卷 當潛在使用者太多或分布太廣時，可考慮以問卷之方式擷取需求。 問卷調查適合於大型企業或公眾資訊系統的設計，因為它所涉及的作業範圍或對象太廣，系統分析師無法逐一親自調查

實例：問卷調查表

問卷設計之語意表達 受訪者僅能用寫的方式回答問卷，且分析師不在現場，無法進行雙向溝通，故問卷之語意表達特別重要 Ex：您的電腦檔案多久備份一次？ (A)經常；(B)有時；(C)不常；(D)不曾 問題點：上述選項語意不清，且電腦檔案所指為何？ 修改為：您的個人電腦硬碟中所有的檔案多久備份一次？ (A)至少每週一次； (B)每月1-3次；(C)1-2月1次或更少；(D)不曾

先導測試(前測) 經由先導測試之檢討與回饋可進一步修飾問卷，及早發現問卷可能之問題，對提升問卷之效能有很大之幫助。 找5-10位受訪者填寫問卷初稿 以面談方式要求受訪者從頭至尾閱讀與作答 再予受訪者溝通文句描述是否清楚？選項與內容是否適當？回答是否合理？

問卷之抽樣方法 進行問卷調查時必須決定那些族群是調查的對象。對象選取之抽樣方法主要分成： 機率抽樣(Probability Sampling) 非機率抽樣(Nonprobability Sampling) 上述抽樣策略可單獨使用，亦可混合使用。問卷回收後，應逐一檢查回答是否完整，並去除異常之問卷，以便進行資料分析。

機率抽樣方法 簡單隨機抽樣：將使用者的名單並逐一給予編號，再以摸彩法或亂數表來抽樣，以決定那些人將成為受測的對象。 分層抽樣：先將所有可能之使用者分成若干互斥的層，然後再從各層中隨機抽選預定數目之使用者為受測對象。 叢式抽樣 系統抽樣

非機率抽樣方法 便利抽樣： 判斷抽樣： 以方便性為抽樣之主要考量，這些對象可能是最容易找到的使用者、願意接受調查的人或是動機高的使用者。 又稱立意抽樣(Purposive Sampling)，係根據抽樣設計者的判斷來選擇受測之使用者，例如針對使用系統已經兩年以上的使用者或者是經常使用的人。

問卷調查與訪談法之比較 問卷調查的優點 問卷調查的缺點 成本較低 蒐集的資料較為廣泛 問卷回收率不高 問卷設計不易 答題者未依據事實來填寫 問卷所獲得的資訊較少

(5) 開會討論 使用者代表與系統開發人員聚集一堂，將所知道的事實、觀念說出，讓所有與會人員一起相互溝通意見。 是一種很有效率的資料蒐集方式 此方法的優點是較易獲得正確的資料，即使有不同的意見與觀念，經由眾人研究亦能加以修正。

(6) 聯合開發 Joint Application Development (JAD) 主要之精神是透過一個二至五天的集會，讓開發者與顧客能夠快速有效，而且深入的檢討需求並取得共識。 JAD依下列五個步驟來進行(Wood and Silver, 1995) ： 範圍界定、訪談關鍵人員、會議(事前)準備、會議進行、文件產生。 聯合開發的具體結果是產生完整的需求文件。

(7)企業外部資料 專業雜誌 教科書 廠商之產品說明書 同業觀摩 相關網站觀察...

三、需求表達工具 流程圖(Flow Chart) 處理描述 藍圖(Drawing) 資料詞彙(Data Glossary) 表達實體(Entity)與作業程序及所需資訊間之關係。 處理描述 表示流程圖中之作業處理、程序與規則及其相關之資訊輸入與輸出等。 藍圖(Drawing) 表示資訊之展示格式與內容等，例如表單之格線與縱橫項目。 資料詞彙(Data Glossary) 要描述藍圖內資訊之詳細內容與規則等。

需求塑模 使用者與 企業需求 需求擷取 需求轉換 使用個案圖 活動圖或流程圖 藍圖 資料詞彙

(1) 流程圖 流程圖可經下列步驟來建立： (a) 先整理出系統範圍內所涉及之實體、資訊與企業功能或企業程序等 (b) 逐一檢討每一實體，以找出主動引發刺激之主要實體，並由每一刺激開始找出其引發之一系列高度相關之處理 一個主要實體至少會有一個主動刺激，亦可能會有多個 (這些處理之集合可完成某一功能)，以形成一個流程圖。 例如訂單處理後會緊接著送貨處理，因此兩者應在同一流程圖中。

(c) 畫流程圖時，原則上實體應在上方，而其相關之作業處理及資訊分別表示在其下方，並以文字描述其未盡之情節。 (d) 檢查所有流程圖之完整性，也就是 所有流程圖是否涵蓋整個系統範圍。

流程圖之主要符號

實例：銷售流程圖

(2) 處理描述 進一步的表達每個處理之執行步驟、法則、控制等，並說明其資料之輸入與輸出內容與所涉及之實體等。 每個處理描述之名稱應與流程圖中之處理同名。

處理描述樣板

實例：訂單處理之處理描述

(3) 藍圖 Drawing 主要用來表達流程圖中有關之表單、介面等各項資訊需求之名稱、展示位置、格線、圖表與說明等 上述資訊常無法在流程圖上具體的表達，因此須另以藍圖進一步的表示。

實例：訂單藍圖

(4) 資料詞彙 Data Glossary 進一步說明藍圖所無法表達之內容如資訊之長度、型態、格式、公式、規則、範圍與限制等 ，並分別舉例說明之。

實例：訂單資料詞彙

四、需求分析文件樣板 一、問題描述與可行性分析 二、新系統目標 三、新系統限制 四、使用者需求 流程圖1 處理規格描述1-1… 處理規格描述1-n 藍圖1-1 資料詞彙1-1… 流程圖2 …

(1) 問題描述 描述目前系統(包括電腦化及人工作業系統)的問題、缺少的功能、生產效率問題等，並排出其重要性或是解決之優先順序 實例：資訊需求表 使用者的需求，通常以備忘錄、通知單等形式通知資訊部門

資訊需求表實例

可行性分析 需求是否重要或迫切需要？ 系統完成後，能否節省成本、提高效益？ 需求是否符合企業經營目標？ 資訊中心人力與設備是否足以負荷？ →若答案均是肯定的，則繼續下一步工作「需求分析」，否則建議停止該系統之開發

(2) 新系統目標 針對問題摘述新系統欲完成之功能、補救之缺陷即將增加或修改之特色 一般性之系統目標如： 節省成本 提高工作效率 提高資訊處理速度和準確性 提高系統的安全性 提供新的處理功能和決策資訊...

(3) 新系統限制 新系統需在所述之限制內完成目標 限制可能來自： 高階管理者或使用者 生產率 軟硬體架構 安全規定 環境條件 實施規則...