編者說明：
當需求調查、分析工作告一段落時，你就需要將這些需求進行規格化描述，整理成文，即軟件需求規格說明書，也就是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控制
[說明控制該系統的運行的方法和控制信號，并說明這些控制信號的來源。]
軟件需求規格說明書（RUP版）
編者說明：
如果在需求分析時采用了用例（U ca）技術，那么該需求規格說明書將更加符合你的需要。當然，你也可以結合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 目的和作用
本指南為軟件需求實踐提供了一個規范化的方法。本指南不提倡把軟件需求說明（Softwar
e 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大綱。
