Chapter 3 需求工作流程.pptVIP

Chapter 3 需求工作流程 學習概要 需求工作流程 需求工作流程（Requirement Workflow）中的大部分工作，會出現在專案啟始和細部評估階段。 描繪出系統該有哪些功能的抽象層次規格是需求工程（Requirements Engineering）的一部分。 需求工程是關於如何導引出這些關鍵人員的需求，並區分出其優先次序的一門學問，需求工程也是談判的過程，尤其是當需求有衝突但又非得取得平衡的時候。 需求工程的描述模型 需求工作流程細節 需求的重要性 需求不完整以及缺少使用者參與是導致專案失敗最主要的兩個原因，兩者的起因都是因為需求工程失敗所導致的。 最後當軟體系統取決於一組需求時，有效的需求工程便會成為軟體開發專案是否成功的重要關鍵。 定義需求 需求是「該被開發出來的規格」 基本上有兩種需求： 功能性需求─系統該提供什麼樣的行為； 非功能性需求─系統的特性或限制。 需求應該僅說明系統該做什麼(What)而已，而不是直接說明系統該怎麼做(How) 需求模型 UP有一個正規的需求描述方式，它是採用使用案例模型來說明需求的內容，我們以傳統功能性與非功能性需求的想法為基礎，再加上需求模型來加強描述需求的內容。 使用案例模型通常是透過一套UML模塑工具來建立，如Rational Rose 需求模型則可能是用文字或是特別的需求工程工具來建立，如RequisitePro()或DOORS()。 好的需求描述格式 建議用一個非常簡單的格式來描述需求的內容。每個需求都有一個唯一碼（通常是數字）、一個關鍵字（Shall）以及一段對功能的描述。 功能性需求 功能性需求是在描述系統應該要做什麼，它是一段系統功能的描述。例如： 自動提款機系統會檢查插入的金融卡之有效性。 自動提款機系統會驗證客戶所輸入的PIN碼。 自動提款機系統會限制每一張金融卡24小時內領出之金額不得超過250美元。 非功能性需求 非功能性需求則是指一個系統的限制。例如： 自動提款機系統會用C++開發。 自動提款機系統會用256位元的加密方式與銀行連線。 自動提款機系統會在3秒內驗證完一張金融卡。 自動提款機系統會在3秒內驗證完PIN碼。 利用分類表來整理需求 如果有在使用需求管理工具，便能夠整理需求到一個分類表（Taxonomy）中。 需求屬性 每個需求都有一組屬性來記錄關於需求額外的資訊(描述資料；Metadata) 每個需求屬性都是一個可描述的名稱以及數值。例如 一個需求可以有一個名為完成日期（dueDate）的屬性，同時這屬性有一個日期的數值是這需求非得完成的日期。 最常見的需求屬性是要需求的優先順序（Priority），此屬性的數值是指該需求在所有需求中的優先順序，普遍用來指定優先順序的是MoSCoW代碼。 需求來自於 系統的直接使用者； 其他關鍵人員（例如，管理者、維護者、安裝人員）； 與此系統互動之其他系統； 與此系統互動之硬體設備； 法律和管制限制； 技術限制； 商業目標。 撰寫願景文件 一般而言，需求工程一開始會用願景（Vision）文件來描繪此系統欲達成的目標，以及系統開發完成後對關鍵人員的好處，這樣一份文件最主要是希望從關鍵人員的觀點中掌握系統開發的目標，並由系統分析人員於UP專案起始階段產出，產出願景文件之後，需求工程才算真正的開始。 需求訪談的技巧 還原需求 訪談 問卷 研討會 本章總結 * *