主题：需求分析与撷取.pptVIP

主題：需求分析與擷取 需求擷取 計畫開始的首要工作 首要工作在於需求的擷取與分析 根據許多的研究顯示，一個計畫之所以會失敗的原因之一常常是因為計畫初期對於即將開發之系統所應提供的功能沒有確切的了解與掌握。 基本上，一個無法滿足使用者需求的系統，不論所採用之資訊技術為何，其最終的命運均可想而知。(WHAT) 領域方析 (Domain Analysis) 需求擷取的第一要務：領域分析 卡內基美隆(Carnegie Mellon)軟體工程學院對於領域分析所下的定義： 根據既有系統及其開發的歷史、領域專家的知識、背後的理論，辨別、收集以及組織相關資訊的過程。 簡單地說，就是從各方面對目前既有的系統做資料蒐集。 現有系統、需求訪談…，談談您的專題 蒐集範圍與種類 在資料搜集的過程中，不要限定範圍或是種類，舉凡是跟領域問題有關聯的都要蒐集起來。 任何資料都能讓你對於計劃領域有更深一層的了解。 針對特定的需求，決定你要蒐集的方向，也就是跟計畫密切相關的資料。 您的經驗談： 領域專家（Domain expert） 領域分析是系統開發前的預備知識 對於待開發產品之背景資料分析與蒐集越完整、對於產品領域知識與操作越了解，越能在將來做出好的決策。 領域分析過程，會接觸到許多與計劃相關的人員 領域專家：對領域有深度了解的人 包括計畫的客戶、既有系統的使用者…等等 對企業的各項活動以及業務流程最熟悉 這些人將在系統開發的分析階段扮演著重要角色 了解領域知識的好處（1） 可以有效率的和客戶溝通 一般從事領域分析的大多是系統分析師 有時候，也包括負責計畫的經理(專案經理)，他是開發團隊與客戶的主要對話窗口 嚴格來說，參予計畫的每一個成員都必須對相關的領域有基本的認識與了解 可以增進開發團隊(具備專業資訊技術)與客戶(通常缺乏資訊技術專業知識)之間的溝通 了解領域知識的好處（2-3） 了解企業既有的(As-is)流程活動，對於即將開發(To-be) 的系統會有實質的幫助 對經常可能變動的企業邏輯 (Business logic)或是商業規則(Business rule)，尤其重要。 預留未來新系統的開發空間 在為客戶開發系統的同時，會對其業務有更深一層的了解。 客戶許多既有的業務流程可以利用資訊系統的優點來改進，幫助企業提升執行效率、工作生產力、降低成本開銷等等。 可以經由與客戶高階執行階層討論與提出建議，進而向客戶提出計畫書，為另一個新的計畫做準備。 擷取方式 了解需求擷取的重要性後，接著來看一下需求擷取有哪些方式？ 需求擷取的方式有很多，比較常用的方式如下 企業既有的報表、表單、操作流程相關文件 訪談 定期開會討論 其他：觀察、問卷調查、腦力激盪、JAD (Joint Applications Design/Development)會議… 既有的報表、表單 努力完整的搜集任何與開發中計畫相關之報表、表單。(例如：成績單、請假單、維修單) 這些資料的主要來源為企業內既有的文件、業務流程說明、工作內容、作業描述等等。 仔細閱讀這些資料，以了解企業的核心流程，企業功能以及企業規則，幫助自己建立對該企業的一個普遍認識。 對於人工作業時所採用之單據更需要仔細蒐集和保留。 專題需要的報表與表單： 表單樣本：訂購單 訪談 需求擷取方法中相當常用的一種方式 透過訪談，可以跟使用者面對面討論與溝通，對於使用者的需求能夠有較真實的體驗。 訪談之前，必須要有詳細規劃(事半功倍)，應該包括： 決定訪談對象 設定訪談的議題 準備相關事宜 訪談之後，必須將其結果詳實地紀錄下來 訪談注意事項 讓訪談有個目標，避免讓訪談變成聊天。例如：可先列舉所要討論的問題在一張紙上。 開始的問題： 你希望系統提供什麼樣的功能？ 目前你們對這項工作的作業流程是如何進行的？ 從這些問題當中可以引領出許多與技術面、執行面、操作面等等相關的討論議題 訪談對象的選取要跟訪談內容相關 例如：如果要了解一項特定的作業程序，訪談對象最好是執行此作業的人員，而不是資深經理。 定期開會討論 系統開發的過程中，規劃定期開會的時間表 除了管理層面的定期開會討論之外，有時候它也用在技術面的討論上。 開會目的：處理系統開發過程中的變數 檢視計畫的進度與執行結果 確認工作細節 確認需求的正確性 各項相關任務的分派 人力資源的調度…等等事項 舉行定期的開會討論為一個有效的管理方式 需求分析 利用各種需求擷取的方式，獲得許多跟即將開發的系統相關的資料。 這些資料可能很凌亂，雜亂無章，因此必須將這些資料做整理與分析。 對於所擷取之需求資料可以分為兩大類： 功能的需求 (Functional requirement) 非功能的需求(Non-functional requirement) 需求分析 功能需求