第3章 需求分析

本章大綱 學習目標 3.1 導論 3.2 需求擷取方式 3.3 需求表達工具與方法 3.4 需求分析結果與文件樣版 3.5 需求分析個案 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. 封閉性問題 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，討論的問題較廣泛。 2. 封閉性問題 適用於問題可預期且回答可明確描述之情況。 優點：訪談的時間較短，討論的問題較廣泛。 缺點：所列之回答選項未必包含受訪者所要回答的答案。 封閉性問題有下列幾種設計形式： 對與錯的選擇方式。 多重選擇的方式。 李克特量表的衡量方式。

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

3.2.4 問卷(2/3) 因為問卷上的問題是以文字靜態地表達出來，因此問題之語意與邏輯必須很清楚且有條理。設計問卷時也可用各種不同的方法來問同一個問題，以觀察各種可能的答案。 進行正式問卷調查前需有先導測試，經先導測試之檢討與回饋進一步修飾問卷，及早發現問卷可能之問題，對提升問卷品質有很大之幫助。

3.2.4 問卷(3/3) 正式問卷調查時必須決定調查的對象，對象選取之抽樣方法主要分成： 機率抽樣(Probability Sampling) 非機率抽樣(Nonprobability Sampling) 各種抽樣策略可單獨使用，亦可混合使用。 當問卷回收後，應逐一檢查問卷的回答內容是否完整，並去除作答不完整或隨便作答等異常問卷，以便進行資料分析。

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

3.2.6 聯合開發(1/5) 聯合開發(Joint Application Development, JAD)之主要精神，是透過一個2～5天的集會，讓開發者與顧客能夠快速、有效且深入地檢討需求，進而取得共識。 聯合開發的具體結果是產生完整的需求文件。

3.2.6 聯合開發(2/5) JAD 依下列五個步驟來進行(Wood and Silver, 1995)： 範圍界定 關鍵人員的熟悉 會議準備 會議進行 文件產生

3.2.6 聯合開發(3/5) 範圍界定 先由專案出資單位的高階主管定義專案範圍，以文字記載後，由高階主管和JAD 召集人一起簽訂契約。 關鍵人員的熟悉 JAD 召集人要花一些時間訪談關鍵性的使用者及管理人員，以瞭解專案的背景資料及重要的需求。

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

3.2.6 聯合開發(5/5) 文件產生 最後階段須在2、3天內將JAD 會議所蒐集的需求，整理成需求文件。 最後再召開一次審查會議，確認需求文件的內容。

3.3 需求表達工具與方法(1/3) 需求分析階段之重點工作是先擷取使用者（或企業）的巨觀需求，並以使用者觀點應用具有完整定義的(Well-Defined)工具、圖形或語言將需求表達出來，再進一步對需求進行合理化，最後由使用者確認，以作為系統分析與設計的基礎。 以結構化之系統分析與設計而言，主要是考量企業流程塑模與資料塑模。

圖3-2 需求塑模

3.3 需求表達工具與方法(2/3) 流程塑模與資料塑模的工具包括： 環境圖 主要表達系統與所在環境之關係。 流程圖 主要表達實體之作業程序及所需資訊。 事件 表示外部實體所啟動且系統必須回應之刺激 處理描述 表示流程圖中作業處理之執行程序與規則、相關之資料輸出入資訊以及處理之限制與備註。

3.3 需求表達工具與方法(3/3) 藍圖 主要表示流程圖中資訊之展示格式與內容。 資料詞彙 主要描述藍圖內資訊之詳細內容與規則。

3.3.1 事件(1/2) 事件(Event)表示外部實體所啟動且系統必須回應之「刺激(Stimuli)」。 事件可分為資料流導向、時間導向與控制導向事件三種。 資料流導向之事件是系統藉由接收到資料之輸入而知道事件已發生。 例如系統收到客戶輸入代號時，啟動驗證是否為有效客戶之事件 時間導向之事件指預設之時間到時，該事件被啟動。 例如在系統內建一時鐘，當時間到達時，系統便會自動啟動簽發支票事件

3.3.1 事件(2/2) 控制導向之事件是由非預設時間之某些刺激或狀態所引發。 例如系統之開或關等 事件之集合稱為事件列(Event List)，一般來說，系統與外部實體之關係可用事件列來表示。 對資料流導向之事件其命名與編碼原則如下： 對每一外部實體給予一個唯一的名稱與編號。 事件以文句之方式命名，主詞為與系統互動之外部實體（行為者）或系統，是事件之起始者或參與者。 事件之編碼可由啟動事件之外部實體編號加流水碼表示之，以方便辨識。 例如客戶下訂單（業務部）可編碼為A01。

3.3.2 環境圖(1/6) 環境圖(Context Diagram)用來表達系統所在之環境及其與環境間之關係，這包括與系統有關之外部實體及系統與外部實體間之互動，例如資訊之輸出入與處理等。 環境圖常用於表達系統之巨觀範圍，以幫助我們瞭解系統所在之環境及兩者間之互動關係，其重要內容有： 與系統互動之外部實體 系統從環境中接受的資訊或刺激 系統所產生及輸出給環境之資訊 系統與環境之界線等

表3-1 環境圖之元件

3.3.2 環境圖(2/6) 系統 環境圖中係以圓形來表示系統，並於其中註明系統名稱。 例如，若以環境圖表達便利商店之進銷存系統及其所在之環境，則以圓形表示該進銷存系統。 外部實體 外部實體可以是任何組織、物件或相關系統，是環境中與系統有互動或交換訊息之任何人或物。 環境圖中以矩形表示外部實體，且於其中註明外部實體之名稱。 例如使用進銷存系統之管理者、廠商等。

3.3.2 環境圖(3/6) 處理與資訊流 處理與資訊流是以箭頭連結系統與外部實體，表示資訊之輸出入處理或事件之方向。 環境圖製作常以系統為中心，以星狀形式表示系統與外部實體之關係，並將兩者互動之事件列標示在箭頭上。 環境圖之建構步驟為： 整理事件條列式 找出外部實體 找出系統與外部實體之關係 繪製環境圖

3.3.2 環境圖(4/6) 整理事件條列式 將使用者與企業需求描述整理成更簡潔的事件條列式，其中應表達事件之起始者、動作及參與動作之物件等，描述格式可表達如下： 主詞＋動詞＋受詞 主詞是與系統互動之外部實體（行為者）或系統 動詞是外部實體或系統之動作，可描述事件要處理的工作 受詞表示件完成之工作項目、表單或格式等。

3.3.2 環境圖(5/6) 2. 找出外部實體 可從使用者與企業需求描述中之名詞、代名詞與名詞片語等，找出合乎外部實體定義的人、組織、物件或相關系統，也就是環境中與系統有互動或交換訊息之任何人或物。 3. 找出系統與外部實體之關係 由於系統與外部實體之關係可用事件列來表示，因此系統與外部實體之關係可由步驟(1)所整理出之簡潔的事件條列式來找出。

3.3.2 環境圖(6/6) 4. 繪製環境圖 繪製步驟為先繪出系統與所有外部實體，再將系統與外部實體間有互動者以箭頭線段連結。 4. 繪製環境圖 繪製步驟為先繪出系統與所有外部實體，再將系統與外部實體間有互動者以箭頭線段連結。 若一事件由外部實體所啟動，則關係之箭頭由外部實體指向系統；若一事件是由系統回應外部實體，則關係之箭頭由系統指向外部實體。 完成環境圖之繪製後，可用流程圖表達系統之執行順序。

3.3.3 流程圖(1/) 流程圖(Flow Chart)為一圖形化表達工具，用以描述企業作業流程，其可分為系統流程圖及程式流程圖兩類。 系統流程圖(System Flow Chart)用以描述整個工作系統中，各單位之間的作業關係。 程式流程圖(Program Flow Chart)則用以表示程式中的處理過程。 程式流程圖是流程圖中較常用之表示方法，因此本節將介紹程式流程圖為主。

表3-2 流程圖之元件

3.3.3.1 流程圖之元件(1/2) 作業處理(Processing) 為真實世界的一個動作處理、一組動作程序、或是可執行的一段副程式。 一個作業處理是流程的基本單位，不能再被分解且此動作之執行不能被中斷。 作業處理以矩形表示，內部標示流程名稱。 決策(Decision) 是用於表達有多個選擇路徑，但僅能依條件選擇其中一個路徑執行，條件通常包含Yes/No或True/False這類的問題。 決策是以一菱形外加一條流入菱形之箭頭與多條流出菱形之箭頭表示。

3.3.3.1 流程圖之元件(2/2) 報告(Report) 可用於描述某一個流程之輸出入資訊。 流程方向(Flow of Control) 用以表達控制流。 接點(Connector) 當流程圖過於龐大或複雜時，可使用接點(Connector)將流程圖轉到另一頁，此舉可避免流程方向之箭頭交叉，亦可避免流程太過冗長，增加流程圖之易讀性。 註解(Annotation) 用以表達流程圖之補充與說明。

3.3.3.2 流程圖製作程與準則 流程圖之建構步驟包括： 找出外部實體 找出作業處理 檢視外部實體 繪製流程圖 檢視流程圖

3.3.3 流程圖(2/4) 找出外部實體 流程圖之外部實體即環境圖之外部實體，每一流程圖必有起始之外部實體及與之互動的其他外部實體。可由事件條列式整理出該流程所涉及之實體，例如人、團隊、組織、部門或其他系統。 找出作業處理 先整理出系統範圍內所涉及之企業功能或企業程序，企業功能盡可能再分解成有意義且有關聯的企業處理(Business Process)。

3.3.3 流程圖(3/4) 作業處理可由執行該處理或與該處理有互動關係的實體來找出，每一處理應有清楚的輸入，新增或修改後的資料為其輸出。 檢視外部實體 逐一檢討每一實體，以找出會主動引發刺激或事件之主要實體。一個主要實體可能會有一至多個主動刺激，並由每一刺激或事件開始找出其所引發之一系列高度相關之處理步驟，以形成一個流程圖。

3.3.3 流程圖(4/4) 繪製流程圖 繪製流程圖時，應由流程圖之上方或左上方開始畫起，接著依企業作業流程之發生順序畫出作業處理及流程方向，而在流程的最後以一結束符號作為流程之結束。 檢視流程圖 檢查所有流程圖之完整性，也就是所有流程圖是否涵蓋整個系統範圍。

3.3.4 處理描述 處理描述進一步地表達每個處理之執行步驟、規則、控制等，並說明其資料之輸入和輸出內容與所涉及之外部實體。 每個處理描述之名稱應與流程圖中之作業處理同名，處理描述之表達形式可如下所示。

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

3.3.6 資料詞彙(1/3) 資料詞彙(Data Glossary)進一步說明藍圖無法表達之內容，如資訊之長度、型態、格式、公式、規則、範圍與限制等，並分別舉例說明之。 基本上，一張藍圖有其對應之資料詞彙，藍圖中每一欄位在資料詞彙中應有一記錄描述之。 資料詞彙之內容與格式之考量，應以能具體掌握與進一步表達資訊需求為原則。

3.3.6 資料詞彙(2/3) 資料詞彙中，規則、格式、範圍、公式等資訊可使用資料字典的格式來表達。 資料字典以文字的方式輔助資訊之顯示，其為系統所有資料元素定義之集合。 資料字典之表達符號與意義如下 符　號 意　義 x = a + b x由a與b組成 x = [a | b] x為a或b x = a +(b) x為a或a與b的組合 x = {a} x由零個、一個或多個a組成

3.3.6 資料詞彙(3/3) 客戶訂單＝客戶名稱 ＋訂單編號 ＋〔送貨地址｜自行取貨〕 ＋（售貨員） ＋｛訂單項目｝ 以下範例說明客戶訂單的資料元素可被定義成如下之組合與架構： 定義客戶訂單後，需再對其中之資料元素提供適當的說明。例如： 客戶訂單＝客戶名稱 　　　　　＋訂單編號 　　　　　＋〔送貨地址｜自行取貨〕 　　　　　＋（售貨員） 　　　　　＋｛訂單項目｝ 訂單項目＝零件號碼＋（零件名稱）＋數量＋單價＋（折扣）

3.4 需求分析結果與文件樣板 完成需求分析與確認後，需求分析結果之文件應包括該階段中重要工作結果之摘述。 需求分析結果之文件樣板如下：

3.5 需求分析個案 需求分析依3.1節概念分為需求擷取與需求轉換兩大步驟，其中，需求轉換主要以流程圖配合藍圖、資料詞彙與環境圖等進行需求塑模。 本節將以一「夢幻公司之管理資訊系統（以下簡稱夢幻系統）」為例，針對其使用者與企業巨觀需求，介紹如何以環境圖、流程圖、處理描述、藍圖與資料詞彙表達其欲電腦化的環境、作業程序與範圍、輸入與輸出所需資訊或表單及系統目標、限制和主要功能。

 3.5.1 案例介紹與需求描述(1/4) 系統開發背景 夢幻公司從事汽機車零件買賣，其為掌握市場，決定建置一管理資訊系統，並將系統委由WULAB 公司進行資訊系統之開發。 夢幻公司之專案指導團隊與WULAB 公司之專案開發團隊經多次討論，將夢幻系統的目標與限制、使用者與企業需求描述分別整理如下：

 3.5.1 案例介紹與需求描述(2/4) 系統目標與限制 建立一Web-based管理資訊系統，使夢幻公司之客戶、生產部與業務部能在線上完成所有的營運管理。 此管理資訊系統須提供表單資料維護的功能。 夢幻公司之客戶、生產部與業務部不論使用哪一種瀏覽器上網，須看到相同的介面，並於權限內執行所有的操作功能。

3.5.1 案例介紹與需求描述(3/4) 使用者與企業需求描述  3.5.1 案例介紹與需求描述(3/4) 使用者與企業需求描述 客戶以系統新增訂單後，由業務部負責接收。當接到客戶的訂貨通知時，須先進行訂貨資料登錄，並作成品庫存檢核。若成品庫存不足，則傳送生產需求通知生產部，以便進行生產計畫。 若成品庫存充足，則業務部直接進行送貨處理，如計算送貨總金額、遞送成品等，並傳送送貨單給客戶確認。 業務部收到客戶欲退回已銷售之成品通知（銷退單），需記錄客戶編號及銷退之成品數量、單價，並計算銷退單之銷退總金額等。

3.5.1 案例介紹與需求描述(4/4) 業務部向客戶請款： 針對各客戶之本期送貨資料，計算出本期應收帳款。  3.5.1 案例介紹與需求描述(4/4) 業務部向客戶請款： 針對各客戶之本期送貨資料，計算出本期應收帳款。 每月請款一次，請款日期為每月25日。 合計上期未收款項及本期應收帳款後，傳送請款單請客戶付款。 業務部收到客戶之付款證明，登錄客戶編號及付款資料後，儲存該次登帳紀錄（付款單）。

 3.5.2 需求塑模—建構環境圖(1/3) 整理事件條列式，如表3-7所示。

 3.5.2 需求塑模—建構環境圖(2/3) 找出外部實體 由使用者與企業需求描述中之名詞、代名詞與名詞片語等，找出合乎外部實體定義的人、組織、物件或相關系統。 上表之更簡潔事件條列式中的名詞包括客戶、訂單、業務部、訂貨通知、訂貨資料、成品庫存、生產需求、生產部等，其中只有客戶、業務部和生產部與系統有互動關係，合乎外部實體的定義，為本案例中之外部實體。

3.5.2 需求塑模—建構環境圖(3/3) 找出系統與外部實體之關係  3.5.2 需求塑模—建構環境圖(3/3) 找出系統與外部實體之關係 系統與外部實體之關係可由更簡潔的事件條列式來找出，例如第一項事件條列式是由客戶所啟動，其他事件條列式以此類推。 繪製環境圖 完成事件之整理工作並找出外部實體及其與系統之關係後，便可將外部實體與系統繪製成環境圖，將事件編號並依外部實體啟動與被影響實體之方向將事件條列式標示於箭頭上。

圖3-3 夢幻資訊系統環境圖 A01.客戶＋新增＋訂單 A03.客戶＋新增＋銷退單 A05.客戶＋新增＋付款證明 …

3.5.3 需求塑模—建構流程圖(1/6) 建構流程圖之步驟依序為： 找出外部實體 找出作業處理 檢視外部實體 繪製流程圖 檢視流程圖

3.5.3 需求塑模—建構流程圖(2/6) 由使用者與企業需求描述和事件條列式得知，前兩項作業可連續發生，也就是客戶訂貨，若無足夠庫存，則進行生產計畫；若有足夠庫存，則可馬上送貨，其餘三項作業均各自獨立。 可將前兩項使用者與企業需求合併為訂單送貨流程，而其餘三項需求分別為銷退處理流程、請款處理流程與登帳處理流程。 以訂單送貨流程為例，其流程圖、處理描述、藍圖和詞彙說明如下。

3.5.3 需求塑模—建構流程圖(3/6) 流程圖1 由事件條列式與環境圖得知，在訂單送貨流程中，有三個外部實體參與，分別為：客戶、業務部與生產部。 前兩項作業中有訂貨與送貨兩個基本作業處理、一個庫存檢核控制，以及產出三張基本表單：訂單、送貨單與生產需求。 首先由客戶送出訂單來起始該流程，接著業務部進行訂單處理、庫存檢核與送貨處理或輸出生產需求。最後，流程終止於客戶收到送貨單或生產部收到生產需求。

圖3-4 訂單送貨流程圖

3.5.3 需求塑模—建構流程圖(4/6) 處理描述1-1 以訂單送貨流程之訂單處理為例（參考圖3-4），其資料來源為客戶之訂單，且產出為生產部之生產需求或進行送貨處理。 訂單處理之處理描述名稱可命名為訂單處理與庫存判斷，該處理描述與庫存判斷之執行程序與規則，可從上述需求描述摘述如表3-8。 流程圖中，每一處理應有一處理描述，每一處理描述應有一致的表達格式。

表3- 8 訂單處理描述

3.5.3 需求塑模—建構流程圖(5/6) 藍圖1-1 以訂單送貨流程之訂單為例，其藍圖基本上可以該公司目前之訂單報表為基礎，再進一步對訂單上的每一欄位，以由上而下、由左至右之原則編號，例如客戶編號為A、地址為B，依序至總金額為O等，詳如右表所示。

3.5.3 需求塑模—建構流程圖(6/6) 資料詞彙1-1 每張藍圖應有一份資料詞彙，且藍圖中之每一欄位在資料詞彙中應有一記錄描述之。 因此以夢幻公司之訂單藍圖為例（參表3-9），採用資料詞彙樣板（參表3-4），再經由訪談整理後，其訂單藍圖之資料詞彙可整理如表3-10。

表3-10 訂單資料詞彙

3.6 結論(1/2) 需求分析的過程主要是擷取與表達使用者之巨觀需求，這包括欲電腦化之環境、作業處理、輸出與輸入所需之資訊或表單與系統主要功能等。 需求分析階段對問題領域之瞭解範圍應盡可能地廣泛，到了分析與設計階段再縮小到專案範圍，如此有助於對新系統之瞭解與規劃。

3.6 結論(1/2) 以目前之開發工具來說，需求分析工作約占整個專案時間的25%左右，且需求分析往往無法在一個階段內完全做完，常在分析與設計階段仍有需求分析工作之進行。 系統分析師之專業知識與經驗，對需求分析之成效有密切之影響。