软体需求.ppt

《软体需求.ppt》由会员分享，可在线阅读，更多相关《软体需求.ppt（70页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、軟體需求 n系統的描述與規格說明 需求工程 n依據客戶對系統的需求以及系統運作與開發時的限制來建立服務的程序n需求本身是需求工程程序期間所產生的系統服務與限制的描述何謂需求？n從某個服務或系統限制的高階抽象敘述到詳細的數學式功能規格n需求通常有兩種功能n它可以當成合約招標的基礎，因此必須容易解釋n它可以當成合約本身的基礎，因此必須詳細定義n這兩項敘述均可稱為需求需求類型n使用者需求n以自然語言和圖表所形成的敘述，用來描述系統能夠提供的服務以及運作時的一些限制條件。這些需求是專為客戶所撰寫的n系統需求n以結構化的文件更詳細的定義系統的服務與限制條件。以客戶和承包商之間的合約方式撰寫n軟體設計規格

2、n詳細的軟體描述，用來當成設計和實作的基礎。專為開發者所撰寫定義與規格需求的讀者功能與非功能需求n功能需求(Functional requirements)n描述系統應該提供的服務、系統對特殊輸入的回應方式以及系統在特殊情況下的行為等敘述。n非功能需求(Non-functional requirements)n服務的限制條件或是系統提供的功能，包括時間上的限制、開發程序上的限制和標準等。n領域需求(Domain requirements)n來自系統應用領域的需求以及該領域所反映的特性，這種需求可以是功能性或非功能性的需求。功能需求n描述系統功能或服務n依據軟體的類型、預期的使用者以及應用此軟體

3、的系統類型而定n功能性的使用者需求可以是說明系統應該做什麼的高階敘述；功能性的系統需求則應該詳細描述系統的服務功能需求的範例n使用者必須能夠搜尋整個資料庫或是選擇某個子集做搜尋。n系統必須提供適當的檢視器，讓使用者可以閱讀文件資料庫中的文件。n每一筆預定的書單必須配置一個唯一的識別碼（ORDER_ID），而且必須能夠讓使用者將這個碼複製到其帳戶的永久儲存區。需求不精確n當需求沒有精確的描述就會發生的問題n模凌兩可的需求會被開發者和使用者解釋成各種可能n以前面範例中的適當檢視器 為例n使用者的目的 為每個不同文件類型所使用的特殊用途檢視器n開發者的解釋 提供能夠顯示文件內容的文字檢視器需求的完整

4、性與一致性n原則上，需求應該是完整且一致的n完整n它們應該包含所有需求功能的描述n一致n系統功能描述中不應該有衝突或矛盾的地方n實際上，不太可能產生完整且一致的需求文件非功能需求n定義系統特性與限制，例如：可靠度、回應時間以及儲存需求。限制則如 I/O 裝置的容量、系統表示方式等。n非功能需求也可以指定程序需求，限制使用特定的 CASE 系統、程式語言或是開發方法等n非功能需求可能比功能需求還重要，如果沒有符合這些需求，系統就沒有用非功能需求的分類n產品需求n指定交付的產品必須以某種特定方式運作的需求，例如：執行速度、可靠度等。n組織需求n因應組織政策與程序的需求，例如：使用的程序標準、實作需

5、求等。n外部需求n系統與開發程序之外的影響因素所引起的需求，例如：互通需求、法律需求等。目的與需求n非功能需求可能不容易精確的陳述，而不精確的需求則更難以進行驗證。n目的n使用者的一般目的，例如容易使用n可驗證的非功能需求n使用某些可以客觀測試的度量值來敘述n這些目的對開發者是有幫助的，因為它們可以傳送系統使用者的目的需求的度量值性質量測方式速度已處理交易秒、使用者事件回應時間、畫面重新整理時間大小K位元組、RAM晶片的數量容易使用訓練時間、輔助說明的數量可靠性平均故障次數、無法使用的機率、故障出現率、可用性強固性故障後重開機次數、造成故障的事件比例、故障時的資料毀損機率速度已處理交易秒、使用

6、者事件回應時間、畫面重新整理時間需求的互動n不同的非功能需求產生衝突的情形在複雜系統中是常見的現象n太空船系統n為了減輕重量，系統使用的晶片數量必須減少n為了減少電力的消耗，必須使用低電力的晶片n然而，若使用低電力的晶片可能需要更多的晶片數量。這時候，哪一個需求是最重要的需求？領域需求n衍生自應用領域，描述能夠反應領域的系統特性與功能n可能是新的功能需求、對現有需求的限制或是定義特定的運算條件n若不能滿足領域需求，系統可能就無法運作領域需求的問題n理解性n需求是以某應用領域特定的語言來表示n開發系統的軟體工程師對這些語言通常都不太能夠瞭解n隱含性n領域專家非常熟知他的領域，所以通常不會以明確的

7、方式來訂定領域需求使用者需求n應該以功能或非功能需求來描述，以便讓不熟悉詳細技術知識的系統使用者能夠理解n使用者需求是以自然語言、表格和圖表來定義自然語言的問題n不夠清楚 n使用語言時有時候很難精確、清楚的描述n需求混淆 n功能與非功能需求可能會產生混淆n需求混合 n將好幾種不同需求一同表示需求的問題n資料庫需求包含了概念和詳細的資訊n它描述了組態控制功能的概念n又包含一些詳細資訊，指出物件可以使用不完全的名稱來存取n格線需求混合了三個不同的需求n概念性的功能需求(格線的需求)n非功能需求(格線單位)n非功能的 UI 需求(格線切換)撰寫需求的指引n創造一個標準的格式，並且確保所有需求定義都支

8、持這個格式。n使用更一致性的言語，特別要將強制和渴望的需求區分清楚。強制的需求通常使用必須(shall)來定義，渴望的需求則使用應該(should)n利用其他字型（粗體和斜體字）強調需求的主要部分n儘量避免使用電腦術語系統需求n比使用者需求更詳細的規格n設計系統的基礎n可以用來當成系統合約的一部分n系統需求可以利用第 7 章即將介紹的系統模型來表示需求與設計n原則上，需求應該陳述系統應該做什麼；而設計應該描述如何做到n事實上，需求和設計是不可分的n利用系統架構可以建立需求的結構n系統可以和其他系統互動以產生設計需求n使用的特定設計可能是領域的需求NL 規格的問題n意義不明確n撰寫與閱讀需求的人

9、必須使用同樣的方式來詮釋相同的文字，不過因為自然語言的特性具有模糊性，所以可能會造成許多誤解n太過彈性n規格中，同一件事情可能會有許多不同講法n缺乏模組化nNL 的結構並不適合建構系統需求的結構NL 規格的替代表示法標示法說明結構化自然語言 這個方法是經由定義標準表格或範本來表示需求的規格。設計描述語言這個方法使用類似程式設計的語言，但是更具抽象特徵，經由定義系統的操作模式來指定需求。圖形標示法加上文字註記的圖形化語言，用來定義系統的功能性需求。這種圖形化語言最早的例子是SADT（Ross,1977；Schoman與Ross,1977），最近的例子則是使用案例描述（Jacobsen 等人,19

10、93）。我們將會在稍後的章節進行討論。數學式規格它是根據數學觀念所形成的標示法，例如有限狀態圖或集論。這些清楚的規格可以減少顧客和承包商對系統功能的爭執。不過，大部分的顧客都不懂這些正規化的規格，所以不願意使用它當作系統的合約。我們將在第9章說明正規化規格。結構化語言的規格n使用自然語言的限制格式可以表示需求n它可以消除模糊與彈性所造成的問題，並且可以讓規格有某種程度的統一性n通常是以表單式的方式來支援表單式規格n定義功能或實體n描述輸入資料以及它們的來源n描述輸出資料以及它們的去處n指示其他所需的實體n前條件與後條件n副作用需求文件n需求文件是一份用來說明系統開發者需求的正式文件n它必須包含

11、需求的定義和規格n但是它不是一份設計文件，它必須設定系統應該做什麼(What)；而不是如何做(How)需求文件的使用者需求文件的需求n指定外部的系統行為n指定實作的限制n容易做變更n當成維護時的參考工具n記錄系統生命週期的未來考慮，亦即預期的變更n列出非預期事件的回應特徵IEEE 的需求標準n簡介n一般說明n特定需求n附錄n索引n這只是通用的結構，必須針對特定的系統做修正需求文件結構n簡介n詞彙n使用者需求定義n系統架構n系統需求規格n系統模型n系統演化n附錄n索引需求工程程序 n發現、分析以及確認系統需求的程序nRE 使用的程序會根據應用領域、參與人員以及發展需求的組織有很大的差異n然而，下

12、列幾項通用活動則是所有程序共通的n需求擷取n需求分析n需求確認n需求管理需求工程程序可行性研究n可行性研究可決定提出的系統是否有價值n它是一項短暫活動，著重於檢查下列幾個重點n此系統對組織的整體目標是否有貢獻？n此系統是否可以利用目前的技術、在有限的成本以及時程限制下製作完成？n此系統是否可以和其他現有系統做整合？可行性研究實作n依據對資訊的評估(需要什麼)、資訊的收集以及報表的撰寫n詢問組織中的人員下列問題n若系統無法實現，組織會如何處理？n目前的程序有哪問題？n提議的系統有何幫助？n有哪些整合上的問題？n是否需要新的技術？需要哪些技能？n提議的系統必須支援哪些功能？擷取與分析n有時候稱為需

13、求擷取或發現需求n它包括讓技術人員與客戶一起合作找出相關的應用領域、應該提供的服務以及系統的操作限制等n還可能牽涉到終端使用者、經理人員、負責維護的工程師、領域專家或是工會等。這些都稱為專案關係人(stakeholders)需求分析的問題n專案關係人不知道他們真正要什麼n專案關係人會以自己的辭彙來表示需求n不同專案關係人可能會產生互相衝突的需求n組織和政治的因素可能也會影響系統的需求n分析過程中若需求遭變更可能會出現新的專案關係人，而造成商業環境的變更需求分析程序程序活動n瞭解領域(Domain understanding)n收集需求(Requirements collection)n分類(C

14、lassification)n解決衝突(Conflict resolution)n排列優先順序(Prioritisation)n檢查需求(Requirements checking)系統模型n在需求分析活動中可能會產生不同模型n需求分析可能牽涉到造成這些不同模型的三種結構化活動n分割(Partitioning)。識別實體之間的結構化關係(部分關係)n抽象化(Abstraction)。識別出各實體的一般化n投射(Projection)。識別出觀察問題的不同方法n系統模型將在第 7 章做介紹觀點式擷取法n專案關係人代表觀察問題或問題觀點的不同方法n這種多重觀點的分析非常重要，因為分析系統需求時沒有

15、唯一正確的方法觀點的類型n資料來源或消化處(Data sources or sinks)n負責產生或使用資料的觀點，分析過程包括辨識產出或消耗的資料以及視資料來源與消化處為合法的假設n表示架構(Representation frameworks)n此觀點可被視為是一種特殊的系統模型。使用單一表示方式可能會漏掉某些需求。這種觀點尤其適用於即時系統n服務接收者(Receivers of services)n系統外部以及從系統接收到服務的觀點，大部分適用於互動式系統外部觀點n很自然的可以將終端使用者視為系統服務的接收者n這些觀點可以很自然的構築需求的擷取n很容易決定觀點是否合理n這些觀點和服務可以用

16、來構築非功能需求以方法為主的分析n需求分析中廣泛運用的方法，依據某個結構化方法的應用來瞭解系統n這些方法有不同的強調處，有些是特別為需求擷取而設計，有些則與設計方法比較接近n這裡使用觀點式方法(viewpoint-oriented method,VORD)為例，它也可以用來說明觀點的使用方式VORD 方法VORD 程序模型n識別觀點n找出接收系統服務的觀點，以及辨識出提供給各個觀點的特定服務n建構觀點 n將相關的觀點組成階層架構，共通的服務放在階層架構的上層，下層觀點則繼承自上層觀點n觀點文件n修飾已辨識出的觀點和服務的描述 n對應觀點與系統n將分析轉換為物件導向式的設計VORD 標準格式觀點

17、範本服務範本文件：觀點名稱文件：服務名稱屬性：觀點資訊的屬性原理：觀點資訊的屬性事件：事件情境是描述系統針對觀點事件如何回應規格：關於服務規格服務：服務描述文件觀點：可收到的服務上的觀點名稱子VPs：子觀點名稱非功能需求：非功能需求上的限制性服務供應者：系統物件上可提供的服務情境法(Scenarios)n情境用來描述系統實際的使用方式n這個方法有助於需求擷取，因為用這個方法比抽象敘述更容易得到系統的需求n情境法對概略的需求描述加入詳細資訊尤其有幫助情境描述n情境開頭的系統狀態描述 n情境中正常的事件流程描述n可能發生的問題以及解決方法的描述n同一時間可能發生的其他活動n情境完成後的系統狀態描述

18、事件情境法 n事件情境法可以用來描述系統如何回應某些特殊事件，例如開始交易事件nVORD 使用下列幾個慣用的圖形來表示事件情境n欲提供與交付的資料n控制資訊n例快處理n下一個預期的事件資料與控制分析的表示符號n由觀點提供的資料以及要交給觀點的資料以橢圓表示n進入或離開方塊的控制資訊表示在每個方塊的上方n離開此方塊的資料表示在每個方塊的右邊 n例外狀況則出現在方塊的下方n預期發生的下一個事件名稱則以灰底顏色顯示在方塊中例外狀況描述n大部分的方法都不包含描述例外狀況的工具n此例中，例外狀況有n逾時：客戶可能在限定的時間內輸入錯誤的PIN，卡片會被退回。n無效卡：無法辨識卡片，卡片也會被退回。n遺失

19、卡：卡片被辨識出為遺失卡，機器會自動收回此卡片。使用個案 n使用個案是 UML 中以情境為主的技術，它可以識別互動中的行為者，以及描述互動本身n利用一組使用個案來描述系統中所有可能的互動n利用順序圖在使用個案中加入詳細資訊，顯示系統處理事件的順序需求確認n用來確定需求是否定義了顧客真正想要的系統 n需求錯誤造成的成本非常高，所以確認的動作很重要n在系統交付之後修正需求錯誤的成本可能會比修護實作的錯誤高出100倍之多需求檢查n確實性：系統提供的功能是否能夠支援客戶的需求？n一致性：是否有任何需求產生衝突？n完整性：是否包含客戶所需的所有功能？n實現性：需求是否可以在有限的預算和可用技術下實作完成

20、？n可驗證性：需求是否可以接受檢查？需求確認技術n需求審查 n有系統的人為分析需求n雛形法 n使用可執行的系統模型來檢查需求，參見第 8 章n測試案例產生法n為需求發展測試案例以檢查其測試性n自動化一致性分析 n檢查結構化需求描述的一致性需求審查n在擬定需求定義時必須定期的進行審查n客戶和承包商的人員都應該參與審查n審查可以是正式的(有完整的文件)或非正式的。開發者、客戶和使用者之間若有良好的溝通便可以提早解決問題審查檢查n可驗證性(Verifiability)：需求是否如敘述情形一樣能夠真的進行測試？n可瞭解性(Comprehensibility)：系統的採購人員或直接使用者是否能夠適當的瞭

21、解這些需求？n可追蹤性(Traceability)：是否清楚的記錄需求來源？n可調適性(Adaptability)：需求是否可調整改變，而不會造成其他系統需求太大的影響？自動化需求一致性檢查 需求管理n需求管理是在需求工程程序及系統開發期間管理需求變更的程序n需求通常是不完整且不一致的n在程序期間，當商業需求改變或是對正在開發的系統有更好的瞭解，就會出現新的需求n不同觀點會不同的需求，而這些需求通常會產生矛盾需求變更n不同觀點產生的需求，其優先順序在開發過程中會有所改變n系統的客戶可能會以商業的觀點來指定需求，而這些觀點可能會與終端使用者的需求產生衝突n系統的商業和技術環境在開發的過程中也會有

22、所改變需求演化 持久和短暫的需求 n持久需求(Enduring requirements)：指非常穩定的需求，來自組織的核心活動。例如，醫院通常會有醫生和護士。這些需求可能是從領域模型而來n短暫需求(Volatile requirements)：系統開發期間或系統開始運作之後可能發生改變的需求。若以醫院為例，政府的健保政策可能就會有隨時改變的需求需求分類n易變的需求(Mutable requirements)n因組織的營運環境改變而造成的需求改變n新出現的需求(Emergent requirements)n顧客在系統開發期間瞭解系統的發展之後所出現的新需求n隨之發生的需求(Consequent

23、ial requirements)n引進電腦系統之後所造成的需求n相容需求(Compatibility requirements)n根據某個特殊系統或組織中商業流程而來的需求需求管理規劃 n在需求工程程序期間，你必須規劃：n需求識別 如何識別每一項個別的需求n變更管理程序分析需求變更時的程序n追蹤策略有關需求之間的關係、且需要進行維護的大量資訊n支援的 CASE 工具幫助管理需求變更時所需的支援工具可追蹤資訊(Traceability)n可追蹤資訊是指需求、需求來源以及系統設計之間的關係n來源可追蹤資訊 n將需求與提出這些需求的專案關係人做一個連結n需求可追蹤資訊n將相依的需求做連結n設計可追蹤資訊 n將需求和設計做連結需求變更管理n應該將所有提出的變更套用至需求中n主要階段n問題分析：討論需求的問題並且提出變更n變更分析與成本預估：評估變更對其他需求的影響n變更實作：修改需求文件和其他文件，以反映變更需求變更管理