[需求管理-9]：需求规格说明书SRS
目錄
第1章 需求規(guī)格說明書概述
1.1 什么軟件項目需求規(guī)格說明書
1.2? 需要規(guī)格說明書在項目中階段
1.3?需要規(guī)格說明書的作用
1.4 主要特點
1.5 衡量標準
1.7 評審注意事項
第2章?需要規(guī)格說明書的格式與主要內容
1 引言
1.1 目的
1.2 背景
1.3 定義
1.4 參考資料
2 需求概述
2.1 總體目標
2.2 運行環(huán)境
2.3 約束條件（CONSTRAINTS）與假定條件（ASSUMPATION）
3. 數(shù)據(jù)描述
3.1 靜態(tài)數(shù)據(jù)
3.2 動態(tài)數(shù)據(jù)
3.3 數(shù)據(jù)庫介紹
3.4 數(shù)據(jù)詞典
3.5 數(shù)據(jù)采集
4. 功能需求概述
4.1 功能劃分
4.2 功能概述
5. 非功能性需求概述
6. 對外接口概述
6.1 用戶界面
6.2 硬件接口
6.3 軟件接口
6.4 故障處理
7. 其他需求
實例參考：
第1章 需求規(guī)格說明書概述
1.1 什么軟件項目需求規(guī)格說明書
軟件項目需求說明書是指在研究用戶要求的基礎上，完成可行性分析和投資效益分析以后，由軟件系統(tǒng)工程師或分析員編寫的需求說明書。
它詳細定義了信息流和界面，功能需求，設計要求和限制，測試準則和質量保證要求。
當然，軟件項目需求規(guī)格說明書是站在用戶的角度看到的系統(tǒng)功能。而不是從軟件系統(tǒng)內部的角度看到的外部接口的需求。前者是由外向內看，后者是由內向外看。
這是寫需求規(guī)格說明書，必須有的立足點。
需求規(guī)格說明書關注的是從外看到系統(tǒng)的功能需求，而不是內部的具體設計，更不是具體的實現(xiàn)。
軟件需求規(guī)格說明書是需求分析階段最后的成果，它是作為需求分析的一部分而制定的可交付文檔。軟件需求說明書，又稱為軟件規(guī)格說明書，是分析員在需求分析階段需要完成的文檔，是軟件需求分析的最終結果。
1.2? 需要規(guī)格說明書在項目中階段
需要規(guī)格說明書發(fā)生在概念階段或需求階段 ，這一階段分為兩個過程：
（1）概念的形成過程
根據(jù)用戶單位業(yè)務發(fā)展和經營管理的需要，提出建設信息系統(tǒng)的初步構想
（2）需求分析過程
即對企業(yè)信息系統(tǒng)的需求進行深入調研和分析，形成《需求規(guī)范說明書》 ，經評審、批準后立項。
也就是說，需要規(guī)格說明書是在項目啟動之前的階段，沒有需求規(guī)格說明說，項目是無法啟動的。
1.3?需要規(guī)格說明書的作用
《需要規(guī)格說明書》代表的是客戶對項目的需求。它限定了項目的目標和任務，也是客戶驗收的標準。
它的作用是作為用戶和軟件開發(fā)人員達成的技術協(xié)議書，作為著手進行設計工作和編碼的基礎和依據(jù)，系統(tǒng)開發(fā)完成以后，為產品的驗收提供了依據(jù)。
需要規(guī)格說明書作用為：
（1）軟件人員與用戶之間事實上的技術合同說明；
（2）為項目管理的范圍管理、成本管理提供了依據(jù)
（3）作為軟件人員下一步進行設計和編碼的基礎；
（4）作為測試和驗收的依據(jù)。
（5）為軟件的維護提供的重要信息
1.4 主要特點
軟件需求規(guī)格說明書應該完整、一致、精確、無二義性，同時又要簡明、易懂、易修改。
由于軟件需求說明書最終要得到開發(fā)者和用戶雙方的認可，所以用戶要能看得懂，并且還能發(fā)現(xiàn)和指出其中的錯誤，這對于保證軟件系統(tǒng)的質量有很大的作用。這就要求需求說明書盡可能少用或不用計算機領域的概念和術語，盡量使用行業(yè)用戶的專業(yè)術語來闡述（而不是計算機領域的術語）
1.5 衡量標準
（1）完整性
每一項需求都必須將所要實現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設計和實現(xiàn)這些功能所需的所有必要信息。
不遺漏任何必要的需求信息，即目標軟件的所有功能、性能、設計約束，以及所有的可能情況下的預期行為，均完整地體現(xiàn)在需求說明書中。
（2）正確性
每一項需求都必須準確地陳述其要開發(fā)的功能。
需求說明書中的功能、性能等描述與用戶對軟件的期望相一致。
（3）可行性
每一項需求都必須是在已知系統(tǒng)和環(huán)境的權能和限制范圍內可以實施的。
（4）無二義性
對所有需求說明的讀者都只能有一個明確統(tǒng)一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求用簡潔明了的用戶性的語言表達出來。另外，需求說明書的各部分之間不能相互矛盾。
（5）可驗證性
需求說明書中的任意一項需求，都存在技術和經濟上可行的手段進行驗證和確認。
（6）可修改性（可伸縮性）
需求說明書的格式和組織方式應該保證能夠比較容易地增、刪和修改，并使修改后的需求說明書能夠軟較好地保持其他各項屬性。
（7）可跟蹤性
應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，使每項需求與用戶的原始需求連起來，并為后續(xù)開發(fā)和其他文檔引用這些需求項提供便利。這種可跟蹤性要求每項需求以一種結構化的，粒度好的方式編寫并單獨標明，而不是大段大段的敘述。
也就是說，每項需要都是以一個個獨立項而存在和維護的。
1.6 需求規(guī)格說明的評審review
（1）參與人員
- 客戶或客戶的代表（產品經理）
- 系統(tǒng)架構師
- 系統(tǒng)工程師（來自目標系統(tǒng)受影響的技術模塊領域）
- 軟件架構師以及核心開發(fā)人員（來自目標系統(tǒng)受影響的技術模塊領域）
- 測試架構師以及核心測試人員（來自目標系統(tǒng)受影響的技術模塊領域）
- 用戶手冊撰寫人員
（2）評審流程
- 啟動kick off
- 草擬、討論、周會 （會議）
- 最終文檔的評審 （在線+會議）
- 最終文檔的授權
1.7 評審注意事項
（1）是否有內容與語法上的錯誤？
這是最基本的要求，不能有內容與語法上的錯誤。
（2）前后不一致性、矛盾性？
一份需求規(guī)格說明說，是經過大量的需求人員經過較長時間的討論、輸入形成的，因此需要關注前后前后一致性，檢查是否有前后矛盾的地方。
（3）是否清晰、無異議的表達了需求？
可以基于SMART原則來檢查需求。
（4）每個需要都是在項目范圍內？
防止需要中的內容超出了需求規(guī)格說明書本身的范圍。有些需求，它不屬于需求規(guī)格說明書的范圍，但確實項目的范圍，比如對于人員的學歷要求等。這些信息不應該放到需求規(guī)格說明書中。
（5）異常處理？
是否考慮了異常出錯處理？沒一種異常都需要明確的定義。
（6）在組織內現(xiàn)有的資源內，是否可以實現(xiàn)？
需求規(guī)格說明書是直到開發(fā)實現(xiàn)需要的。如果有需要，在現(xiàn)有的資源（人力資源和物質資源）的情況下，無法實現(xiàn)，這樣的需求就不適合放到需求規(guī)格說明書中，需要通過分解、變通等方法來化解不可實現(xiàn)的需求。
1.8 需求規(guī)格說明的的格式
需要規(guī)格說明書必須用統(tǒng)一格式的文檔進行描述，為了使需求分析描述具有統(tǒng)一的風格，可以采用已有的且能滿足項目需要的模板，也可以根據(jù)項目特點和軟件開發(fā)小組的特點對標準進行適當?shù)母膭?#xff0c;形成自己的模板。
第2章?需要規(guī)格說明書的格式與主要內容
1 引言
1.1 目的
本文檔是進一步分析用戶需求的結果，詳盡說明了這一軟件的需求和規(guī)格，這些規(guī)格說明時進行系統(tǒng)設計的基礎，也是編寫測試用例和進行系統(tǒng)測試的主要依據(jù)。同時，該文檔也是用戶確定軟件功能需求的主要依據(jù)。
本文檔撰寫的目的是明確軟件需求、安排項目計劃、推廣軟件設計和組織軟件開發(fā)和測試。本文檔主題內容為項目的需求匯總分類以及以此為基礎而建立的需求模型。
本說明書的預期讀者是軟件概要設計人員和詳細設計人員，是軟件設計的基礎。
1.2 背景
背景：是指襯托其他事物的要素或背后力量。
闡述項目或特定需求產生的背景，便于各方的干系人了解事情的背景。
1.3 定義
項目的名稱與標識
1.4 參考資料
其他參考資料
2 需求概述
2.1 總體目標
闡述需要解決客戶哪方面的問題或痛點？ 闡述客戶的期望和目標。
2.2 運行環(huán)境
軟件系統(tǒng)的運行環(huán)境（操作系統(tǒng)、計算機硬件等）
2.3 約束條件（CONSTRAINTS）與假定條件（ASSUMPATION）
約束：不是具體的動作或行為，而是對項目或設計的行為動作或行為進行限制。通常通過"約束”強調其限制性。
（1）業(yè)務環(huán)境約束（來自客戶或出資方的約束條件）
- 預算的約束
- 上線時間的約束
- 業(yè)務領域的約束
- 業(yè)務規(guī)則的約束
- 業(yè)務限制的約束
- 法律或專利的約束
（2）用戶使用環(huán)境的約束（使用者）
- 使用群體的約束
- 用戶年齡的約束
- 用戶喜好的約束
- 使用期間的環(huán)境：如移動性、車載等
- 運行平臺的約束，如只能運行在Linux環(huán)境中
- 數(shù)據(jù)庫的約束
（3）構建環(huán)境的約束（來自開發(fā)團隊的實際情況的約束）
- 開發(fā)團隊的開發(fā)環(huán)境
- 開發(fā)團隊的技術水平
- 開發(fā)團隊的成員工作地點的分布
- 開發(fā)項目管理的約束
- 是否需要開放源代碼的約束
（4）技術環(huán)境的約束
- 業(yè)內的技術水平的約束
（5）技術要求的約束
- 性能指標的約束
- 功能的約束
- 體積、總量、功耗
找出、發(fā)現(xiàn)這些隱性的約束是一件非常重要的任務，如果無視一些約束，有可能會成為項目或需求無法實現(xiàn)的一顆炸藥或一個大坑。
3. 數(shù)據(jù)描述
3.1 靜態(tài)數(shù)據(jù)
靜態(tài)數(shù)據(jù)是指在運行過程中主要作為控制或參考用的數(shù)據(jù),它們在很長的一段時間內不會變化，一般不隨運行而變。
3.2 動態(tài)數(shù)據(jù)
動態(tài)數(shù)據(jù)包括所有在運行中發(fā)生變化的數(shù)據(jù)以及在運行中需要輸入、輸出的數(shù)據(jù)及在連機操作中要改變的數(shù)據(jù)。
3.3 數(shù)據(jù)庫介紹
數(shù)據(jù)庫是“按照數(shù)據(jù)結構來組織、存儲和管理數(shù)據(jù)的倉庫”。是一個長期存儲在計算機內的、有組織的、可共享的、統(tǒng)一管理的大量數(shù)據(jù)的集合。
3.4 數(shù)據(jù)詞典
IBM計算詞典中定義的數(shù)據(jù)字典或元數(shù)據(jù)存儲庫是“有關數(shù)據(jù)的信息的集中存儲庫，例如含義、與其他數(shù)據(jù)的關系、來源、用法和格式”。Oracle將其定義為具有元數(shù)據(jù)的表的集合。
3.5 數(shù)據(jù)采集
數(shù)據(jù)采集(DAQ)，是指從傳感器和其它待測設備等模擬和數(shù)字被測單元中自動采集非電量或者電量信號,送到上位機中進行分析，處理。數(shù)據(jù)采集系統(tǒng)是結合基于計算機或者其他專用測試平臺的測量軟硬件產品來實現(xiàn)靈活的、用戶自定義的測量系統(tǒng)。
4. 功能需求概述
功能需求規(guī)定開發(fā)人員必須在產品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務，滿足業(yè)務需求功能需求有時也被稱作行為需求。
功能需求，描述是開發(fā)人員需要實現(xiàn)什么。
產品特性，是指一組邏輯上相關的功能需求，它們?yōu)橛脩籼峁┠稠椆δ?#xff0c;使業(yè)務目標得以滿足對商業(yè)軟件而言。特性則是一組能被客戶識別，并幫助他決定是否購買的需求。
4.1 功能劃分
對大的功能需要進行分解，分解成一個個相對獨立的功能。功能性需要取決于客戶對系統(tǒng)的操作性需要。
4.2 功能概述
（1）用用戶故事描述
（2）用戶場景進行描述
（3）用用戶用例進行描述
（4）用時序圖進行描述
（5）用獨立文本進行描述
5. 非功能性需求概述
非功能性需求，是指軟件產品為滿足用戶業(yè)務需求而必須具有且除功能需求以外的特性，包括安全性、可靠性、互操作性、健壯性等。
非功能性需求是隨著軟件系統(tǒng)的規(guī)模成長和復雜性增加這兩個因素才逐漸成為軟件工程師們的新著眼點和關注點的，早期的時候，甲方處于自身對軟件技術的了解和自身對系統(tǒng)文件維護的方便性考慮等，對系統(tǒng)有了諸如：開發(fā)平臺、技術流派、關鍵實現(xiàn)等等方面的要求，這被稱之為“設計約束”。從甲乙雙方合同的角度，設計約束也是一種需求——一種“非功能”性的需求，后來，軟件的質量問題越來越突出，描述軟件質量目標的要求也成為非功能性需求的一部分。于是，目前業(yè)界關于軟件的非功能需求，一般就包括：質量屬性要求和約束性要求。
場景的性能指標有：
（1）容量：最大用戶數(shù)
（2）并發(fā)量：同時并發(fā)運行的進程數(shù)、用戶數(shù)
（3）響應時間
（4）利用率：CPU、內存、網絡、硬盤
（5）高可用性：高負載多長時間，系統(tǒng)能夠持續(xù)提供服務。
6. 對外接口概述
6.1 用戶界面
- 靜態(tài)頁面
- 頁面切換
6.2 硬件接口
- 硬件信號名稱、含義
- 硬件時序
6.3 軟件接口
- 消息/函數(shù)名稱
- 消息/函數(shù)格式
- 消息時序
6.4 故障處理
- 告警名稱與含義
- 告警處理
7. 其他需求
實例參考：
需求規(guī)格說明書.pdf
總結
以上是生活随笔為你收集整理的[需求管理-9]：需求规格说明书SRS的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： CSharp设计模式读书笔记（18）：中
- 下一篇： 【转贴】利用 Javascript 获取