系统分析与设计理与实务应用.pptVIP

需求分析 本章大綱 學習目標 3.1?導論 3.2?需求擷取方式 3.3?需求表達工具與方法 3.4 需求分析結果與文件樣版 3.5?需求分析個案 3.6 結論 學習目標 詳讀本章，你至少能瞭解： 需求分析步驟與應注意事項。 常見的六種需求擷取方式及執行要點。 何謂環境圖、流程圖、處理描述、藍圖與資料詞彙。 如何以環境圖、流程圖、處理描述、藍圖與資料詞彙進行需求塑模。 需求分析之重要工作與文件樣板為何。 3.1 導論(1/5) 使用者需求，係指使用者期待系統解決的問題與希望從系統獲得之資訊。 使用者需求是資訊系統開發過程中最關鍵、最重要且最容易發生錯誤的部分，亦是資訊系統失敗的主因之一。 需求分析是使用者與分析師均必須重視之議題。 該階段之主要工作是應用已通過驗證之原理(Principles)、技術(Techniques)、語言(Languages)與工具(Tools)，幫助分析師瞭解問題或描述與新系統互動之外部行為。 3.1 導論(2/5) 系統開發過程中的需求分析階段主要包括三個活動： 需求判斷 強調如何判斷真正的需求及需求的正確性。 需求分析 重視在分析已有的需求下，所產生的不一致、不完整或矛盾等問題。 需求溝通 重視以最佳的方式組織及描述需求，使需求令人容易瞭解，並經由相互溝通達到需求確認的目的。 3.1 導論(3/5) 需求分析階段可分為兩大步驟： 需求擷取 主要是對系統範圍內之各種事物與相關現象，加以瞭解、判斷及選擇，並設計成描述性綱目。 需求轉換 主要將描述性綱目以系統模式語法轉換成概念性綱目。 圖3-1 需求分析之重要步驟 3.1 導論(4/5) 需求分析階段之重要工作包括： 建立組織資訊處理需求 發展資訊系統目標 設計及評估資訊系統發展方案 整理系統分析師、其他分析師、使用者和其管理者溝通分析的結果 從事系統審核 3.1 導論(5/5) 使用者需求可分為： 巨觀需求 包括欲電腦化之環境、作業程序與範圍、輸出與輸入所需之資訊或表單及系統目標、限制和主要功能等，這些需求應盡可能地在需求分析階段釐清與確定。 微觀需求 指的是電腦化之微觀範圍，包括使用者介面要求、例外狀況處理與錯誤及輔助訊息顯示等需求，這些需求通常需到設計階段才較容易處理，在此之前這些細部需求不易被掌握。 3.2 需求擷取方式 在擷取使用者需求之前，必須先瞭解系統之潛在使用者及可能之人機互動。 接著蒐集欲電腦化之作業處理程序及其輸出入資料內容、數量、格式、目標、規則與限制等。 常用的需求擷取方式有查閱文件、觀察、問卷、訪談、開會討論與聯合開發六種，這些方式可單獨應用亦可互相搭配使用。 3.2.1 查閱文件 係指研究企業的內部文件，例如工作說明書、企業表單與手冊等，是瞭解企業運作邏輯之初步工作。 然而，組織中很少有完整的文件能詳細描述系統全貌，再加上系統可能已經過多次修改，文件未能同步更新，所以文件與實際情況常有出入。 以此方式蒐集之資訊常有過時之慮。 3.2.2 觀察 一般來說，實地觀察所獲得資料之正確性會比查閱文件為高，亦能驗證所蒐集資料之正確性及補充不完整的部分，透過實地觀察也可獲得第一手資料。 觀察時，可選擇正常與例外情況之時機或對象來做觀察，以便獲得各種可能的資料。 但觀察仍無法完整地反映出組織的真實情況與需求，例如被觀察者的行為可能改變。 3.2.3 訪談(1/4) 訪談是需求擷取方式中最有效且最普遍的資料蒐集方法。訪談時，系統分析師將親自與使用部門的主管或相關作業人員面對面討論實際作業的情況、所需報表和資訊需求等。 訪談期間，系統分析師蒐集到的可能是事實、選擇或推測，並可觀察到人們的肢體語言、情緒和他們對於現行系統之觀感。 3.2.3 訪談(2/4) 訪談可分成兩種方式： 開放式訪談(Open Interview) 系統分析師不事先預定表格、問卷或固定的標準程序，訪談過程全由使用者自由談論其工作。 主要應用在系統分析師對問題領域不熟悉的情況。 結構化訪談(Structured Interview) 又稱為標準化訪談或導向式訪談，其訪談過程近似詢問而非交談，所要求資訊的深度與專業程度亦較深。 特點是把問題標準化，然後由受訪者回答或選擇。 3.2.3 訪談(3/4) 訪談之問題依其性質可分成兩種： 開放性問題 用來探索系統分析師無法明確詢問受訪者或對受訪者之回答無法預期之問題。 優點： 能讓先前不知道的資訊浮現出來。 受訪者感覺較輕鬆。 受訪者有機會參與和控制整個訪談的過程。 缺點：回答問題所花的時間較長，也較難做結論。 3.2.3 訪談(4/4) 2. 封閉性問題 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，討論的問題較廣泛。 缺點：所列之回答選項未必包含受訪者所要回答的答案。 封閉性問題有下列幾種