软体需求.ppt

軟體需求 系統的描述與規格說明 需求工程 依據客戶對系統的需求以及系統運作與開發時的限制來建立服務的程序 需求本身是需求工程程序期間所產生的系統服務與限制的描述 何謂需求？ 從某個服務或系統限制的高階抽象敘述到詳細的數學式功能規格 需求通常有兩種功能 它可以當成合約招標的基礎，因此必須容易解釋 它可以當成合約本身的基礎，因此必須詳細定義 這兩項敘述均可稱為需求 需求類型 使用者需求 以自然語言和圖表所形成的敘述，用來描述系統能夠提供的服務以及運作時的一些限制條件。這些需求是專為客戶所撰寫的 系統需求 以結構化的文件更詳細的定義系統的服務與限制條件。以客戶和承包商之間的合約方式撰寫 軟體設計規格 詳細的軟體描述，用來當成設計和實作的基礎。專為開發者所撰寫 定義與規格 需求的讀者 功能與非功能需求 功能需求(Functional requirements) 描述系統應該提供的服務、系統對特殊輸入的回應方式以及系統在特殊情況下的行為等敘述 。 非功能需求(Non-functional requirements) 服務的限制條件或是系統提供的功能，包括時間上的限制、開發程序上的限制和標準等。 領域需求(Domain requirements) 來自系統應用領域的需求以及該領域所反映的特性，這種需求可以是功能性或非功能性的需求。 功能需求 描述系統功能或服務 依據軟體的類型、預期的使用者以及應用此軟體的系統類型而定 功能性的使用者需求可以是說明系統應該做什麼的高階敘述；功能性的系統需求則應該詳細描述系統的服務 功能需求的範例 使用者必須能夠搜尋整個資料庫或是選擇某個子集做搜尋。 系統必須提供適當的檢視器，讓使用者可以閱讀文件資料庫中的文件。 每一筆預定的書單必須配置一個唯一的識別碼（ORDER_ID），而且必須能夠讓使用者將這個碼複製到其帳戶的永久儲存區。 需求不精確 當需求沒有精確的描述就會發生的問題 模凌兩可的需求會被開發者和使用者解釋成各種可能 以前面範例中的「適當檢視器 」為例 使用者的目的 – 為每個不同文件類型所使用的特殊用途檢視器 開發者的解釋 – 提供能夠顯示文件內容的文字檢視器 需求的完整性與一致性 原則上，需求應該是完整且一致的 完整 它們應該包含所有需求功能的描述 一致 系統功能描述中不應該有衝突或矛盾的地方 實際上，不太可能產生完整且一致的需求文件 非功能需求 定義系統特性與限制，例如：可靠度、回應時間以及儲存需求。限制則如 I/O 裝置的容量、系統表示方式等。 非功能需求也可以指定程序需求，限制使用特定的 CASE 系統、程式語言或是開發方法等 非功能需求可能比功能需求還重要，如果沒有符合這些需求，系統就沒有用 非功能需求的分類 產品需求 指定交付的產品必須以某種特定方式運作的需求，例如：執行速度、可靠度等。 組織需求 因應組織政策與程序的需求，例如：使用的程序標準、實作需求等。 外部需求 系統與開發程序之外的影響因素所引起的需求，例如：互通需求、法律需求等。 目的與需求 非功能需求可能不容易精確的陳述，而不精確的需求則更難以進行驗證。 目的 使用者的一般目的，例如容易使用 可驗證的非功能需求 使用某些可以客觀測試的度量值來敘述 這些目的對開發者是有幫助的，因為它們可以傳送系統使用者的目的 需求的度量值 需求的互動 不同的非功能需求產生衝突的情形在複雜系統中是常見的現象 太空船系統 為了減輕重量，系統使用的晶片數量必須減少 為了減少電力的消耗，必須使用低電力的晶片 然而，若使用低電力的晶片可能需要更多的晶片數量。這時候，哪一個需求是最重要的需求？ 領域需求 衍生自應用領域，描述能夠反應領域的系統特性與功能 可能是新的功能需求、對現有需求的限制或是定義特定的運算條件 若不能滿足領域需求，系統可能就無法運作 領域需求的問題 理解性 需求是以某應用領域特定的語言來表示 開發系統的軟體工程師對這些語言通常都不太能夠瞭解 隱含性 領域專家非常熟知他的領域，所以通常不會以明確的方式來訂定領域需求 使用者需求 應該以功能或非功能需求來描述，以便讓不熟悉詳細技術知識的系統使用者能夠理解 使用者需求是以自然語言、表格和圖表來定義 自然語言的問題 不夠清楚 使用語言時有時候很難精確、清楚的描述 需求混淆 功能與非功能需求可能會產生混淆 需求混合 將好幾種不同需求一同表示 需求的問題 資料庫需求包含了概念和詳細的資訊 它描述了組態控制功能的概念 又包含一些詳細資訊，指出物件可以使用不完全的名稱來存取 格線需求混合了三個不同的需求 概念性的功能需求 (格線的需求) 非功能需求 (格線單位) 非功能的 UI 需求 (格線切換) 撰寫需求的指引 創造一個標準的格式，並且確保所有需求定義都支持這個格式。 使用更一致性