整理了个软件需求规格说明书模板
?
?
?
1、引言
(引言提供了一個概述，幫助讀者理解軟件需求規格的組織方式和使用方式。)
1.1目的
( 確定其需求在文檔中進行了定義的哪些產品或應用程序，包括修訂版本或發布版本號，如果該軟件需求規格說明書只與整個系統的一部分有關系，那么就只需要確定這一部分或子系統)
本文檔詳細描述影像系統一期工程中的必須滿足的功能需求、非功能需求（質量屬性和外部接口）與限制條件，作為本項目的項目管理人員、系統設計人員、編碼和測試人員以及與本項目相關的其他人員開展工作的基礎和依據，同時也界定了本項目的工作內容。
?
1.2文檔約定
在本文檔中描述的所有需求都有一個唯一的編號標識。該需求編號在需求確立時產生并在整個項目開發過程中保持不變。
1.3讀者對象和閱讀建議
(列舉軟件需求規格說明面向的不同讀者對象。描述軟件需求規格說明中其余部分的內容及其組織結構。就每一類讀者最合適以什么順序來閱讀該文檔提出建議)
本文檔的讀者包括參與本項目的項目管理人員、系統設計人員、編碼和測試人員、用戶代表以及市場人員，上述讀者可以通過閱讀本文檔對將要開發的影像系統有一個全面、詳細的了解和認識。
?
1.4項目范圍
（提供對指定的軟件及其作用的簡短描述。把軟件與用戶或公司目標向關聯，把軟件與義務目標和策略相關聯。如果可以得到單獨的前景和范圍文檔，就應該引用它，而不要直接將其內容復制到這里。如果是說明改進產品的增量發布的軟件需求規格說明，那么應該包括它自己的范圍聲明，作為長期戰略的產品前景的一個子集。）
?
本系統是影像系統（一期）的產品，主要實現….
?
在本系統中實現 系統登錄、圖片管理、單證類型管理、權限管理。
?
1.5參考資料
（列舉編寫軟件需求規格說明書時所參考的所有文檔或其他資源，如果可能的話，使用超文本連接。具體說來可能包括用戶界面樣式指南、合同、標準、系統需求規格說明、用例文檔、接口規格說明、操作概念文檔、或相關產品的軟件需求規格說明。在這里應該給出足夠詳細的信息，包括參考資料的標題、作者、版本號、日期以及來源或位置，以方便）
本文檔引用如下參考文獻：
?
?
2、總體描述
（這一部分用于從總體上概述產品及其運行環境，以及產品用戶對象和已知的約束、假設和依賴關系）
2.1系統前景
（描述從產品的背景和起源。說明該產品是否產品系列中的下一個成員，是否是成熟系統的下一個版本，是現有應用程序的升級產品還是一個全新的產品。如果該軟件需求規格說明定義了大型系統的一個組件，那么就要說明這個部分軟件是怎樣與整個系統相關聯的，并且要確定二者之間的主要接口。）
（系統用來做什么）
影像系統用來管理公司業務系統的圖像信息，為公司其他業務系統提供統一的圖像操作接口。
（系統最終會是什么樣子）
???? 影像系統最終建設為非結構化數據的統一管理操作中心。
2.2 系統功能
???????? （列出產品所具有的主要特性或者產品可能實現的總要功能。其詳細內容將在該軟件需求規格說明的第3部分中描述，所以在此只需要提供一個總體概括即可。用圖形來表示主要的需求組件以及它們之間的聯系，例如頂層數據流圖、用例圖或者類圖，可能是很有幫助的。）
???
???
2.3 用戶分類及其特征
（確定我們能預料到的有可能使用該產品的各類用戶類，并描述它們的相關特征。有些需求可能只與某些用戶類相關，應確定哪些是優先考慮的用戶類。用戶類是前景和范圍文檔中描述的涉眾的一個子集。）
2.4 運行環境
（描述軟件的運行環境，包括硬件平臺、操作系統版本，以及用戶、服務器和數據庫的地理位置。列出系統必須和平共存的其他軟件組件或應用程序）
?
2.5 設計和實現上的約束
（
描述限制開發人員進行有效選擇的所有因素，以及每—種約束的基本原理。約柬可
能包括如下內容：?
?? 必須使用或避免使用的特定技術、工具、編程語言和數據庫。
?? 由產品的運行環境所引起的一些限制，例如，將要使用的web瀏覽器的類型
和版本。
?? 所要求的開發約定或標準(例如，如果由客戶的組織負責軟件維護，那么該組
織就可能指定分包商必須遵循的設計符號和編碼標準)。
?? 與早期產品向后兼容。
?? 業務規則強加的限制。
?? 硬件限制，例如定時需求、內存或處理器限制、大小、重量、材料或成本
?? 對現有產品進行改進時，要遒循的現存用戶界面的一些約定。
?? 標準數據交換格式，例如XML
）
?
2.6 用戶文檔
（列出將要交付的用戶文檔組件以及可執行軟件，可以包括用戶手冊、聯機幫助和教程。確定所有要求的文檔交付格式、標準或工具。）
3、系統功能需求
? 3.1 系統功能a
3.a.1 描述和優先級
3.a.2 請求響應序列
3.a.3 功能性需求
4、外部接口需求
（外部接口需求指定了系統或組件必須與其進行接口的硬件、軟件或數據庫元素）
4.1 用戶界面
? ?(描述系統所需的每個用戶界面的邏輯特征。可能包括下面這些條目：
?? 對圖形用戶界面(GUI)標準的引用或者將要采用的產品系列的樣式指南。
?? 有關字體、圖標、按鈕標簽、圖像、顔色選擇方案、域的Tab順序、常用控件等的標準
?? 屏幕布局或解決方案的約朿。
?? 每個屏幕中將出現的標準按鈕、功能或導航鏈接，例如，幫助按鈕。
?? 快捷鍵。
?? 消息顯示約定。
?? 便于軟件定位的布局標準。
?? 滿足視力有問題的用戶的要求。
?
應該將用戶界面的設計細節，例如特定對話框的布局，寫入單獨的用戶界面規格說明中，而不能寫入軟件需求規格說明中。應該將屏幕模型寫入軟件需求規格說明中，以便與需求的另一個視圖進行交流，這樣做是有益的，但要指明模型并不是所要提交的屏幕設計。如果軟件需求規格說明描述的是對一個己有系統的改進，那么將實際將要實現的屏幕畫面寫入軟件需求規格說明中，有時也是有意義的。開發人員己經被現有系統的當前現實所限制，因此，預先了解要修改的屏幕(也可能是新的屏幕)的精確外觀也是應該的。
)
4.2 硬件接口
（描述系統中軟件和硬件組件之間每一接口的特征。這種描述可能包括支持的設備類
型、軟件和硬件之間的數據和控制交互以及所用的通信協議等。）
?
4.3 軟件接口
（描述該產品與其他軟件組件(由名稱和版本來識別)之間的連接。這些組件包括數據庫、操作系統、工具、庫和集成的商業組件等。聲明在軟件組件之間交換消息、數據和控制項的目的，描述外部軟件組件所需的服務，以及組件間通信的本質。確定將在軟件組件之間共享的數據。如果必須用一種特殊的方式來實現數據共享機制，例如一個全局數據區，那么就必須把它定義為一種實現上的約束。）
?
4.4 通信接口
（描述產品將使用的所有通信功能的需求，包括電子郵件、Web瀏覽器、網絡通信協
議和電子表格等。定義所有相關的消息格式，規定通信安全或加密問題、數據傳輸速率
和同步通信機制等。）
5、其他非功能性需求
5.1 性能需求
（聲明各種系統操作特定的性能需求，并解釋其原理以指導開發人員作出合理的設計選擇。
例如，如果對數據庫響應時間要求很嚴格，那么設計人員就會在多個地理位置放多個鏡像數據庫，或者是設計非規范化關系數據庫表，以便更快速地響應査詢請求。指定每秒鐘支持處理的交易量、響應時間、運算精度和實時系統的定時關系。還應該指定內存和磁盤空問需求，并發的用戶負載，或者數據庫表中所能存儲的最大行數。如果不同的功能性需求或特征具有不同的性能需求，那么比較合適的做法是使用其相應的功能性需求指定性能指標，而不要將它們都集中在這一部分中。
應當盡可能的量化性能需求。
）
?
5.2 防護性需求
?
5.3 安全性需求
（
指定與安全性、完整性或保密性問題相關的所有需求，這些問題影響對產品的訪問、
使用以及產品所創建或使用的數據的保護。安全性需求一般來源于業務規則，因此要確
定產品必須遵守的所有安全或保密策略或規則。另一種方法是，也可以在完整性質量屬
性中聲明這些需求。下面是安全性需求的兩個范例：
?? SE-1每個用戶在第1次成功登錄后，必須立即更改他最初的登錄密碼。最初
的登錄密碼不能重用。
?? SE-2如果門鎖系統成功地讀到安全性標記，那么門鎖將保持打開狀態8.0秒
）
5.4 軟件質量屬性
?
6 其他需求
（
定義在此軟件需求規格說明中其他部分未出現的所有其他需求，例如國際化需求
(貨幣、日期格式、語言、國際規則以及文化和政治上的問題)及法律上的需求。還可以
添加操作、管理和維護等幾部分來描述產品的安裝、配置、啟動和關閉、修復和容錯，
以及登錄和監控操作等方面的需求。應在模板中加入與項目相關的任何新的需求部分。
如果不需要添加任何其他需求，就省略這一部分。
）
?
?
附錄A：術語表
（定義讀者霜要了解的所有專門術語(包括縮略詞)，以便他們能夠正確地理解軟件需
求規格說明。拼寫出每一個縮略詞的全稱并給出其定義，還要考慮生成一個跨越多個項
目的企業級術語表，然后在每個軟件需求規格說明中只定義單個項目專用的術語。）
附錄B：分析模型
（這一部分是可選的，它包括或指向相關的分析模型，例如：數據流圖、類圖、狀態
轉換圖實體一關系圖
）
附錄C：待確定問題清單
（
這一部分列出了有待于解決的需求問題。這些問題包括標記為“待確定”（ to?? be
determined ，TBD)的需求、懸而未決的決策、所需要的信息以及有待解決的沖突等。這
一部分并不是軟件需求規格說明所必需的，但有些組織總是在軟件需求規格說明中附上
一張“待確定”問題的列表。我們要主動地管理這些問題直到解決，否則這些問題會成
為我們及時將高廣量的軟件需求規格說明納入基線的絆腳石。
?
）
總結
以上是生活随笔為你收集整理的整理了个软件需求规格说明书模板的全部內容，希望文章能夠幫你解決所遇到的問題。
