需求擷取.

Presentation on theme: "需求擷取."— Presentation transcript:

1 需求擷取

2 內容大網 導論 需求擷取方法 需求表達工具 結論

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

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

5 導論 (c.3) 理論上，該階段之主要工作是應用已通過驗證之原理(Principles)、技術(Techniques)、語言(Languages)與工具(Tools)，以幫助分析師瞭解問題或描述新系統之外部行為。

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

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

8 需求分析之重要步驟

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

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

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

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

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

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

15 訪談 (c.3) 結構化訪談 結構化訪談又稱為標準化訪談或導向式訪談，其訪談過程近似於詢問(Interrogation)而非交談 (Conversation)，所要求資訊的深度、專門程度亦較深。

16 訪談 (c.4) 這種方式的特點是把問題標準化，然後由受訪者回答或選擇。 所有的受訪者都回答同一形式的問題，其作法如下：
(1) 每討論一個主題時，先由分析師依其現有瞭解的知識，提出簡短敘述。 (2) 使用者針對主題作深度分析，但分析師應在適當知識深度時加以中止。 (3) 對某個主題有初步瞭解，就可以進行另一主題的訪談。

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

18 訪談 (c.6) 封閉性問題 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，問題可較廣泛。
缺點：所列回答之選項未必包含受訪者所要回答之答案。

19 訪談 (c.7) 封閉性問題可以有下列幾種設計形式： (1)對與錯的選擇方式。 (2)多重選擇的方式。
(3)Likert尺度的衡量方式。用一些級距來衡量受訪者意見的強弱程度，例如用很好、好、普通、差與很差五個等級。

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

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

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

23 問卷 (c.2) 設計一份好的問卷需有相當的練習與經驗，因為問卷上的問題是以文字靜態的表達，故問題之語意與邏輯必須很清楚且有條理。
問卷設計時也可以用各種不同的方法來問同一個問題，以觀察各種可能的答案。

24 問卷 (c.3) 正式問卷調查前需有先導測試。 經由先導測試之檢討與回饋可進一步修飾問卷，及早發現問卷可能之問題，對提升問卷之效能有很大之幫助。

25 問卷 (c.4) 正式問卷調查時必須決定那些族群是調查的對象。對象選取之抽樣方法主要分成：
機率抽樣(Probability Sampling) 非機率抽樣(Nonprobability Sampling)

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

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

28 問卷 (c.7) 上述抽樣策略可單獨使用，亦可混合使用。當問卷回收後，應該逐一檢查回收問卷之回答是否完整，並去除異常之問卷，以便進行資料分析。

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

30 聯合開發 聯合開發（Joint Application Development, JAD）主要之精神是透過一個二至五天的集會，讓開發者與顧客能夠快速有效，而且深入的檢討需求並取得共識。 聯合開發的具體結果是產生完整的需求文件。

31 聯合開發(c.2) JAD依下列五個步驟來進行： (1) 範圍界定。 (2) 關鍵人員的熟悉。 (3) 會議(事前)準備。
(4) 會議進行。 (5) 文件產生。

32 聯合開發(c.3) 範圍界定 首先，由專案出資單位的高階主管定義專案的範圍，並以文字記載，且由高階主管和JAD的召集人一起簽訂契約。這個步驟使JAD的召集人得到授權來進行需求分析，對於目標與範圍也有了約定。

33 聯合開發(c.4) 關鍵人員的熟悉 JAD的召集人要花一些時間訪談關鍵性的使用者及管理人員，以了解專案的背景資料及重要的需求。

34 聯合開發(c.5) 會議準備 JAD會議事前的準備工作應包括下列項目： 準備需求文件草稿。 分送需求文件草稿。 安排助理人員。 準備會議室。

35 聯合開發(c.6) 會議進行 會議進行時，召集人引導大家充分利用各種視覺上的輔助工具如貼紙、白板、投影片、圖表等，將需求表達出來並做有效的溝通及共識的達成。

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

37 需求表達工具 物件導向技術在需求分析時常以使用個案模式 (Use Case Model) 來進行需求塑模。
使用個案模式是一種使用者需求表達之塑模工具，該工具從使用者之觀點描述系統提供之功能與定義系統內部之作業，主要以使用個案圖（Use Case Diagram）及一些典型的情節(Scenario)來幫助表達與了解使用者需求。

38 需求表達工具 (c.2) 結構化技術於需求分析時常用工具包括： 流程圖(Flow Chart) 處理描述 藍圖(Drawing)
流程圖主要表達實體(Entity)與作業程序及所需資訊間之關係。 處理描述 處理描述則表示流程圖中之作業處理、程序與規則及其相關之資訊輸入與輸出等。 藍圖(Drawing) 藍圖主要表示資訊之展示格式與內容等，例如表單之格線與縱橫項目。 資料詞彙(Data Glossary) 資料詞彙主要描述藍圖內資訊之詳細內容與規則等。

39 需求表達工具 (c.3) 以上這些物件導向技術及結構化技術所採用的工具亦可混合使用。

40 結論 需求分析階段對問題領域之瞭解範圍應盡可能的廣，而到分析與設計階段再縮小到專案範圍，如此有助於對新系統之瞭解與規劃。

41 結論 (c.2) 以目前之開發工具來說，需求分析工作約佔整個專案時間的10％左右，且需求分析往往無法在一個階段完全做完，常在分析與設計階段仍有需求分析工作之進行。當然，分析師之專業知識與經驗，對需求分析之成效有關鍵性之影響。