《系統（子系統）名稱》軟體功能需求說明書
版本控制
目錄1 引論 2
1.1 目的 2
1.2 文件約定 2
1.3 預期的讀者和閱讀建議 2
1.4 產品的範圍 2
1.5 參考文獻 3
2 綜合描述 3
2.1 產品的前景 3
2.2 產品的功能 3
2.3 使用者分類和特徵 3
2.4 執行環境 3
2.5 設計和實現上的限制 4
2.6 使用者文件 4
2.7 假設和依賴 4
3 外部介面需求 4
3.1 使用者介面 4
3.2 硬體介面 5
3.3 軟體介面 5
3.4 通訊介面 5
4 系統特性 5
4.1 系統特性 1 5
4.1.1 描述和優先順序 5
4.1.2 激勵/響應序列 6
4.1.3 功能需求 6
4.2 系統特性 2 (等等) 6
5 其它非功能需求 6
5.1 效能需求 6
5.2 安全設施需求 6
5.3 安全性需求 6
5.4 軟體質量屬性 7
5.5 業務規則 7
6 其它需求 7
附錄a: 詞彙表 7
附錄b: 分析模型 7
附錄c: 待確定問題（tbd）列表 7
＜引言提出了對軟體需求規格說明的縱覽，這有助於讀者理解文件如何編寫並且如何閱讀和解釋。＞
＜對產品進行定義，在該文件中詳盡地說明了這個產品的軟體需求，包括修正或發行版本號。如果這個軟體需求規格說明只與整個系統的一部分有關係，那麼就只定義文件中說明的部分或子系統。＞
＜描述編寫文件時所採用的標準或排版約定，包括正文風格、提示區或重要符號。例如，說明了高層需求的優先順序是否可以被其所有細化的需求所繼承，或者每個需求陳述是否都有其自身的優先順序。＞
＜列舉了軟體需求規格說明所針對的不同讀者，例如開發人員、專案經理、營銷人員、使用者、測試人員或文件的編寫人員。描述了文件中剩餘部分的內容及其組織結構。提出了最適合於每一型別讀者閱讀文件的建議＞
＜提供了對指定的軟體及其目的的簡短描述，包括利益和目標。把軟體與企業目標或業務策略相聯絡。可以參考專案檢視和範圍文件而不是將其內容複製到這裡。＞
＜列舉了編寫軟體需求規格說明時所參考的資料或其它資源。這可能包括使用者介面風格指導、合同、標準、系統需求規格說明、使用例項文件，或相關產品的軟體需求規格說明。在這裡應該給出詳細的資訊，包括標題名稱、作者、版本號、日期、出版單位或資料**，以方便讀者查閱這些文獻。
＞＜這一部分概述了正在定義的產品以及它所執行環境、使用產品的使用者和已知的限制、假設和依賴。＞
＜描述了軟體需求規格說明中所定義的產品的背景和起源。說明了該產品是否是產品系列中的下一成員，是否是成熟產品所改進的下一代產品、是否是現有應用程式的替代品，或者是否是乙個新型的、自含型產品。如果軟體需求規格說明定義了大系統的乙個組成部分，那麼就要說明這部分軟體是怎樣與整個系統相關聯的，並且要定義出兩者之間的介面。
＞＜概述產品所具有的主要功能。其詳細內容將在系統特性中描述，所以在此只需要概略地總結，例如用列表的方法給出。很好地組織產品的功能，使每個讀者都易於理解。
用圖形表示主要的需求分組以及它們之間的聯絡，例如流程圖的頂層圖或類圖，都是有用的。＞
＜確定你常見得可能使用該產品的不同使用者類並描述它們相關的特徵，有一些需求可能只與特定的使用者類相關。將該產品的重要使用者類與那些不太重要的使用者類區分開。＞
《描述軟體的執行環境，包括硬體平台、作業系統和版本、還有其它的軟體元件或與其共存的應用程式。>
＜確定影響開發人員自由選擇的問題，並說明這些問題為什麼成為一種限制。可能的限制包括如下內容：
必須使用或避免的特定技術、工具、程式語言和資料庫。
所要求的開發規範或標準（例如，如果由客戶的公司負責軟體維護，就必須定義轉包者所使用的設計符號表示和編碼標準）
企業策略、**法規或工業標準。
硬體限制，例如定時需求或儲存器限制。
資料轉換格式標準。＞
＜列舉出將與軟體一同發行的使用者文件部分，例如，使用者手冊、**幫助和教程。明確所有已知的使用者文件的交付格式或標準。＞
＜列舉出在對軟體需求規格說明中影響需求陳述的假設因素（與已知因素相對立）。這可能包括你打算要用的商業元件或有關開發或執行環境的問題。你可能認為產品將符合乙個特殊的使用者介面設計約定，但是另乙個srs讀者卻可能不這樣認為。
如果這些假設不正確、不一致或被更改，就會使專案受到影響。
此外，確定專案對外部因素存在的依賴。例如，如果你打算把其它專案開發的元件整合到系統中，那麼你就要依賴那個專案按時提供正確的操作元件。如果這些依賴已經記錄到其它文件（例如專案計畫）中了，那麼在此就可以參考其它文件。
＞＜利用本節來確定可以保證新產品與外部元件正確連線的需求。關聯圖表示了高層抽象的外部介面。需要把對介面資料和控制項的詳細描述寫入資料字典中。
如果產品的不同部分有不同的外部介面，那麼應把這些外部介面的詳細需求併入到這一部分的例項中。＞
《陳述所需要的使用者介面的軟體元件。描述每個使用者介面的邏輯特徵。以下是可能要包括的一些特徵：
將要採用的圖形使用者介面（gui）標準或產品系列的風格。
螢幕布局或解決方案的限制
將出現在每個螢幕的標準按鈕、功能或導航鏈結（例如乙個幫助按鈕）
快捷鍵錯誤資訊顯示標準
對於使用者介面的細節，例如特定物件框的布局，應該寫入乙個獨立的使用者介面規格說明中。
本節內容可以單列乙個標題，給與更為詳細的描述，如介面的選單樹、每個選單下的需求等。>
＜描述系統中軟體和硬體每一介面的特徵。這種描述可能包括支援的硬體型別、軟硬體之間交流的資料和控制資訊的性質以及所使用的通訊協議。＞
＜描述該產品與其它外部元件（由名字和版本識別）的連線，包括資料庫、作業系統、工具庫和整合的商業元件。明確並描述在軟體元件之間交換資料或訊息的目的。描述所需要的服務以及內容元件通訊的性質。
確定將在元件之間共享的資料。如果必須用一種特殊的方法來實現資料共享機制，例如在多工作業系統中的乙個全域性資料區，那麼就必須把它定義為一種實現上的限制。＞
＜描述與產品所使用的通訊功能相關的需求，包括電子郵件、web瀏覽器、網路通訊標準或協議及電子**等等。定義了相關的訊息格式。規定通訊安全或加密問題、資料傳輸速率和同步通訊機制。＞
＜功能需求是根據系統特性即產品所提供的主要服務來組織的。你可能更喜歡通過使用例項、執行模式、使用者類、物件類或功能等級來組織這部分內容（ieee1998）。或者使用這些元素的組合。
用簡短的語句從以下三個方面說明特性的名稱＞
《提出了對該系統特性的簡短說明並指出該特性的優先順序是高、中、低。或者可以包括對特定優先順序部分的評價》
《列出輸入激勵（使用者運用、來自外部裝置的訊號或其它觸發器）和定義這一特性行為的系統響應序列。>
《詳細列出與該特性相關的詳細功能需求，使使用者可以使用所提供的特性執行任務或者使用所指定的使用例項執行任務。描述產品如何響應可預知的出錯條件或非法輸入或動作。>
《如果以下每個req標號的優先順序或激勵/響應序列與該系統特性的總體有不同，在下面的各req中應該特別標識出來。>
req-4.1-1：
描述：（可選）
優先順序：（可選）
激勵/響應序列：（可選）
req-4.2-2：
《如果每個req有不同的優先順序或激勵/響應序列，可以特別標識出來》
《闡述了不同的應用領域對產品效能的需求，並解釋它們的原理幫助開發人員作出合理的設計選擇。確定相互合作的使用者數或者所支援的操作、響應時間以及與實時系統的時間關係。還可以定義容量需求。
盡可能確定效能需求。可能需要針對每個功能需求或特性分別陳述其效能需求，而不是把它們都集中在一起陳述。>
《詳盡陳述與產品使用過程中可能發生的損失、破壞或危害相關的需求。定義必須採取的安全保護或動作，還有那些預防的潛在的危險動作。明確產品必須遵從的安全標準、策略或規則。>
＜詳盡陳述與系統安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所建立或使用的資料的保護。定義使用者身份確認或授權需求。明確產品必須滿足的安全性或保密性策略。＞
軟體開發流程說明
第一步 需求調研分析 1 相關系統分析員向使用者初步了解需求，然後用word列出要開發的系統的大功能模組，每個大功能模組有哪些小功能模組，對於有些需求比較明確相關的介面時，在這一步裡面可以初步定義好少量的介面。2 系統分析員深入了解和分析需求，根據自己的經驗和需求用word或相關的工具再做出乙份文件...
軟體開發流程規範說明
四 系統設計階段 本階段包括系統概要設計和詳細設計兩個子階段。概要設計的工作是開發人員根據使用者已驗收簽署的 系統需求說明書 描述出軟體系統的總體藍圖，它包括設計系統組織結構圖 業務流程圖 系統功能模組結構 資料流程圖設計 資料庫的e r圖設計 資料庫表 資料字典以及相應資料邏輯設計等 詳細設計階段...
需求驅動的軟體開發平台技術建議書
文件編號 ibm rational需求驅動的軟體開發平台技術方案 2010年4月 目錄 2 1.概述 4 2.平台目標 5 2.1.平台目標 5 2.2.平台功能 6 2.2.1.集中管理 6 2.2.2.需求管理 6 2.2.3.版本控制 6 2.2.4.專案開發流程管理 7 2.2.5.基線管理...