軟體工程第二章

第二章 軟體需求與軟體需求規約

**大家想一起學習交流的可以加群，QQ：755422568。**
           

一、軟體需求

（1）、軟體需求

定義：是有關一個“要予構造”的陳述，描述了待開發産品/系統功能上的能力、性能參數或其他性質。

性質：

1）、必要的，該需求是使用者所要求的，驗證采用需求複審。

2）、無歧義的，該需求隻能用一種方式解釋。

3）、可測的

4）、可跟蹤的，該需求可從一個開發階段跟蹤到另一個階段。

5）、可測量的

（2）、需求分類

1）、功能需求

規約了系統或系統構件必須執行的功能。

2）、非功能需求

1、性能需求

規約了系統或系統構件在性能方面必須具有的一些特性。

2、外部接口需求

規約了系統或系統構件必須與之互動的使用者、硬體、軟體或資料庫元素，其中也有可能規約互動格式、時間或其他因素。

接口需求有七個：

（1）、使用者接口

（2）、硬體接口

（3）、軟體接口，描述與其他軟體産品進行的互動。

（4）、通信接口，描述待開發系統與通信設施之間的互動。

（5）、記憶體限制

（6）、運作

（7）、地點需求，描述系統安裝以及如何調整一個地點，以适應新的實體環境。

3、設計限制

限制了軟體系統或軟體系統構件的設計方案的範圍。

考慮幾個方面：

（1）、法規政策

（2）、硬體限制

（3）、與其他應用的接口

（4）、并發操作

（5）、審計功能

（6）、控制功能

（7）、進階語言需求

（8）、握手協定

（9）、應用的關鍵程度

（10）、安全和保密

4、品質屬性

規約了軟體産品所具有的一個性質必須達到其他品質方面一個所期望的水準。

可靠性、存活性、可維護性、使用者友好性

（3）、需求發現

1）、初始發現需求的常用技術包括5種。

（1）、自悟

适用情況：需求人員不能直接與使用者進行交流。

存在風險：無法驗證發現的需求是否滿足使用者的要求，是否正确。

（2）、交談，提出問題/使用者回答這一方式

适用情況：客戶支援需求人員與最終使用者進行有關系統需求的交流。

存在風險：需求可能不斷增長，以至于很難控制，導緻超出項目成本和進度的限制。

（3）、觀察

适用情況：使用者允許需求人員進入工作現場，并進行觀察，可與有關人員就問題進行交流。

存在風險：客戶可能抵觸，影響他們的正常業務；可能在開發者簽約之前就已熟悉業務。

（4）、小組會，與客戶組織的一些代表共同開發需求

适用情況：各方組織在管理層上重視需求工作，并有能力提供人力資源。

存在風險：如會議組織不到位或者某些客觀環境的限制，會産生一些互相沖突的需求。

（5）、提煉，複審技術文檔，并提取相關的資訊。

适用情況：提煉方法是針對已經有了部分需求文檔的情況。

存在風險：無法驗證發現的需求是否滿足使用者的要求，是否正确。

二、需求規約

（1）、需求規約

定義：是一個軟體項/産品/系統所有需求陳述的正式文檔，表達了一個軟體産品/系統的概念模型。

性質：

1）、重要性和穩定性程度，按需求的重要性和穩定性，對需求進行分級。

2）、可修改的

3）、完整的，沒有被遺漏的需求。

4）、一緻的，不存在互斥的需求。

需求規約是軟體開發組織和使用者之間一份事實上的技術合同書，回答：“傳遞給客戶的産品/系統是什麼”

（2）、需求規約（規格說明書）（

選擇題、填空題

）

表達三種不同風格

（1）、非形式化的需求規約，以一種自然語言來表達需求規約，如文章。

（2）、半形式化的需求規約，以半形式化符号體系來表達需求規約，如術語表、标準化的表達格式

（3）、形式化的需求規約，以一種基于良構數學概念的符号體系來編制需求規約，一般往往伴有解釋性注釋的支援

（3）、需求規約的作用

（1）、需求規約是軟體開發組織和使用者之間一份事實上的技術合同書，是産品功能及其環境的展現。

（2）、對于項目的其餘大多數工作，需求規約是一個管理控制點。

（3）、對于産品/系統的設計，需求規約是一個正式的、受控的起始點。

（4）、需求規約是建立産品驗收測試計劃和使用者指南的基礎，即基于需求規約一般還會嘗試另外兩個文檔——初始測試計劃和使用者系統操作描述。

注：需求規約不能實作以下兩個作用。

1、不是設計文檔，是一個“用于”設計的文檔。

2、不是進度或者規劃文檔，不包含在工作陳述、軟體項目管理計劃、軟體生存周期管理計劃、軟體配置管理計劃或軟體品質保證計劃。