C、需求分析 需求擷取方式 需求表達工具 (需求塑模) 需求分析文件樣板 查閱文件、觀察、訪談、問卷、開會討論、聯合開發、企業外部資料

Presentation on theme: "C、需求分析 需求擷取方式 需求表達工具 (需求塑模) 需求分析文件樣板 查閱文件、觀察、訪談、問卷、開會討論、聯合開發、企業外部資料"— Presentation transcript:

1 C、需求分析 需求擷取方式 需求表達工具 (需求塑模) 需求分析文件樣板 查閱文件、觀察、訪談、問卷、開會討論、聯合開發、企業外部資料
事件表、流程圖、處理描述、藍圖、資料詞彙 需求分析文件樣板

2 使用者需求 使用者期待系統解決的問題，或是希望從系統獲得之資訊。 Grosz(1992)認為可分為兩大步驟：
需求擷取：對系統範圍內之各種事物及相關現象加以瞭解、判斷和選擇，並設計成描述性綱目。 需求轉換：將描述性綱目以系統模式語法，轉換成概念性綱目。 擷取 轉換 各種事物現象 描述性綱目 概念性綱目

3 1. 需求擷取方式 以下方式可單獨應用亦可混合使用 查閱文件、觀察 訪談、問卷 開會討論、聯合開發、企業外部資料 擷取 轉換 各種事物現象
描述性綱目 概念性綱目

4 1.1 查閱文件 研究企業的內部文件，是瞭解企業運作邏輯之初步工作，例如： 工作說明書(Job Description)
企業表單(Business Forms) 手冊(Manuals)

5 企業表單實例

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

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

8 查閱文件之缺點 組織中很少有完整的文件詳細地描述出完整系統之全貌 文件往往未能配合更新，因此以該方式收集之資訊常有過時之慮

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

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

11 訪談 訪談之前必須要有詳細規劃 訪談之後必須將結果詳實地紀錄下來 決定訪談對象 設定訪談的議題 (列舉所要討論的問題)
可以從「你希望系統提供什麼樣的功能？」開始 或是「目前你們對這項工作的作業流程是如何進行的？ 」 從這些問題中，可以引領出許多與技術面、執行面、操作面等相關的討論議題。 訪談之後必須將結果詳實地紀錄下來 在得到允諾的情況下，可將訪問內容錄音或錄影。 訪談結束後48小時內整理訪談內容。

12 1.4 問卷 當潛在使用者太多或分布太廣時，可藉問卷之方式擷取需求。 缺點
問卷調查適合於大型企業或公眾資訊系統的設計，因其所涉及的作業範圍或對象太廣，系統分析師無法逐一親自調查 缺點 回收率不高 設計不易 答題者未依據事實來填寫 所獲得的資訊不夠深入

13 實例：問卷調查表

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

15 1.6 聯合開發 Joint Application Development (JAD)
透過一個二至五天的集會，讓開發者與顧客能快速有效，且深入的檢討需求並取得共識

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

17 2. 需求表達工具 (需求塑模) 使用者與 企業需求 事件表 流程圖 處理描述 藍圖 資料詞彙 需求擷取 需求轉換

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

19 2.1 事件表 需求描述轉換為事件表

20 需求分析描述 從需求擷取所獲得的資料，定義出所要解決的問題 儘量使用淺顯易懂的句子 問題的敘述最好是從使用者的觀點出發
對於一個電影院(火車、客運等等)訂票系統來說，可以將使用者的需求定義如下： 使用者必須登入以使用此系統 使用者可利用瀏覽器找尋相關電影並預訂電影票 如果 用「實現訂票流程自動化」來描述，那就把問題的範圍定義得太廣、太抽象

21 事件 功能性需求的描述，可將它們歸納成事件 對於「使用者搜尋音樂CD」這個功能，系統允許我們輸入關鍵字以作為搜尋的依據。
事件可當作是需求描述的精簡版或摘要(summary)。 對於「使用者搜尋音樂CD」這個功能，系統允許我們輸入關鍵字以作為搜尋的依據。 只輸入關鍵字，不會發生什麼事。只有按下了，比如說一個按鈕，系統才會開始做事。 「 搜尋音樂CD 」就是一個事件，這個事件 (藉由按了按鈕)觸發系統去處理或是執行某些特定的工作，並且對於這個事件，系統會將處理結果回應給使用者。

22 自動提款機(ATM)實例 如果你仔細地觀察一下ATM的畫面，會發現到一部ATM的主畫面以及其他可用的選項，都會對應到一個事件上。
比如說：提款，存款，餘額查詢，轉帳等等 這些都是一部提款機所提供給使用者的功能 使用者，必須製造某些事件來觸發或是告知系統你到底想要它做什麼。

23 事件表 整理歸納出一大堆事件之後，可以將之紀錄於表格中，成為事件表。 不要擔心功能到底需要怎麼被實現出來，先把系統當成一個黑盒子。
整理歸納出一大堆事件之後，可以將之紀錄於表格中，成為事件表。  不要擔心功能到底需要怎麼被實現出來，先把系統當成一個黑盒子。 好處：讓參與計畫的人員能將焦點放在系統高層次的觀點，從外部來看系統，而不是系統內部的運作情況 (把焦點放在系統的What)

24 事件表格式 事件名稱：寫出造成系統去完成某事的事件。利用主詞+動詞+(受詞)的型式。 觸發器(trigger)：引發事件的資料。
來源：資料來源 活動：事件發生時， 系統要執行的任務。活動要以動詞為開端。 例如：查詢 (Retrieve)…、更新(Update)…、產生(Create)…、取消(Delete)…。 回應：什麼樣的輸出如果有的話？由哪裡產生？ 目的地：輸出到哪裡去。 事件名稱 觸發器 來源 活動 回應 目的地 顧客下訂單 訂單 顧客 產生一筆新訂單 (訂單明細) 使用者、 出貨部門

25 需求描述轉換為事件表 思考方向 有哪些事情是必須由系統來自動化執行。 所有想要從系統取得某些東西的外部實體。
例如系統必須提供月報表： 所有想要從系統取得某些東西的外部實體。 所有想要從系統取得某些東西的內部實體。 想一想有沒有以資料為導向的事件。 想一想有沒有以時間為導向的事件。 事件名稱 觸發器 來源 活動 回應 目的地 產生月報表 時間 系統 月報表 經理

26 2.2 流程圖 實例：銷售流程圖 訂單處理 訂 單 成品庫存 足夠？ 生產需求 送貨處理 送貨單 是 客 戶 業 務 部 生 產 部 否

27 流程圖之主要符號

28 流程圖繪製步驟 先整理出系統範圍內所涉及之實體、資訊與企業程序。
逐一檢討每一實體，以找出主動引發刺激之主要實體，並由每一刺激找出其引發之處理。 畫流程圖時，實體應在上方，而其相關之作業處理及資訊分別表示在其下方，並以文字描述其未盡之情節。 檢查所有流程圖之完整性(所有流程圖是否涵蓋整個系統範圍)。

29 2.3 處理描述 進一步表達每個處理之執行步驟、法則、控制等，並說明資料之輸入與輸出內容與所涉及之實體。

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

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

32 藍圖實例：訂單

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

34 資料詞彙實例：訂單

35 3. 需求分析文件樣板 問題描述與可行性分析 新系統目標 新系統限制(或系統範圍) 使用者需求 事件表
流程圖1 處理規格描述1-1… 處理規格描述1-n 藍圖1-1 資料詞彙1-1… 流程圖2 …

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

37 資訊需求表實例 資訊需求表 系統名稱 應付帳款系統 使用單位 貨品部與管理部 填表日期 91.3.19. 問題癥結與原因 (1)
應付帳款均在交貨 30 天後才付款 ，無法獲得優惠折扣 。 (2) 貨品部與管理部人手不足 ，難於交貨 10 天後完成手續 需求說明 利用電腦處理應付帳款工作 ，以期獲得供應商最優惠折扣 加速付款作業 ，提升對供應商之服務品質 預期效益 每月可獲得 50 萬元的折扣 提升本公司財務信譽 (3) 減輕各單位工作負荷 ，避免增加人力之需求 預期完成日期 91 年 6 月底 審查意見 確可獲得折扣 、簡化作業 、降低成本 ，利用現有設備即可 主管批示 儘速進行系統分析 填表人 某某某

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

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

40 3.3 新系統限制(或系統範圍) 限制可能來自： 時間 投入人力 高階管理者之支持 使用者之配合與抗拒 軟硬體架構與資源 安全規定...