【軟體工程】第三章 軟體需求與軟體規約
阿新 • • 發佈：2018-12-31
3.1 需求的作用
3.1.1 在現代系統中的作用
三個作用：
- 為產品提供控制功能。
- 為產品提供耦合功能，可整合其他功能。
- 為產品提供一些由本身所實現的功能，利用自身提供服務。
特別的：
- 為解決系統整合遇到的問題提供了靈活性。
- 為軟硬體介面中所出現的問題提供了低成本解決途徑。
- 軟體易修改，但修改成功很困難。
- 現代技術產品中最重要的技術是軟體技術，即軟甲是現代系統中的重要因素，是任何系統中最複雜的部分且最大的挑戰，它使得產品/系統成為使用者的解決方案。
3.1.2 在系統工程中的作用
三個作用：
- 需求分析環節：通過分析系統需求確定軟體需求及約束。
- 軟體體系結構設計環節：以軟體需求及約束為基礎，確定一個最佳的方案。
- 驗證、確認及測試環節：以需求為準則進行產品評估。
可見：
- 軟體在此時作為系統工程工作的一部分被實施。
- 在軟體開發活動中首先要做的是調查確定在一個系統需求規約中的分配給軟體的那些系統需求和在一個軟體需求規約（SRS）中的軟體需求
總結：
- 軟體需求是軟體開發的工作基礎。
3.2.1 定義
概念：一個需求是一個有關“要予構造”的陳述，描述了待開發產品/系統（或項）功能上的能力、效能引數或者其他性質。
3.2.2 基本性質
需求的五個基本性質：
- 必要的：是要求的嗎？
- 無歧義的：只能用一種方式解釋嗎？
- 可測的：可以對它進行測試嗎？
- 可跟蹤的：可以在不同階段進行跟蹤嗎？
- 可測量的：可以對它進行測量嗎？
3.3 需求的分類
分類：
- 功能需求是整個需求的主體，即沒有功能需求就沒有非功能需求。
- 設計約束將對軟體專案規劃、所需要的附加成本和工作產生直接影響。
3.4 需求發現
需求發現的方式：
- 自悟：需求人員把自己作為系統的終端使用者審視該系統並提出問題。
- 交談：為了確定系統應該提供的功能，需求人員向用戶提問。
- 觀察：通過觀察使用者瞭解系統執行環境。
- 小組會：舉行客戶和開發人員的聯席會議，與客戶組織的一些代表共同開發需求。
- 提煉：複審技術文件並提出相關的資訊。
- 綜合運用：所有方法互相結合，取長補短。
3.5 需求規約的概念和格式
3.5.1 需求規約（SRS）及其格式
概念：
- 需求規約是軟體項所有需求陳述的正式文件，是一個軟體產品的概念模型。
四個基本性質：
- 重要性和穩定性程度。
- 可實現單一需求的修改。
- 完整的沒有遺漏的。
- 一致的不存在互斥的。
格式舉例：
第一部分：
第二部分：
第三部分（特定需求，是文件的技術核心）：
- 模板一：根據系統執行模式，把第三部分劃分為一些小節，並在一個小節中給出系統性能的規約。
- 模板二：通過一種可選的模式劃分，把第三部分劃分為一些小節，其中每種模式的效能包含在該模式的規約中。
- 模板三：根據使用者類，把第三部分劃分為一些小節，其中每類使用者執行的功能包含在該類使用者的描述中。
- 模板四：按物件，把第三部分劃分為一些小節，在每一小節中給出該物件所關聯的功能。
3.6 需求規約的作用
概念：
- 是最重要的，作為軟體開發組織和使用者之間一份事實上的技術合同書。
- 是一個管理控制點。
- 是一個正式的、受控的起始點。
- 是建立產品驗收測試計劃和使用者指南的基礎。
建立產品驗收測試計劃：
| 測試型別 | 所處階段 |
|---|---|
| 有效性測試 | 需求分析階段 |
| 整合測試 | 總體設計階段 |
| 單元測試 | 詳細設計階段 |
- 目的：對未來系統中的哪些功能和效能指標進行測試，以達到何種要求。
- 作用：指導系統開發早期發現並修改一個錯誤，減少測試代價，並在以後階段的軟體開發中，對這個測試計劃不斷的修正和完善使之成為相應文件的一部分。
建立使用者指南：
- 目的：從使用者使用系統的角度簡要描述系統功能和效能，使用系統的主要步驟和方法，以及系統使用者的責任等。
- 作用：準備初步的使用者手冊可以使未來的系統使用者能夠從使用的角度檢查、稽核以判斷是否符合使用者需要，並迫使系統分析員從使用者角度考慮，發現需求的不一致和誤解的地方。
SRS不能實現的作用：
- 它不是設計文件，是一個“為了”設計的文件。
- 不是進度或規劃文件，所以不應包含專案成本、交付進度、報告規程、軟體開發方法、質量保證規程、配置管理規程、驗證和確認規程、驗收規程、安裝規程等。
3.7 專案的需求及需求規約
- 概念：專案需求是客戶和開發者之間有關技術合同-產品/系統需求的理解，應記錄在工作陳述SOW中或其他某一專案文件（如專案管理計劃）中。
區別：
- SRS只關注產品需求，即“交付給客戶的產品是什麼”。
- SOW應關注專案工作與管理，即“開發組要做的是什麼”。
（完）