軟體需求說明，也稱軟體需求說明書，或者軟體需求規格說明，或者軟體需求規格說明書， 對應的英文是software requirements specification, 縮寫是srs。
軟體需求說明是軟體系統需求的規格化說明，是對將要開發系統的行為的說明。它包括功能性需求，也包括非功能性需求。
根據中國大陸gb8567-88 計算機軟體產品開發檔案編制指南，軟體需求說明書章節如下：
1引言至今各組織的軟體需求說明書模板雖然經過使用後歷經調整，但往往仍然能夠看到上述章節要求的痕跡。1．1編寫目的
1．2背景
1．3定義
1．4參考資料
2任務概述
2．1目標
2．2使用者的特點
2．3假定與約束
3需求規定
3．1對功能的規定
3．2對效能的規定
3．2．1精度
3．2．2時間特性耍求
3．2．3靈活性
3．3輸入輸出要求
3．4資料管理能力要求
3．5故障處理要求
3．6其他專門要求
4執行環境規定
4．1裝置
4．2支援軟體
4．3介面
4．4控制
到目前的2023年，在軟體需求表達方式領域出現了如下三種常見情況：
仍然基於傳統srs表達方式，常見的利用word來書寫
採用用例分析的表達方式，常見的利用uml工具來管理，比如rose，ea等等[6]
使用者故事的表達方式，常見的利用條目化（工作項）工具來管理，比如卡片，jira，vsts，scrumworks等
有些組織雖然仍然稱呼需求文件為需求說明書（或者srs），而實質的表達採用的是用例，這種情況歸屬於上述的第2種情況。這樣包含用例的srs的常見章節如下：
1 專案概況在最新的swebok v3.0[7]1.1 產品或系統名稱
1.2 產品或系統使用者
1.3 執行平台
1.4 詞彙表
1.5 資料字典
2 效能指標和驗收標準
3 功能需求概況
3.1 總體概述
3.2 功能模組劃分
3.3 功能塊編碼
4 模組1 [例如]使用者組織
4.1 模組概述
4.2 業務邏輯規則
4.3 用例圖
4.4 用例1 [例如]用例：使用者登入
4.4.1 描述
4.4.2 對應的原始需求
4.4.3 前提條件
4.4.4 事件流
4.4.5 使用者介面
4.4.6 後置條件、特別要求和擴充套件點
4.5 用例2實現
4.5.1 描述
4.5.2 對應的原始需求
4.5.3 前提
4.5.4 事件流
4.5.5 使用者介面
4.5.6 後置條件、特別要求和擴充套件點
4.6 外部介面
5 模組2 格式同第5章
5.1 概述
5.2 業務邏輯規則
5.3 用例圖
5.4 用例1實現
5.5 用例2實現
5.6 外部介面
6 模組3…n
7 資訊保安方面需求
7.1 許可證方面需求
7.2 身份認證和授權方面需求
7.3 可恢復性方面需求
8 其它非功能性需求
9 其它要求
中，在這一領域仍然採用了「software requirements specification」的說法。
但是在中文領域，軟體需求說明書是無法在字面意思上涵蓋：1，不採用srs寫法的用例分析；2，使用者故事。
因此，提議中文領域對應詞彙是「軟體需求說明"或者「軟體需求規格說明", 沒有「書」字，這樣的字面意思就能夠涵蓋用例和使用者故事。
說明：至於表達內部事務的使用者故事是否屬於需求範疇，那是另一回事，畢竟多數的使用者故事表達的是需求。
^software requirements specification
^gb8567-88 計算機軟體產品開發檔案編制指南
^830-1984 - ieee guide to software requirements specifications
^gb9385-88 計算機軟體需求說明編制指南
^gb/t9385-2008 《計算機軟體需求說明編制指南》
^張秋餘 楊玥 王雪 王鵬 賈志龍 基於用例的需求建模方法 《計算機工程與設計》 2023年19期
^guide to the software engineering body of knowledge v3.0 swebok v3.0
軟體需求說明書
軟體需求說明書 軟體需求說明書 1 引言 1.1 編寫目的 闡明編寫需求說明書的目的，指明讀者物件。1.2 專案背景 應包括 專案的委託單位 開心單位和主管部門 該軟體系統與其他系統的關係。1.3 定義 列出文件中所用到的專門術語的定義和縮寫詞的願文。專案經核准的計畫任務書 合同或上級機關的批文 文...
軟體需求說明書
軟體需求說明書是需求分析階段的第乙個文件，是對軟體目標範圍的求精和細化，深化描述軟體的功能和效能以及軟體的約束範圍，使使用者和軟體開發者對初始規定有個大概的了解，有利於對專案的回溯並指導後續的開發和維護工作。文件的讀者 開發人員和使用者代表 1 專案名稱 機房收費系統 2 專案提出者 廊坊師範學院公...
軟體工程 需求說明
在軟體行業已經做了好幾年了，由於公司風格的原因，缺少真實處理需求的人員，需求編寫環節只是機械性的填寫文件，沒有經過嚴謹思考的，泥沙俱下的需求文件，常常讓程式設計師無從下手，導致技術方向出問題。最近下決心好好梳理一遍。提公升自身的專業化 職業化能力。軟體是現代系統中的重要元素，使這些產品 系統成為使用...