《软体需求》PPT课件.ppt
《《软体需求》PPT课件.ppt》由会员分享,可在线阅读,更多相关《《软体需求》PPT课件.ppt(53页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 1軟體需求 l系統的描述與規格說明 Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 2本章目的 l介紹使用者需求和系統需求的概念l瞭解功能與非功能需求的差異l說明描述系統需求的兩項技術l說明如何將軟體需求組織成一份需求文件Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 3本章
2、內容 l功能與非功能需求 l使用者需求l系統需求 l軟體需求文件Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 4需求工程 l依據客戶對系統的需求以及系統運作與開發時的限制來建立服務的程序l需求本身是需求工程程序期間所產生的系統服務與限制的描述Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 5何謂需求?l從某個服務或系統限制的高階抽象敘述到詳細的數學式功能規格l需求通常有兩種功能它可以當成合約招標的基礎,因此必須
3、容易解釋它可以當成合約本身的基礎,因此必須詳細定義這兩項敘述均可稱為需求Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 6需求類型l使用者需求以自然語言和圖表所形成的敘述,用來描述系統能夠提供的服務以及運作時的一些限制條件。這些需求是專為客戶所撰寫的l系統需求以結構化的文件更詳細的定義系統的服務與限制條件。以客戶和承包商之間的合約方式撰寫l軟體設計規格詳細的軟體描述,用來當成設計和實作的基礎。專為開發者所撰寫Ian Sommerville 2000 Software Engineering,6th ed
4、ition.Chapter 5 Slide 7定義與規格Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 8需求的讀者Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 9功能與非功能需求l功能需求(Functional requirements)描述系統應該提供的服務、系統對特殊輸入的回應方式以及系統在特殊情況下的行為等敘述。l非功能需求(Non-functional requirements)服務的限制條件或是系統
5、提供的功能,包括時間上的限制、開發程序上的限制和標準等。l領域需求(Domain requirements)來自系統應用領域的需求以及該領域所反映的特性,這種需求可以是功能性或非功能性的需求。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 10功能需求l描述系統功能或服務l依據軟體的類型、預期的使用者以及應用此軟體的系統類型而定l功能性的使用者需求可以是說明系統應該做什麼的高階敘述;功能性的系統需求則應該詳細描述系統的服務Ian Sommerville 2000 Software Engineering
6、,6th edition.Chapter 5 Slide 11功能需求的範例l使用者必須能夠搜尋整個資料庫或是選擇某個子集做搜尋。l系統必須提供適當的檢視器,讓使用者可以閱讀文件資料庫中的文件。l每一筆預定的書單必須配置一個唯一的識別碼(ORDER_ID),而且必須能夠讓使用者將這個碼複製到其帳戶的永久儲存區。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 12需求不精確l當需求沒有精確的描述就會發生的問題l模凌兩可的需求會被開發者和使用者解釋成各種可能l以前面範例中的適當檢視器 為例使用者的目的 為每
7、個不同文件類型所使用的特殊用途檢視器開發者的解釋 提供能夠顯示文件內容的文字檢視器Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 13需求的完整性與一致性l原則上,需求應該是完整且一致的l完整它們應該包含所有需求功能的描述l一致系統功能描述中不應該有衝突或矛盾的地方l實際上,不太可能產生完整且一致的需求文件Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 14非功能需求l定義系統特性與限制,例如:可靠度、回應時間以
8、及儲存需求。限制則如 I/O 裝置的容量、系統表示方式等。l非功能需求也可以指定程序需求,限制使用特定的 CASE 系統、程式語言或是開發方法等l非功能需求可能比功能需求還重要,如果沒有符合這些需求,系統就沒有用Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 15非功能需求的分類l產品需求指定交付的產品必須以某種特定方式運作的需求,例如:執行速度、可靠度等。l組織需求因應組織政策與程序的需求,例如:使用的程序標準、實作需求等。l外部需求系統與開發程序之外的影響因素所引起的需求,例如:互通需求、法律需求等
9、。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 16非功能需求的類型Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 17非功能需求範例l產品需求4.C.8它必須讓APSE和使用者之間的所有必要通訊都使用標準的Ada字元集l組織需求9.3.2系統開發的程序和交付文件必須符合 XYZCo-SP-STAN-95 所定義的程序和交付成果l外部需求7.6.5系統不能公開顧客的任何個人資訊,除了他們的姓名和系統操作人員的聯
10、絡電話之外Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 18目的與需求l非功能需求可能不容易精確的陳述,而不精確的需求則更難以進行驗證。l目的使用者的一般目的,例如容易使用l可驗證的非功能需求使用某些可以客觀測試的度量值來敘述l這些目的對開發者是有幫助的,因為它們可以傳送系統使用者的目的Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 19範例l系統目的系統目的系統應該讓有經驗的管理人員用起來容易,它也應該能夠減
11、少使用者的錯誤。l可驗證的非功能需求可驗證的非功能需求有經驗的管理人員必須能夠在兩個小時的訓練之後即可使用所有系統功能。訓練之後,有經驗的使用者在一天內可能發生的平均錯誤量不得超過兩次。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 20需求的度量值性質量測方式速度已處理交易秒、使用者事件回應時間、畫面重新整理時間大小K位元組、RAM晶片的數量容易使用訓練時間、輔助說明的數量可靠性平均故障次數、無法使用的機率、故障出現率、可用性強固性故障後重開機次數、造成故障的事件比例、故障時的資料毀損機率速度已處理交
12、易秒、使用者事件回應時間、畫面重新整理時間Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 21需求的互動l不同的非功能需求產生衝突的情形在複雜系統中是常見的現象l太空船系統為了減輕重量,系統使用的晶片數量必須減少為了減少電力的消耗,必須使用低電力的晶片然而,若使用低電力的晶片可能需要更多的晶片數量。這時候,哪一個需求是最重要的需求?Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 22領域需求l衍生自應用領域,描述
13、能夠反應領域的系統特性與功能l可能是新的功能需求、對現有需求的限制或是定義特定的運算條件l若不能滿足領域需求,系統可能就無法運作Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 23圖書館系統的領域需求l所有資料庫都必須有一個標準的使用者介面,而且必須符合Z39.50的標準。l由於版權的限制,有些文件拿到之後必須立即刪除。根據使用者的需求,這些文件可以在系統伺服器上列印,再以手動方式轉送給使用者,或是直接轉送到網路印表機列印。Ian Sommerville 2000 Software Engineerin
14、g,6th edition.Chapter 5 Slide 24火車保護系統l火車的減速速率必須依據下列公式計算:Dtrain=Dcontrol+Dgradient 其 中 的 Dgradient 為 9.81ms2 補 償 後 的gradient/alpha,9.81 ms2/alpha 的值是已知的不同類型火車。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 25領域需求的問題l理解性需求是以某應用領域特定的語言來表示開發系統的軟體工程師對這些語言通常都不太能夠瞭解l隱含性領域專家非常熟知他的領域,
15、所以通常不會以明確的方式來訂定領域需求Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 26使用者需求l應該以功能或非功能需求來描述,以便讓不熟悉詳細技術知識的系統使用者能夠理解l使用者需求是以自然語言、表格和圖表來定義Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 27自然語言的問題l不夠清楚 使用語言時有時候很難精確、清楚的描述l需求混淆 功能與非功能需求可能會產生混淆l需求混合 將好幾種不同需求一同表示Ian
16、 Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 28資料庫需求4.A.5 資料庫必須能夠支援組態物件的產生與控制;也就是資料庫中的物件可以自行和其他物件組成群組。組態控制的機制必須能夠以不完整的名稱存取不同版本群組中的物件。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 29Editor grid requirement2.6 格線功能格線功能 為了幫助圖表中實體的定位,使用者可以透過控制台中的選項開啟以公分或英吋計的
17、格線功能。開始的時候,格線功能為關閉的。在編輯階段,使用者可以任意開啟和關閉格線,也可以任意切換英吋或公分的格線單位。格線選項將提供於最適大小檢視中,但顯示的格線將會減少,以避免小型圖表會根據格線填入。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 30需求的問題l資料庫需求包含了概念和詳細的資訊它描述了組態控制功能的概念又包含一些詳細資訊,指出物件可以使用不完全的名稱來存取l格線需求混合了三個不同的需求概念性的功能需求(格線的需求)非功能需求(格線單位)非功能的 UI 需求(格線切換)Ian Somm
18、erville 2000 Software Engineering,6th edition.Chapter 5 Slide 31結構化的表示方式2.6 格線功能格線功能2.6.1編輯器必須提供格線功能,亦即在編輯器視窗背景 提供水平與垂直的格線。這個格線必須是一個被動 的格線,實體的排列與對齊油使用者來控制。基本理由:格線可以幫助使用者建立整齊的圖表,每個實 體之間有適當的空間。雖然主動式格線比較有用,亦即實體會自動卡位到格線,但是這種定位方 式不夠精確。使用者是決定實體應該如何放置的 最佳人選。規格:ECLIPSE/WS/Tools/DE/FS Section 5.6Ian Sommervi
19、lle 2000 Software Engineering,6th edition.Chapter 5 Slide 32詳細的使用者需求3.5.1 在設計中加入節點3.5.1.1 編輯器必須能夠讓使用者在設計中加入指定類型的節點。3.5.1.2 加入節點的動作順序應該如下:1.使用者選取欲加入的節點類型。2.使用者將游標移動到圖表中適當的節點位置,並且指出 欲加入到該點上的節點符號。3.使用者將節點符號拖拉到最後的位置。基本理由:使用者是決定實體應該如何放置的最佳人選。這個方法 可以讓使用者控制節點類型的選擇與定位。規格:ECLIPSE/WS/Tools/DE/FS。Section 3.5.1
20、Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 33撰寫需求的指引l創造一個標準的格式,並且確保所有需求定義都支持這個格式。l使用更一致性的言語,特別要將強制和渴望的需求區分清楚。強制的需求通常使用必須(shall)來定義,渴望的需求則使用應該(should)l利用其他字型(粗體和斜體字)強調需求的主要部分l儘量避免使用電腦術語Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 34系統需求l比使用者需求更詳細的規格
21、l設計系統的基礎l可以用來當成系統合約的一部分l系統需求可以利用第 7 章即將介紹的系統模型來表示Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 35需求與設計l原則上,需求應該陳述系統應該做什麼;而設計應該描述如何做到l事實上,需求和設計是不可分的利用系統架構可以建立需求的結構系統可以和其他系統互動以產生設計需求使用的特定設計可能是領域的需求Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 36NL 規格的問題l
22、意義不明確撰寫與閱讀需求的人必須使用同樣的方式來詮釋相同的文字,不過因為自然語言的特性具有模糊性,所以可能會造成許多誤解l太過彈性規格中,同一件事情可能會有許多不同講法l缺乏模組化NL 的結構並不適合建構系統需求的結構Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 37NL 規格的替代表示法標示法說明結構化自然語言這個方法是經由定義標準表格或範本來表示需求的規格。設計描述語言這個方法使用類似程式設計的語言,但是更具抽象特徵,經由定義系統的操作模式來指定需求。圖形標示法加上文字註記的圖形化語言,用來定義系
23、統的功能性需求。這種圖形化語言最早的例子是SADT(Ross,1977;Schoman與Ross,1977),最近的例子則是使用案例描述(Jacobsen 等人,1993)。我們將會在稍後的章節進行討論。數學式規格它是根據數學觀念所形成的標示法,例如有限狀態圖或集論。這些清楚的規格可以減少顧客和承包商對系統功能的爭執。不過,大部分的顧客都不懂這些正規化的規格,所以不願意使用它當作系統的合約。我們將在第9章說明正規化規格。Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 38結構化語言的規格l使用自然語言的
24、限制格式可以表示需求l它可以消除模糊與彈性所造成的問題,並且可以讓規格有某種程度的統一性l通常是以表單式的方式來支援Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 39表單式規格l定義功能或實體l描述輸入資料以及它們的來源l描述輸出資料以及它們的去處l指示其他所需的實體l前條件與後條件l副作用Ian Sommerville 2000 Software Engineering,6th edition.Chapter 5 Slide 40表單式的節點規格ECLIPSE/WS/Tools/DE/FS Sect
25、ion 5.6Function加入節點Description在現有設計中加入一個節點。使用者選取欲加入的節點類型和它的位置。將節點加入到設計中之後,該節點會變成目前的選取。使用者選擇節點位置時是將游標移往欲加入節點的區域。Inputs節點類型、節點位置、設計識別碼。Source使用者輸入節點類型和節點位置,設計識別碼則來自資料庫。Outputs設計識別碼。Destination設計資料庫。操作完成後,設計便會記錄到資料庫中。Requires以輸入的設計識別碼為根的設計圖形。Pre-condition設計被開啟並且顯示在使用者的螢幕上。Post-condition除了在指定位置加入一個指定類型的
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软体需求 软体 需求 PPT 课件
限制150内