定义需求.ppt

Chapter 04 定義需求 學習目標 ? 說明問題陳述(problem statement)的概念 ? 辨別需求類型 ? 說明收集需求的程序 ? 辨別在收集需求時常見的陷阱 需求工作流程 需求工作流程（Requirement Workflow）中的大部分工作，會出現在專案啟始和細部評估階段。 描繪出系統該有哪些功能的抽象層次是需求工程（Requirements Engineering）的一部分。 需求工程的描述模型 需求的重要性 需求不完整以及缺少使用者參與是導致專案失敗最主要的兩個原因，兩者的起因都是因為需求工程失敗所導致的。 最後當軟體系統取決於一組需求時，有效的需求工程便會成為軟體開發專案是否成功的重要關鍵。 定義需求 需求是「該被開發出來的規格」 基本上有兩種需求： 功能性需求─系統該提供什麼樣的行為； 非功能性需求─系統的特性或限制。 需求應該僅說明系統該做什麼(What),系統該提供那些功能而已，而不是直接說明系統該怎麼做(How)，如何達到那些功能。 需求模型 UP有一個正規的需求描述方式，它是採用使用案例模型來說明需求的內容，我們以傳統功能性與非功能性需求的想法為基礎，再加上需求模型來加強描述需求的內容。 使用案例模型通常是透過一套UML模塑工具來建立，如Rational Rose, Microsoft Visio, ArgoUML,….. 好的需求描述格式 建議用一個非常簡單的格式來描述需求的內容。每個需求都有一個唯一碼（通常是數字）、一個關鍵字（Shall）以及一段對功能的描述。 功能性需求 (透過使用案例來描述) 功能性需求是在描述系統應該要做什麼，它是一段系統功能的描述。例如： 自動提款機系統會檢查插入的金融卡之有效性。 自動提款機系統會驗證客戶所輸入的PIN碼。 自動提款機系統會限制每一張金融卡24小時內領出之金額不得超過250美元。 非功能性需求(不適合透過使用案例來描述) 非功能性需求則是指一個系統的限制。例如： 自動提款機系統會用C++開發。 自動提款機系統會用256位元的加密方式與銀行連線。 自動提款機系統會在3秒內驗證完一張金融卡。 自動提款機系統會在3秒內驗證完PIN碼。 功能性需求 (透過使用案例來描述) 功能性需求是在描述系統應該要做什麼，它是一段系統功能的描述。例如： 數位學習平台要提供教師能掛入數位課程。 數位學習平台要提供學生選課的功能。 數位學習平台要提供課程有線上考試的功能。 數位學習平台可提供追蹤學生學習成果的功能。 非功能性需求(不適合透過使用案例來描述) 非功能性需求則是指一個系統的限制。 數位學習平台應有同時提供20使用者同時上線使用的能力。 數位學習平台應有持續運作24小時不當機的能力。 數位學習平台應有對上載的教材有掃毒的功能。 數位學習平台應能儲存使用者資料10以上。 非功能性需求 非功能性需求通常涉及 系統的限制: 效能, 標準。 軟體安全度。 軟體維護度。 軟體可靠度。 利用分類表來整理需求 如果有在使用需求管理工具，便能夠整理需求到一個分類表（Taxonomy）中。 需求屬性 每個需求都有一組屬性來記錄關於需求額外的資訊(描述資料；Metadata) 每個需求屬性都是一個可描述的名稱以及數值。例如 一個需求可以有一個名為完成日期（dueDate）的屬性，同時這屬性有一個日期的數值是這需求非得完成的日期。 最常見的需求屬性是要需求的優先順序（Priority），此屬性的數值是指該需求在所有需求中的優先順序，普遍用來指定優先順序的是MoSCoW代碼。 MoSCoW代碼 需求類型 商務程序(Business process) 限制(Constraints) 規則(Rules) 績效(Performance) 限制(Constraints) 收集需求(Requirements) 使用者的經驗與技能會限制系統的需求。 主要使用者只要有欄位可直接輸入資料即可, 但一般使用者卻希 望能供下拉式的選單供選擇。 分析(Analysis) 法律、契約或產業標準可能會嚴格限制系統的規格。 存貨系統必須遵循會計原則的限制，在存入貨物之後也必須同時告知會計部門，準備付款事宜。 設計(Design) 系統所採用的Program Language、DB、Middleware…，都會限制到系統資料欄位的型態、資料的交換或通訊協定。 實作(Implementation) 實作部份的限制經常與cost相關。 在倉庫中欲採用RFID技術，但隔壁變電所產生太太干擾，先要發大 筆經費來解決干擾的問題。 需求訪談的技巧 訪談 (key m