1 / 24

軟體工程

軟體工程. 第 6 章 軟體需求 Software Requirements. 學習目標. 瞭解使用者需求和系統需求的概念，並且明白為何應該使用不同方式來表示這些需求 瞭解軟體的功能需求與非功能需求的差異 瞭解在軟體需求文件中如何組織這些需求. 需求工程 Requirement Engineering. 軟體需求包括 描述系統應提供的服務 系統運作的限制 顧客為何需要這個系統 需求 工程 發現、探索、誘導 使用者需求與系統限制 分析 使用者 需求與系統限制 紀錄 使用者 需求與系統限制 檢查 使用者 需求與系統 限制. 使用者需求和系統需求.

dieter-santana
Download Presentation

軟體工程

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 軟體工程 第6章 軟體需求 Software Requirements

  2. 學習目標 瞭解使用者需求和系統需求的概念，並且明白為何應該使用不同方式來表示這些需求 瞭解軟體的功能需求與非功能需求的差異 瞭解在軟體需求文件中如何組織這些需求

  3. 需求工程Requirement Engineering • 軟體需求包括 • 描述系統應提供的服務 • 系統運作的限制 • 顧客為何需要這個系統 • 需求工程 • 發現、探索、誘導 使用者需求與系統限制 • 分析 使用者需求與系統限制 • 紀錄 使用者需求與系統限制 • 檢查 使用者需求與系統限制

  4. 使用者需求和系統需求 • 使用者需求（User Requirement） • 高階的抽象需求 • 以自然語言加上圖表所形成的敘述 • 系統需求（System Requirement） • 詳細定義系統的功能、服務與限制 • 功能規格（Functional Specification）

  5. 需要不同種類規格的讀者類型

  6. 6.1 功能需求與非功能需求 • 軟體系統的需求通常可以分為功能需求、非功能需求或是領域需求。 • 功能需求（Functional Requirement） • 系統提供的服務、系統對特定輸入的反應，以及系統在特定情況下的行為 • 有時候也會在功能需求中明確描述系統不應該做什麼。 • 非功能需求（Non-Functional Requirement） • 系統提供的服務或功能的限制。包括時間上的限制、開發程序上的限制和標準等。 • 通常套用在整個系統，比較少只套用在個別系統功能或服務 • 領域需求（Domain Requirement） • 來自系統應用領域的需求，以及該領域所反映的特性和限制。 • 可以是功能需求或非功能需求。

  7. 功能需求 系統的功能需求主要是描述系統所能提供的功能或服務。 這些需求會依據軟體類型、該軟體的預期使用者，以及組織所採取的一般做法而定。

  8. 非功能需求 非功能需求就像它的名稱一樣，凡是沒有直接與系統提供功能有關的其他需求，就稱作非功能需求。 非功能需求很少與個別的系統功能有關，它們通常是與系統外顯性質有關，如系統執行效能、安全性、可用性等。 非功能需求並不一定都跟將要開發的軟體系統有關。 非功能需求是透過使用者的需求產生的，可能是由於預算限制、公司政策，或者與其他軟硬體系統相互操作的需求；也可能是其他外部因素，如安全規則或隱私權等。

  9. 非功能需求的類型

  10. 非功能需求分類 產品需求（product requirement）：這類需求是指定產品的行為。例如系統必須執行多快和它需要多少記憶體這類執行效能需求，設定可接受的故障率的可靠性需求、可移植性需求以及使用方便性需求。 組織需求（organisational requirement）：這類需求是衍生自客戶公司和軟體開發公司的組織政策和程序。例如必須使用的程序標準、規定使用的程式語言或設計方法的實作需求，以及指定何時交付產品與說明文件的交付需求。 外部需求（external requirement）：這是系統與其開發程序之外的其他因素所產生的所有需求。包括定義如何與其他組織的系統互動的相互操作需求、確保系統合法運作的法律需求，以及其他的道德需求等。此處的道德需求是為了確保此系統可為使用者和一般大眾所接受。

  11. 代表非功能需求的測量值

  12. 領域需求 領域需求是來自系統應用領域的需求，不是系統使用者的特定需求。它們通常會包含有專業領域的術語，或者參考到專業領域的觀念。 它們自己本身可能是新的功能需求、限制現有的功能需求，或是設定某個運算要如何執行。 領域需求通常會反映出應用程式領域的基本觀念。

  13. 6.2 使用者需求 • 系統的使用者需求應該描述功能需求與非功能需求兩者，以便能夠讓沒有專業技術背景的系統使用者也能瞭解這些需求。 • 這些需求應該只需要指定系統的外部行為，儘量避免敘述系統設計特性。因此，不要使用軟體術語、結構化符號表示法或正規化符號表示法來描述需求。 • 不過，若使用自然語言來撰寫需求，可能會產生下列這些問題： • 不夠清楚：使用語言時有時候很難精確、清晰的描述，而且文件常常會變得很冗長，難以閱讀。 • 需求混淆：功能需求、非功能需求、系統目標和設計資訊可能不容易分清楚。 • 需求合併：好幾種不同的需求可能只表達在一個需求中。

  14. 需求撰寫的原則 創造一個標準的格式，並確定所有的需求定義都遵照這個格式。標準化比較不容易發生疏忽或遺漏的情形，並且讓需求更容易檢查。我使用的格式是以粗體來顯示一開始的需求敘述，並提供原因說明以及詳細系統需求規格的參考資源。也許還可以考慮記錄是誰提出這個需求（來源），這樣萬一需求必須變更時，才知道要找誰商量。 語言的使用要一致。例如把強制和期望的需求區分清楚。強制的需求通常使用「必須」（shall）來定義，期望的需求則使用「應該」（should）。 利用字型功能（粗體、斜體或彩色）強調需求的重要部分。 儘量避免使用電腦術語。但是無可避免的，有時候使用者需求還是多少會有些技術詞彙。

  15. 6.3 系統需求 系統需求是把使用者需求描述得更詳細。軟體工程師可將它當成系統設計的起點，在裡面加上細節，並說明系統應該如何提供相對應的功能。 它也可以當作承包系統實作合約的一部分，因此應該是完整的，而且與整個系統的規格一致。 在撰寫使用者需求時，選擇一種能讓非技術人員瞭解的語言是必要的。不過，你可以使用比較專業的符號表示法（圖6.11）來撰寫系統需求。

  16. 需求規格的表示法

  17. 使用結構化語言撰寫規格 結構化自然語言是一種撰寫系統需求的方式，是一種形式有限的自然語言，而且所有的需求都是以標準方式來撰寫。 它的優點是保有自然語言的大部分表達能力和易理解性，而又可確保規格有某種程度的一致。

  18. 使用標準的表單描述功能需求 欲指定的功能或實體的描述。 系統的輸入和輸入來源的描述。 系統的輸出和輸出去向的描述。 說明會使用到的其他實體（必要條件部分）。 描述所採取的行動。 假如是採用功能性方法，則在前置條件處設定呼叫此功能之前必須為真的條件，並且在後續條件處指定呼叫此功能之後必須為真的條件。 描述可能的副作用（如果有的話）

  19. 在需要顯示狀態是如何改變的，或者需要描述一連串的活動時，圖形模型是最適合的表達方式。

  20. 6.4 介面規格 • 有3種類型的介面可能必須描述定義： • 程序介面：呼叫現有程式或子系統的程序，即可使用它的各項服務。這類介面有時被稱作「應用程式介面」（API）。 • 資料結構：在子系統之間互相傳遞的資料結構。這類敘述使用圖形資料模型（第8章）來表達最適合。必要時還可以從這些描述中自動產生Java或C++語言的程式描述。 • 資料表示法：現有系統的資料表示法，例如位元的順序。這類介面在嵌入式、即時系統中最常見。有些語言能支援這麼細節的規格，但是Java不行。不過也許這應該使用圖形搭配文字標記來表達最適合。

  21. 6.5 軟體需求文件 軟體需求文件有時候也稱為軟體需求規格書（software Requirements Specification, SRS）。 它是一份用來說明系統開發者應該實作什麼功能的正式文件，其內容應該包括系統的使用者需求，以及系統需求的詳細規格。 需求文件可能的使用者範圍廣泛，表示該文件不但要能夠讓客戶看懂需求，需求定義的詳細程度對於開發人員和測試人員而言也要夠詳細，並且還要涵蓋系統可能的演進預測

  22. 需求文件的使用者類型

  23. 需求文件的結構

More Related