[需求管理-9]：需求規格說明書SRS

目錄

​​第1章 需求規格說明書概述​​

​​1.1 什麼軟體項目需求規格說明書​​

​​1.2  需要規格說明書在項目中階段​​

​​1.3 需要規格說明書的作用​​

​​1.4 主要特點​​

​​1.5 衡量标準​​

​​1.7 評審注意事項​​

​​第2章 需要規格說明書的格式與主要内容​​

​​1 引言​​

​​1.1 目的​​

​​1.2 背景​​

​​1.3 定義​​

​​1.4 參考資料​​

​​2 需求概述​​

​​2.1 總體目标​​

​​2.2 運作環境​​

​​2.3 限制條件（CONSTRAINTS）與假定條件（ASSUMPATION）​​

​​3. 資料描述​​

​​3.1 靜态資料​​

​​3.2 動态資料​​

​​3.3 資料庫介紹​​

​​3.4 資料詞典​​

​​3.5 資料采集​​

​​4. 功能需求概述​​

​​4.1 功能劃分​​

​​4.2 功能概述​​

​​5. 非功能性需求概述​​

​​6. 對外接口概述​​

​​6.1 使用者界面​​

​​6.2 硬體接口​​

​​6.3 軟體接口​​

​​6.4 故障處理​​

​​7. 其他需求​​

​​執行個體參考：​​

第1章 需求規格說明書概述

1.1 什麼軟體項目需求規格說明書

軟體項目需求說明書是指在研究使用者要求的基礎上，完成可行性分析和投資效益分析以後，由​​軟體系統工程師​​或分析員編寫的需求說明書。

它詳細定義了資訊流和界面，功能需求，設計要求和限制，測試準則和品質保證要求。

當然，軟體項目需求規格說明書是站在使用者的角度看到的系統功能。而不是從軟體系統内部的角度看到的外部接口的需求。前者是由外向内看，後者是由内向外看。

這是寫需求規格說明書，必須有的立足點。

需求規格說明書關注的是從外看到系統的功能需求，而不是内部的具體設計，更不是具體的實作。

軟體需求規格說明書是需求分析階段最後的成果，它是作為需求分析的一部分而制定的可傳遞文檔。軟體需求說明書，又稱為軟體規格說明書，是分析員在需求分析階段需要完成的文檔，是軟體需求分析的最終結果。

1.2  需要規格說明書在項目中階段

需要規格說明書發生在概念階段或需求階段 ，這一階段分為兩個過程：

（1）概念的形成過程

根據使用者機關業務發展和經營管理的需要，提出建設資訊系統的初步構想

（2）需求分析過程

即對企業資訊系統的需求進行深入調研和分析，形成《需求規範說明書》 ，經評審、準許後立項。

也就是說，需要規格說明書是在項目啟動之前的階段，沒有需求規格說明說，項目是無法啟動的。

1.3 需要規格說明書的作用

《需要規格說明書》代表的是客戶對項目的需求。它限定了項目的目标和任務，也是客戶驗收的标準。

它的作用是作為使用者和軟體開發人員達成的技術協定書，作為着手進行設計工作和編碼的基礎和依據，系統開發完成以後，為産品的驗收提供了依據。

需要規格說明書作用為：

（1）軟體人員與使用者之間事實上的技術合同說明；

（2）為項目管理的範圍管理、成本管理提供了依據

（3）作為軟體人員下一步進行設計和編碼的基礎；

（4）作為測試和驗收的依據。

（5）為軟體的維護提供的重要資訊

1.4 主要特點

軟體需求規格說明書應該完整、一緻、精确、無二義性，同時又要簡明、易懂、易修改。

由于軟體需求說明書最終要得到開發者和使用者雙方的認可，是以使用者要能看得懂，并且還能發現和指出其中的錯誤，這對于保證軟體系統的品質有很大的作用。這就要求需求說明書盡可能少用或不用計算機領域的概念和術語，盡量使用行業使用者的專業術語來闡述（而不是計算機領域的術語）

1.5 衡量标準

（1）完整性

每一項需求都必須将所要實作的功能描述清楚，以使開發人員獲得設計和實作這些功能所需的所有必要資訊。

不遺漏任何必要的需求資訊，即目标軟體的所有功能、性能、設計限制，以及所有的可能情況下的預期行為，均完整地展現在需求說明書中。

（2）正确性

每一項需求都必須準确地陳述其要開發的功能。

需求說明書中的功能、性能等描述與使用者對軟體的期望相一緻。

（3）可行性

每一項需求都必須是在已知系統和環境的權能和限制範圍内可以實施的。

（4）無二義性

對所有需求說明的讀者都隻能有一個明确統一的解釋，由于自然語言極易導緻二義性，是以盡量把每項需求用簡潔明了的使用者性的語言表達出來。另外，需求說明書的各部分之間不能互相沖突。

（5）可驗證性

需求說明書中的任意一項需求，都存在技術和經濟上可行的手段進行驗證和确認。

（6）可修改性（可伸縮性）

需求說明書的格式群組織方式應該保證能夠比較容易地增、删和修改，并使修改後的需求說明書能夠軟較好地保持其他各項屬性。

（7）可跟蹤性

應能在每項軟體需求與它的根源和設計元素、源代碼、測試用例之間建立起連結鍊，使每項需求與使用者的原始需求連起來，并為後續開發和其他文檔引用這些需求項提供便利。這種可跟蹤性要求每項需求以一種結構化的，粒度好的方式編寫并單獨标明，而不是大段大段的叙述。

也就是說，每項需要都是以一個個獨立項而存在和維護的。

1.6 需求規格說明的評審review

（1）參與人員

• 客戶或客戶的代表（産品經理）
• 系統架構師
• 系統工程師（來自目标系統受影響的技術子產品領域）
• 軟體架構師以及核心開發人員（來自目标系統受影響的技術子產品領域）
• 測試架構師以及核心測試人員（來自目标系統受影響的技術子產品領域）
• 使用者手冊撰寫人員

（2）評審流程

• 啟動kick off
• 草拟、讨論、周會 （會議）
• 最終文檔的評審 （線上+會議）
• 最終文檔的授權

1.7 評審注意事項

（1）是否有内容與文法上的錯誤？

這是最基本的要求，不能有内容與文法上的錯誤。

（2）前後不一緻性、沖突性？

一份需求規格說明說，是經過大量的需求人員經過較長時間的讨論、輸入形成的，是以需要關注前後前後一緻性，檢查是否有前後沖突的地方。

（3）是否清晰、無異議的表達了需求？

可以基于SMART原則來檢查需求。

（4）每個需要都是在項目範圍内？

防止需要中的内容超出了需求規格說明書本身的範圍。有些需求，它不屬于需求規格說明書的範圍，但确實項目的範圍，比如對于人員的學曆要求等。這些資訊不應該放到需求規格說明書中。

（5）異常處理？

是否考慮了異常出錯處理？沒一種異常都需要明确的定義。

（6）在組織内現有的資源内，是否可以實作？

需求規格說明書是直到開發實作需要的。如果有需要，在現有的資源（人力資源和物質資源）的情況下，無法實作，這樣的需求就不适合放到需求規格說明書中，需要通過分解、變通等方法來化解不可實作的需求。

1.8 需求規格說明的的格式

需要規格說明書必須用統一格式的文檔進行描述，為了使需求分析描述具有統一的風格，可以采用已有的且能滿足項目需要的模闆，也可以根據項目特點和軟體開發小組的特點對标準進行适當的改動，形成自己的模闆。

第2章 需要規格說明書的格式與主要内容

1 引言

1.1 目的

本文檔是進一步分析使用者需求的結果，詳盡說明了這一軟體的需求和規格，這些規格說明時進行系統設計的基礎，也是編寫測試用例和進行系統測試的主要依據。同時，該文檔也是使用者确定軟體功能需求的主要依據。

本文檔撰寫的目的是明确軟體需求、安排項目計劃、推廣軟體設計群組織軟體開發和測試。本文檔主題内容為項目的需求彙總分類以及以此為基礎而建立的需求模型。

本說明書的預期讀者是軟體概要設計人員和詳細設計人員，是軟體設計的基礎。

1.2 背景

背景：是指襯托其他事物的要素或背後力量。

闡述項目或特定需求産生的背景，便于各方的幹系人了解事情的背景。

1.3 定義

項目的名稱與辨別

1.4 參考資料

其他參考資料

2 需求概述

2.1 總體目标

闡述需要解決客戶哪方面的問題或痛點？ 闡述客戶的期望和目标。

2.2 運作環境

軟體系統的運作環境（作業系統、計算機硬體等）

2.3 限制條件（CONSTRAINTS）與假定條件（ASSUMPATION）

限制：不是具體的動作或行為，而是對項目或設計的行為動作或行為進行限制。通常通過"限制”強調其限制性。

（1）業務環境限制（來自客戶或出資方的限制條件）

• 預算的限制
• 上線時間的限制
• 業務領域的限制
• 業務規則的限制
• 業務限制的限制
• 法律或專利的限制

（2）使用者使用環境的限制（使用者）

• 使用群體的限制
• 使用者年齡的限制
• 使用者喜好的限制
• 使用期間的環境：如移動性、車載等
• 運作平台的限制，如隻能運作在Linux環境中
• 資料庫的限制

（3）建構環境的限制（來自開發團隊的實際情況的限制）

• 開發團隊的開發環境
• 開發團隊的技術水準
• 開發團隊的成員工作地點的分布
• 開發項目管理的限制
• 是否需要開放源代碼的限制

（4）技術環境的限制

• 業内的技術水準的限制

（5）技術要求的限制

• 性能名額的限制
• 功能的限制
• 體積、總量、功耗

找出、發現這些隐性的限制是一件非常重要的任務，如果無視一些限制，有可能會成為項目或需求無法實作的一顆炸藥或一個大坑。

3. 資料描述

3.1 靜态資料

靜态資料是指在運作過程中主要作為控制或參考用的資料,它們在很長的一段時間内不會變化，一般不随運作而變。

3.2 動态資料

動态資料包括所有在運作中發生變化的資料以及在運作中需要輸入、輸出的資料及在連機操作中要改變的資料。

3.3 資料庫介紹

資料庫是“按照資料結構來組織、存儲和管理資料的倉庫”。是一個長期存儲在​​計算機​​内的、有組織的、可共享的、統一管理的大量資料的集合。

3.4 資料詞典

IBM計算詞典中定義的​​資料字典​​​或元​​資料存儲​​​庫是“有關​​資料​​的資訊的集中存儲庫，例如含義、與其他資料的關系、來源、用法和格式”。Oracle将其定義為具有中繼資料的表的集合。

3.5 資料采集

資料采集(DAQ)，是指從​​傳感器​​​和其它待測裝置等​​模拟​​​和數字被測單元中自動采集​​非電量​​​或者​​電量​​​信号,送到​​上位機​​​中進行分析，處理。​​資料采集系統​​​是結合基于​​計算機​​​或者其他專用測試平台的測量軟硬體産品來實作靈活的、使用者自定義的​​測量系統​​。

4. 功能需求概述

功能需求規定開發人員必須在産品中實作的軟體功能，使用者利用這些功能來完成任務，滿足業務需求功能需求有時也被稱作行為需求。

功能需求，描述是開發人員需要實作什麼。

産品特性，是指一組邏輯上相關的功能需求，它們為使用者提供某項功能，使業務目标得以滿足對商業軟體而言。特性則是一組能被客戶識别，并幫助他決定是否購買的需求。

4.1 功能劃分

對大的功能需要進行分解，分解成一個個相對獨立的功能。功能性需要取決于客戶對系統的操作性需要。

4.2 功能概述

（1）用使用者故事描述

（2）使用者場景進行描述

（3）用使用者用例進行描述

（4）用時序圖進行描述

（5）用獨立文本進行描述

5. 非功能性需求概述

非功能性需求，是指​​軟體産品​​為滿足使用者業務需求而必須具有且除功能需求以外的特性，包括安全性、可靠性、互操作性、健壯性等。

非功能性需求是随着軟體系統的規模成長和複雜性增加這兩個因素才逐漸成為軟體工程師們的新着眼點和關注點的，早期的時候，甲方處于自身對軟體技術的了解和自身對系統檔案維護的友善性考慮等，對系統有了諸如：開發平台、技術流派、關鍵實作等等方面的要求，這被稱之為“設計限制”。從甲乙雙方合同的角度，設計限制也是一種需求——一種“非功能”性的需求，後來，軟體的品質問題越來越突出，描述軟體品質目标的要求也成為非功能性需求的一部分。于是，目前業界關于軟體的非功能需求，一般就包括：品質屬性要求和限制性要求。

場景的性能名額有：

（1）容量：最大使用者數

（2）并發量：同時并發運作的程序數、使用者數

（3）響應時間

6. 對外接口概述

6.1 使用者界面

• 靜态頁面
• 頁面切換

6.2 硬體接口

• 硬體信号名稱、含義
• 硬體時序

6.3 軟體接口

• 消息/函數名稱
• 消息/函數格式
• 消息時序

6.4 故障處理

• 告警名稱與含義
• 告警處理

7. 其他需求

執行個體參考：