《软体需求》PPT课件.ppt

軟體需求,系統的描述與規格說明,本章目的,介紹使用者需求和系統需求的概念瞭解功能與非功能需求的差異說明描述系統需求的兩項技術說明如何將軟體需求組織成一份需求文件,本章內容,功能與非功能需求 使用者需求系統需求 軟體需求文件,需求工程,依據客戶對系統的需求以及系統運作與開發時的限制來建立服務的程序需求本身是需求工程程序期間所產生的系統服務與限制的描述,何謂需求？,從某個服務或系統限制的高階抽象敘述到詳細的數學式功能規格需求通常有兩種功能它可以當成合約招標的基礎，因此必須容易解釋它可以當成合約本身的基礎，因此必須詳細定義這兩項敘述均可稱為需求,需求類型,使用者需求以自然語言和圖表所形成的敘述，用來描述系統能夠提供的服務以及運作時的一些限制條件。這些需求是專為客戶所撰寫的系統需求以結構化的文件更詳細的定義系統的服務與限制條件。以客戶和承包商之間的合約方式撰寫軟體設計規格詳細的軟體描述，用來當成設計和實作的基礎。專為開發者所撰寫,定義與規格,需求的讀者,功能與非功能需求,功能需求(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系統不能公開顧客的任何個人資訊，除了他們的姓名和系統操作人員的聯絡電話之外,目的與需求,非功能需求可能不容易精確的陳述，而不精確的需求則更難以進行驗證。目的使用者的一般目的，例如容易使用可驗證的非功能需求使用某些可以客觀測試的度量值來敘述這些目的對開發者是有幫助的，因為它們可以傳送系統使用者的目的,範例,系統目的系統應該讓有經驗的管理人員用起來容易，它也應該能夠減少使用者的錯誤。可驗證的非功能需求有經驗的管理人員必須能夠在兩個小時的訓練之後即可使用所有系統功能。訓練之後，有經驗的使用者在一天內可能發生的平均錯誤量不得超過兩次。,需求的度量值,需求的互動,不同的非功能需求產生衝突的情形在複雜系統中是常見的現象太空船系統為了減輕重量，系統使用的晶片數量必須減少為了減少電力的消耗，必須使用低電力的晶片然而，若使用低電力的晶片可能需要更多的晶片數量。這時候，哪一個需求是最重要的需求？,領域需求,衍生自應用領域，描述能夠反應領域的系統特性與功能可能是新的功能需求、對現有需求的限制或是定義特定的運算條件若不能滿足領域需求，系統可能就無法運作,圖書館系統的領域需求,所有資料庫都必須有一個標準的使用者介面，而且必須符合Z39.50的標準。由於版權的限制，有些文件拿到之後必須立即刪除。根據使用者的需求，這些文件可以在系統伺服器上列印，再以手動方式轉送給使用者，或是直接轉送到網路印表機列印。,火車保護系統,火車的減速速率必須依據下列公式計算：Dtrain=Dcontrol+Dgradient 其中的 Dgradient 為 9.81ms2 補償後的gradient/alpha，9.81 ms2/alpha 的值是已知的不同類型火車。,領域需求的問題,理解性需求是以某應用領域特定的語言來表示開發系統的軟體工程師對這些語言通常都不太能夠瞭解隱含性領域專家非常熟知他的領域，所以通常不會以明確的方式來訂定領域需求,使用者需求,應該以功能或非功能需求來描述，以便讓不熟悉詳細技術知識的系統使用者能夠理解使用者需求是以自然語言、表格和圖表來定義,自然語言的問題,不夠清楚 使用語言時有時候很難精確、清楚的描述需求混淆 功能與非功能需求可能會產生混淆需求混合 將好幾種不同需求一同表示,資料庫需求,4.A.5 資料庫必須能夠支援組態物件的產生與控制；也就是資料庫中的物件可以自行和其他物件組成群組。組態控制的機制必須能夠以不完整的名稱存取不同版本群組中的物件。,Editor grid requirement,2.6 格線功能 為了幫助圖表中實體的定位，使用者可以透過控制台中的選項開啟以公分或英吋計的格線功能。開始的時候，格線功能為關閉的。在編輯階段，使用者可以任意開啟和關閉格線，也可以任意切換英吋或公分的格線單位。格線選項將提供於最適大小檢視中，但顯示的格線將會減少，以避免小型圖表會根據格線填入。,需求的問題,資料庫需求包含了概念和詳細的資訊它描述了組態控制功能的概念又包含一些詳細資訊，指出物件可以使用不完全的名稱來存取格線需求混合了三個不同的需求概念性的功能需求(格線的需求)非功能需求(格線單位)非功能的 UI 需求(格線切換),結構化的表示方式,詳細的使用者需求,撰寫需求的指引,創造一個標準的格式，並且確保所有需求定義都支持這個格式。使用更一致性的言語，特別要將強制和渴望的需求區分清楚。強制的需求通常使用必須(shall)來定義，渴望的需求則使用應該(should)利用其他字型（粗體和斜體字）強調需求的主要部分儘量避免使用電腦術語,系統需求,比使用者需求更詳細的規格設計系統的基礎可以用來當成系統合約的一部分系統需求可以利用第 7 章即將介紹的系統模型來表示,需求與設計,原則上，需求應該陳述系統應該做什麼；而設計應該描述如何做到事實上，需求和設計是不可分的利用系統架構可以建立需求的結構系統可以和其他系統互動以產生設計需求使用的特定設計可能是領域的需求,NL 規格的問題,意義不明確撰寫與閱讀需求的人必須使用同樣的方式來詮釋相同的文字，不過因為自然語言的特性具有模糊性，所以可能會造成許多誤解太過彈性規格中，同一件事情可能會有許多不同講法缺乏模組化NL 的結構並不適合建構系統需求的結構,NL 規格的替代表示法,結構化語言的規格,使用自然語言的限制格式可以表示需求它可以消除模糊與彈性所造成的問題，並且可以讓規格有某種程度的統一性通常是以表單式的方式來支援,表單式規格,定義功能或實體描述輸入資料以及它們的來源描述輸出資料以及它們的去處指示其他所需的實體前條件與後條件副作用,表單式的節點規格,PDL式的需求定義,需求也可以利用像程式語言的操作性語言來定義，讓表示方式可以更具彈性的最適合兩種情況當操作是以一連串的動作來指定，而且其順序很重要時必須指定硬體和軟體介面時缺點PDL 的表述能力可能不足以用來定義領域概念它只能做為設計的規格，無法做為幫助使用者瞭解系統的模型,ATM 規格的 PDL 描述,PDL 的缺點,PDL 可能無法以容易理解的方式表達系統所提供的功能它的表示方式只能讓具有程式設計語言知識的人瞭解這種需求可能只能當成設計的規格，無法做為幫助使用者瞭解系統的模型,介面規格,大部分的系統必須和其他系統一起運作，所以操作介面的指定必須當成需求的一部分必須定義三種類型的介面程序性的介面交換的資料結構資料表示方式正規的標示法可以比較有效的定義介面的規格,PDL 的介面描述,需求文件,需求文件是一份用來說明系統開發者需求的正式文件它必須包含需求的定義和規格但是它不是一份設計文件，它必須設定系統應該做什麼(What)；而不是如何做(How),需求文件的使用者,需求文件的需求,指定外部的系統行為指定實作的限制容易做變更當成維護時的參考工具記錄系統生命週期的未來考慮，亦即預期的變更列出非預期事件的回應特徵,IEEE 的需求標準,簡介一般說明特定需求附錄索引這只是通用的結構，必須針對特定的系統做修正,需求文件結構,簡介詞彙使用者需求定義系統架構系統需求規格系統模型系統演化附錄索引,重點整理,需求是設定系統應該做的事，以及定義運作與實作時的限制條件功能需求設定系統應該提供的服務非功能需求則是用來限制欲開發的系統或是開發程序使用者需求則是定義系統應該做什麼事的高階陳述,重點整理,使用者需求應該以自然語言、表格和圖表的方式來撰寫系統需求則是以精確方式來傳達系統必須提供的功能 系統需求可以用結構化的自然語言、PDL或是正規的語言來撰寫 軟體需求文件是一份已議定的系統需求陳述文件,