編者說明：
當需求調查、分析工作告一段落時，你就需要將這些需求進行規格化描述，整理成文，即軟體需求規格說明書，也就是srs。這是在軟體專案過程中最有價值的乙個文件。iso所提供的標準雖然已經時間久遠，但還是頗具參考價值的。
1．引言
1.1編寫的目的
[說明編寫這份需求說明書的目的,指出預期的讀者。]
1.2背景
a. 待開發的系統的名稱;
b. 本專案的任務提出者、開發者、使用者；
c. 該系統同其他系統或其他機構的基本的相互來往關係。
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裝置
[列出執行該軟體所需要的硬裝置。說明其中的新型裝置及其專門功能，包括：
a. 處理器型號及記憶體容量
b. 外存容量、聯機或離線、**及其儲存格式，裝置的型號及數量
c. 輸入及輸出裝置的型號和數量，聯機或離線；
d. 資料通訊裝置的型號和數量
e. 功能鍵及其他專用硬體]
4.2支援軟體
[列出支援軟體，包括要用到的作業系統、編譯程式、測試支援軟體等。]
4.3介面
[說明該系統同其他系統之間的介面、資料通訊協議等。]
4.4控制
[說明控制該系統的執行的方法和控制訊號，並說明這些控制訊號的**。]
編者說明：
如果在需求分析時採用了用例（use case）技術，那麼該需求規格說明書將更加符合你的需要。當然，你也可以結合volere需求規格說明書對該模板進行必要的修改。
1.文件概述
[該部分主要是對軟體需求規格說明書文件進行基本的描述，包括該文件的目的、範圍、術語定義、參考資料以及概要。]
[軟體需求規格說明書用來系統、完整地記錄系統的軟體需求。該軟體需求說明書的基礎是用例分析技術。因此該文件中應包括用例模型、補充規約等內容。]
1.1目的
[在此小節中，主要對軟體需求規格說明書的目的做一概要性說明，通常軟體需求規格說明書應詳細地說明應用程式、子系統的外部行為，還要說明非功能性需求、設計約束，以及其它的相關因素。]
1.2範圍
[系統是有範圍的，而不是無限擴充套件的，對於無限擴充套件的需求是無法進行描述的。因此，在本小節應該對該說明書所涉及的專案範圍進行清晰的界定。指定該規格說明書適用的軟體應用程式、特性或者其它子系統分組、其相關的用例模型。
當然在此也需要列出會受到該文件影響的其它文件。]
1.3 定義、首字母縮寫詞和縮略語
[與其它文件一樣，該文件也需要將本文件中所涉及的所有術語、縮略語進行詳細的定義。還有一種可簡明的做法，就是維護在乙個專案詞彙表中，這樣就可以避免在每個文件中都重複很多內容。]
1.4參考資料
[在這一小節中，應完整地列出該文件引用的所有文件。對於每個引用的文件都應該給出標題、標識號、日期以及**，為閱讀者查詢這些文件提供足夠詳細的資訊。]
1.5概述
[在本小節中，主要是說明軟體需求規格說明書各個部分所包含的主要內容，就像乙個文章摘要一樣。同時也應該對文件的組織方式進行解釋。]
2. 整體說明
[在本節中，將對整個軟體需求進行總體性的描述，以期讓讀者對整個軟體系統的需求有乙個框架性的認識。也就是說，該節中主要包括影響產品及其需求的一般因素，而不列舉具體的需求。主要包括產品總體效果、產品功能、使用者特徵、約束、假設與依賴關係、需求子集等方面的內容。
]2.1用例模型
[在本小節中，將列出該軟體需求的用例模型，該模型處於系統級，對系統的特性進行巨集觀的描述。在此應該列出所有的用例和actor的名稱列表，並且對其做出簡要的說明，以及在圖中的各種關係。]
2.2假設與依賴關係
[在軟體系統的開發過程中，存在許多假設和依賴關係。在本小節中應列舉出所有的重要的技術可行性假設、子系統或構件可用性假設，以及一些可行性的假設。]
3.具體需求
[如果說第二章節是框架，那麼本節就是血肉。在本節中，應該詳細列出所有的軟體需求，其詳細程式應使設計人員能夠充分理解並且進行設計的要求，同時也應該給予測試人員足夠的資訊，以幫助他們來驗證系統是否滿足了這些需求。整個需求的組織可以採用用例描述進行。
]3.1用例描述
[如果你使用用例建模技術，那麼你已經通過用例定義了系統的大部分功能性需求和一些非功能性需求。因此，在軟體需求規格說明書只需將這些具體的用例描述，整理在一起，全部放在該小節之中。當然也可以將用例描述做為附件，在此列出引用，只是這樣做並不利於閱讀。
建議在組織形式上採用以「軟體需求」為線索，在每個需求中，填入對應的1個或幾個用例描述。]
3.2補充需求
[由於用例畢竟主要針對功能性需求，因此還會有一些其它的補充需求遺漏，因此在本小節中就是將這些東西補充出來。這些補充需求大部分集中在非功能需求之上，包括以下幾個方面的內容：]
1） 易用性：例如指出普通使用者和高階使用者要高效地執行某個特定操作所需的培訓時間；指出典型任務的可評測任務次數；或者指出需要滿足的可用性標準（如ibm的cua標準、microsoft的gui標準。
2） 可靠性：包括系統可用性（可用時間百分比、使用小時數、維護訪問權、降紙模式操作等）；平均故障間隔時間（mtbf，通常表示為小時數，但也可表示為天數、月數或年數）；平均修復時間（mttr，系統在發生故障後可以暫停執行的時間）；精確度（指出系統輸出要求具備的精密度、解析度和精確度）；最高錯誤或缺陷率（通常表示為bugs/kloc，即每千行**的錯誤數目或 bugs/function-point，即每個功能點的錯誤數目）；錯誤或缺陷率（按照小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對「嚴重」錯誤進行界定，例如：
資料完全丟失或完全不能使用系統的某部分功能）。
3） 效能：包括對事務的響應時間（平均、最長）；吞吐量（例如每秒處理的事務數）；容量（例如系統可以容納的客戶或事務數）；降級模式（當系統以某種形式降級時可接受的執行模式）；資源利用情況：記憶體、磁碟、通訊等。
4） 其它：包括使用者介面要求、聯機幫助系統要求、法律許可、外購構件，以及作業系統、開發工具、資料庫系統等設計約束。
4.支援資訊
[支援資訊用於使軟體需求規格說明書更易於使用。它包括：目錄、索引、附錄等。]
編者說明：
軟體需求規格說明是十分重要的文件，因此為開發團隊提供乙份詳細的編制指南是十分有意義和必要的。本文件就是乙個編制指南的例子，你可以根據該指南，結合自己的實際情況進行修改。
1．引言
1.1 目的和作用
本指南為軟體需求實踐提供了乙個規範化的方法。本指南不提倡把軟體需求說明（software requirements specifications，以下簡稱srs）劃分成等級，避免把它定義成更小的需求子集。
本指南適用物件：
1）軟體客戶（customers），以便精確地描述他們想獲得什麼樣的產品。
2）軟體開發者（suppliers），以便準確地理解客戶需要什麼樣的產品。
對於任一要實現下列目標的單位和（或）個人：
1）要提出開發規範化的srs提綱；
2）定義自己需要的具體的格式和內容；
3）產生附加的區域性使用條款，如srs質量檢查清單或者srs作者手冊等。
srs將完成下列目標：
1） 在軟體產品完成目標方面為客戶和開發者之間建立共同協議創立乙個基礎。對要實現的軟體功能做全面描述，幫助客戶判斷所規定的軟體是否符合他們的要求，或者怎樣修改這種軟體才能適合他們的要求；
2） 提高開發效率。編制srs的過程將使客戶在設計開始之前周密地思考全部需求，從而減少事後重新設計、重新編碼和重新測試的返工活動。在srs中對各種需求仔細地進行複查，還可以在開發早期發現若干遺漏、錯誤的理解和不一致性，以便及時加以糾正；
3） 為成本計價和編制計畫進度提供基礎。srs提供的對被開發軟體產品的描述，是計算機軟體產品成本核算的基礎，並且可以為各方的要價和付費提供依據。srs對軟體的清晰描述，有助於估計所必須的資源，並用作編制進度的依據；
4） 為確認和驗證提供乙個基準。任何組織將更有效地編制他們的確認和驗證計畫。作為開發合同的一部分，srs還可以提供乙個可以度量和遵循的基準（然而，反之則不成立，即任一有關軟體的合同都不能作為srs。
因為這種檔案幾乎不包括詳盡的需求說明，並且通常不完全的）；
5） 便於移植。有了srs就便於移值軟體產品，以適應新的使用者或新的機種。客戶也易於移植其軟體到其他部門，而開發者同樣也易於把軟體移植到新的客戶；
6） 作為不斷提高的基礎。由於srs所討論的是軟體產品，而不是開發這個產品的設計。因此srs是軟體產品繼續提高的基礎。
雖然srs也可能要改變，但是原來的srs還是軟體產品改進的可靠基礎。
1.2 範圍
本指南適用於編寫軟體需求規格說明，它描述了乙個srs所必須的內容和質量，並且在第6章中提供了srs大綱。
需求規格說明書
專案編號 需求規格說明書 注意 使用時請仔細閱讀斜體提示部分，文件完成後請刪除斜體部分，刪除後請注意文件的格式。修改說明 目錄1.引言 6 1.1.目的 6 1.2.範圍 6 1.3.讀者 6 1.4.參考文獻 6 1.5.術語與縮寫解釋 6 2.概述 7 2.1.專案 任務背景 7 2.2.專案 ...
需求規格說明書
文件編號 版本號 商務網 2012 年 5 月 目錄1 引言 4 1.1編寫目的 4 1.2專案說明 4 1.3 專案背景 4 1.4 定義 5 1.5 參考資料 5 2 任務概述 6 2.1目標 6 2.2 建設任務 6 2.3 使用者特點 6 3功能需求 7 3.1 系統範圍 7 3.2 系統體...
需求規格說明書
文件編號 x x xx xx x x x科技工程專案 x x x x x研發工程需求規格說明書 版本歷史 目錄1 引言 3 1.1 編寫目的 3 1.2 專案背景 4 1.3 參考資料 4 1.4 定義術語 4 2 任務概述 4 2.1 任務目標 4 2.2 執行環境 4 2.3 條件與限制 4 3...