第三章 需求擷取與分析

內容大綱 第一節 導論 第二節 需求擷取方式 第三節 需求表達工具 第四節 需求分析個案 第五節 需求分析之重要工作與文件樣板 第六節 結論

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

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

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

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

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

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

需求擷取方式 在擷取使用者需求之前，必須瞭解系統之潛在使用者及可能之人機互動。 常用的需求擷取方式有查閱文件、觀察、問卷、訪談、開會討論與聯合開發等六種，這些方式可單獨應用亦可混合使用。

查閱文件 研究企業的內部文件，例如工作說明書、企業表單與手冊等，是瞭解企業運作邏輯之初步工作。 一般來說，組織中很少有完整的文件詳細地描述出系統之全貌，加上系統可能已經過多次的修改，文件往往未能配合更新，因此以該方式蒐集之資訊常有過時之慮。

觀察 一般來說，實地觀察所獲得的資料正確性會比查閱文件為高，亦能驗證所蒐集資料之正確性及補充不完整的部分，透過觀察可以獲得第一手的資料。 僅用觀察仍無法完整地反映出組織的真實情況與需求，例如被觀察者的行為可能改變。 選擇正常與例外情況之時機或對象來作觀察，可獲得各種可能的資料。

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

訪談(2/6) 訪談可分成兩種方式： 開放式訪談 結構化訪談 系統分析師事先不預定表格、問卷或固定的標準程序，訪談過程全由使用者自由談論其工作。 適用於系統分析師對問題領域不熟悉或無法預期之情況。

訪談(3/6) 結構化訪談 結構化訪談又稱為標準化訪談或導向式訪談，其訪談過程近似於詢問而非交談，所要求資訊的深度、專門程度亦較深。 這種方式的特點是把問題標準化，然後由受訪者回答或選擇。 所有的受訪者都回答同一形式的問題，其作法如下： 每討論一個主題時，先由系統分析師依其現有瞭解的知識，提出簡短敘述。 使用者針對主題作深度分析，但系統分析師應在深入到適當程度時加以中止。 對某個主題有初步瞭解，就可以進行另一主題的訪談。

訪談(4/6) 訪談之問題依其性質可分成開放性與封閉性問題兩種： 開放性問題 用來探索系統分析師無法預期的回答或明確詢問之問題。 優點：能讓先前不知道的資訊浮現出來，系統分析師可以用一些非預期中的問題，不斷地來探究新的資訊。 缺點：回答問題所花的時間較長，也較難作結論。

訪談(5/6) 封閉性問題 封閉性問題可以有下列幾種設計形式： 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，問題可較廣泛。 缺點：所列之選項未必包含受訪者所要回答的答案。 封閉性問題可以有下列幾種設計形式： 對與錯的選擇方式。 多重選擇的方式。 Likert尺度的衡量方式。用一些級距來衡量受訪者意見的強弱程度，例如用很好、好、普通、差與很差五個等級。

訪談(6/6) 訪談前需有周詳的規劃。 一些有助於訪談進行之準則包括： 要仔細地聆聽受訪者的回答，同時將重點記錄下來，在得到允諾的情況下，還可以將訪問的內容用錄音機或錄影機錄下來，以有效地掌握訪談內容。 訪談結束後，須在48小時之內將訪談內容整理出來，因為經過48小時之後，訪談的內容會慢慢的從記憶中消失。 不管是面對開放性或是封閉性的問題，系統分析師不要強調問題答案的對或錯。 在訪談時，不要對新的系統做任何預期的想法。需讓受訪者知道他們的意見會被仔細地考慮，並讓受訪者知道專案的完成需要很多的步驟，同時還有很多人的觀點都需要一起考慮。 從系統潛在的使用者、管理者與對現行系統有經驗的專業人員等尋找各式各樣的觀點，以對新系統做全盤性的瞭解，如此才能設計出大多數使用者都可接受的系統。

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

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

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

問卷(4/4) 非機率抽樣方法 便利抽樣 以方便性為抽樣之主要考量，這些抽樣之對象可能是最容易找到的系統使用者、願意接受調查的人或是動機高的使用者。 判斷抽樣 又稱立意抽樣，係根據抽樣設計者的判斷來選擇受測之使用者。設計者必須對使用者之特徵有相當地瞭解，然後針對符合某些特徵的名單抽樣，例如針對使用系統已經兩年以上的使用者或者是經常使用的人。 上述抽樣策略可單獨使用，亦可混合使用。當問卷回收後，應該逐一檢查回收問卷之回答是否完整，並去除異常之問卷，以便進行資料分析

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

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

聯合開發(2/4) 範圍界定 首先，由專案出資單位的高階主管定義專案的範圍，並以文字記載，且由高階主管和JAD的召集人一起簽訂契約。這個步驟使JAD的召集人得到授權來進行需求分析，對於目標與範圍也有了約定。 關鍵人員的熟悉 JAD的召集人要花一些時間訪談關鍵性的使用者及管理人員，以瞭解專案的背景資料及重要的需求。

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

聯合開發(4/4) 文件產生 最後階段將JAD會議所蒐集的需求整理成需求文件，為達到會議的效果，需求文件的準備要非常快速，例如二、三天。最後再召開一次審查會議，以確認需求文件的內容。

需求表達工具(1/2) 企業程序是企業處理有組織的結合，其結果需能完成某企業功能，例如行銷或生產管理等。 結構化系統分析與設計主要是考量流程塑模與資料塑模。

圖3-2 需求塑模

需求表達工具(2/2) 流程塑模與資料塑模的工具包括： 流程圖：主要表達實體與作業程序及所需資訊間之關係。 處理描述：表示流程圖中之作業處理、程序與規則及其相關之資訊輸入與輸出等。 藍圖：主要表示資訊之展示格式與內容等，例如表單之格線與縱橫項目。 資料詞彙：主要描述藍圖內資訊之詳細內容與規則等。

圖3-3 流程圖之主要符號

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

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

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

表3-1 處理描述樣板

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

資料詞彙 資料詞彙進一步說明藍圖所無法表達之內容，如資訊之長度、型態、格式、公式、規則、範圍與限制等 ，並分別舉例說明之。 資料詞彙之內容項目除了藍圖中之欄位編號與名稱外，欄位資料之長度與型態，資料是否唯一，資料產生之規則、格式、範圍、公式等資訊，均有助於系統分析與設計，因此均可列入資料詞彙中，其形式可表達如表 3-2。

表3-2 資料詞彙樣板

需求分析個案(1/4) 流程圖（圖3-4 銷售作業流程圖範例）

需求分析個案(2/4) 處理描述（表3-3 「訂單處理」與庫存判斷描述範例）

需求分析個案(3/4) 藍圖 表3-4 訂單藍圖範例

需求分析個案(4/4) 資料詞彙 表3-5 訂單資料詞彙範例

圖3-5 需求分析 文件樣板

結論 需求分析主要是擷取與表達使用者之巨觀需求，這包括欲電腦化之環境、作業處理、輸出與輸入所需之資訊或表單與系統之主要功能等。 需求分析階段對問題領域之瞭解範圍應盡可能的廣，而到分析與設計階段再縮小到專案範圍，如此有助於對新系統之瞭解與規劃。 以目前之開發工具來說，需求分析工作約占整個專案時間的10%左右，且需求分析往往無法在一個階段完全做完，常在分析與設計階段仍有需求分析工作之進行。當然，系統分析師之專業知識與經驗，對需求分析之成效有密切之影響。