软体需求96.pptVIP

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