01_系统分析简介与需求调查.pptVIP

系統分析簡介與需求調查 Introduction to System Analysis and Requirement Determination 內容大綱 系統分析簡介 使用者需求的重要 分析流程 分析重點 需求訂定 調查方法 表達工具 使用者需求的重要 使用者需求：使用者期待系統解決的問題與希望從系統獲得之資訊。 為系統開發最關鍵、最重要且最容易發生錯誤的部分，是資訊系統失敗的主因之一。 各階段修正錯誤的相對成本如下表: 系統分析流程Systems analysis process 非常重要的階段與活動。主要是應用已通過驗證之原理、技術、語言與工具，瞭解問題或描述新系統之外部行為。 範疇定義Scope definition (可使用Context Diagram，如前章所述) 問題分析Problem analysis 需求擷取調查Requirements Discovery 需求分析與塑模Requirement Analysis and Modeling 發掘及分析問題 (以石川圖Ishikawa Diagram) A graphical tool used to identify, explore, and depict problems and the causes and effects of those problems. Often referred to as a cause-and-effect diagram因果圖 or a fishbone diagram魚骨圖. 需求分析的流程 擷取:對系統範圍內之各種事物與相關現象，加以瞭解、判斷及選擇，並設計成描述性綱目。 轉換成結構性之需求:將描述性綱目以系統模式語法轉換成概念性綱目。 常平行及反覆的(Parallel and iterative)進行 分析的重點 現況(As-is) vs. 未來系統(To-be) 資料 流程 邏輯 系統需求調查訂定的態度 直截了當的詢問 保持中立的思考 鬆綁現有限制 注意細節 重新建構 產出與結果Deliverables and Outcomes 與使用者交談或是觀察使用者所獲取之資料：訪談筆記或會議紀錄。 現存的書面資訊：企業使命與策略聲明、企業內的各式文件格式與電腦報表、作業手冊、工作說明書、訓練手冊、現行使用系統上的文件件與流程或公司顧問的報告。 電腦上的資訊：協合應用系統設計(JAD)階段的結果、現行系統上的CASE的儲存庫(repository)內容、 現有系統報表與系統雛型呈現。 需求擷取方式 系統發展猶如對企業作診斷及治療過程，需求調查也像對人的診斷，需運用「望、聞、問、切」的技巧。 必須瞭解系統之潛在使用者及可能之人機互動。 常用方式（可單獨或混合使用） 查閱文件 觀察 問卷 訪談 開會討論 聯合開發(Joint Application Development, JAD) 查閱文件 研究企業的內部文件是瞭解企業運作邏輯之初步工作，內容包括: 工作說明書(含流程圖)，或標準作業程序（Standard Operation Procedure, SOP) 手冊 表單 報表 一般來說，組織中很少有完整的文件詳細地描述出系統之全貌，加上系統可能已經過多次的修改，文件往往未能配合更新，因此以該方式蒐集之資訊常有過時之慮。 觀察 一般來說，實地觀察所獲得的資料正確性會比查閱文件為高，亦能驗證所蒐集資料之正確性及補充不完整的部分，透過觀察可以獲得第一手的資料。 僅用觀察仍無法完整地反映出組織的真實情況與需求，例如被觀察者的行為可能改變。 選擇正常與例外情況之時機或對象來作觀察，可獲得各種可能的資料。 訪談 最有效且最普遍的資料蒐集方法。 系統分析師親自與使用部門的主管或相關作業人員面對面討論實際作業的情況、報表和資訊需求等。蒐集到的可能是事實、選擇或推測，並可觀察到人們的肢體語言、情緒和他們對現行系統之觀感等。 開放式訪談 不預定表格、問卷或固定的標準程序，過程全由使用者自由談論其工作。 適用於系統分析師對問題領域不熟悉或無法預期之情況。 結構化訪談 又稱標準化訪談或導向式訪談，過程近似於詢問而非交談，所要求資訊的深度、專門程度亦較深。 把問題標準化，然後由受訪者回答或選擇。 訪談 問題依其性質可分 開放性問題 用來探索系統分析師無法預期的回答或明確詢問之問題。 優點：能讓先前不知道的資訊浮現出來，系統分析師可以用一些非預期中的問題，不斷地來探究新的資訊。 缺點：回答問題所花的時間較長，也較難作結論。 封閉性問題 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，問題可較廣泛。 缺點：所列之選項未必包含受訪者所要回答的答案。 幾種設計形式： 對與錯 多重選擇 Likert尺度的衡量方式。例如用很好