Atlantic System Guild公司所提供的Volere需求過程與軟件需求規格說明書模板則充分利用了現代軟件工程思想與技術，是一個十分實用、完善的SRS模板。陪學網《需求分析課》採用的正是Volere版的需求規格說明書。
1.產品的目標
1.1 該項目工作的用戶問題或背景
對引發開發任務的工作和情況的描述。同時也應描述用戶希望用將要交付的軟件來完成的工作。
該節內容爲該項目提供了合法的理由，你應該考慮用戶的問題是否嚴重，是否應該解決和爲什麼應該解決。
1.2 產品的目標
用一句話或很少的幾句話來說明“我們希望該產品做什麼？”換言之，即開發該產品的真正原因。
項目如果沒有一個表述清晰、易於理解的目標，就會迷失在產品開發的沙漠中。產品必須帶來某種優勢。典型的優勢是產品會增加組織在市場上的價值，減少運作成本，或提供更好的客戶服務。這個優勢應該是可度量的，這樣才能夠讓您確定交付的產品是否達到目標。
2.客戶、顧客和其它風險承擔者
2.1 客戶是爲開發付費的人，並將成爲所交付產品的擁有者
這一項必須給出客戶的姓名，三個以內是合理的。
客戶最終將接受該產品，因此必須對交付的產品滿意。如果你無法找到一個客戶的姓名，那麼也許你就不應該構建該產品。
2.2 顧客是將花錢購買該產品的人
也給出姓名和相關的信息
2.3 其它風險承擔者
其他的一些人或組織的名稱，他們或者受到產品的影響，或影響產品。
經理或項目負責人；業務領域專家；技術人員；系統開發者；市場人員；產品經理；測試和質量保證人員；審查員，諸如安全審查員或審計人員；律師；易用性專家；你所處行業的專業人員。
3.產品的用戶
3.1 產品的用戶
產品的潛在用戶或操作員的列表。針對每種類型的用戶，提供以下信息：
用戶分類用戶工作的任務；主要相關的經驗；技術經驗；其他用戶特徵：包括身體、智力、工作態度、對技術的態度、教育程度、語言技能、年齡、性別等。
用戶是爲了完成工作而與產品交互的人，你瞭解用戶，就越可能提交適合用戶工作方式的產品。
3.2 對用戶設的優先級
在每類用戶後面附上一個優先級，這區別了用戶的重要性和優先地位：
關鍵用戶：對產品的後續成功至關重要；次要用戶：他們使用產品，但對產品的長期成功並無影響；不重要的用戶：不常用、未授權和沒有技能的用戶。
如果認爲某些用戶對產品或組織更重要，那麼應該寫明，因爲它會影響你設計產品的方式。
4.需求限制條件
4.1 解決方案限制條件
此處明確了限制條件，它們規定了解決問題必須採取的方式。您可以認爲它們是指令式的解決方案。仔細描述該解決方案，以及測試是否符合的度量標準。如果可能，您應該解釋使用該解決方案的原因。
換一句話說，就是要求軟件解決方案滿足哪些限制條件！
4.2 實現環境
此處描述產品將被實施的技術環境和物理環境。
該環境也將成爲設計解決方案時的限制條件之一。
4.3 夥伴應用
此處描述那些不屬於產品的一部分，但產品卻又必須與其協作的應用程序。
4.4 COTS
此處描述實現產品需求所必須使用的COTS(商業組件)。
4.5 預期的工作場地環境
此處描述用戶工作和使用該產品的工作場地。此處應該描述任何可能對產品設計產生影響的工作場地特徵。
4.6 開發者構建該產品需要多少時間
任何已知的最後期限，或商業機會的時限，應在此處說明。
4.7 該產品的財務預算是多少
該產品的預算，以金錢的形式或可得資源的形式說明。
5.命名標準和定義
定義項目中使用到的所有術語，包括同義詞。這裏的內容就是一個字典，包括在需求規格說明書中使用的所有名稱的含義。這個字典應該使用你的組織或行業使用的標準名稱。這些名稱也應該反映出在工作領域中當前使用的術語。該字典包括項目中用到的所有名稱。請仔細地選擇名稱，以避免傳達不同的、不期望的含義。爲每個名字寫下簡明扼要的定義，這些定義必須經過相應的風險承擔者同意。
6.相關事實
可能對產品產生影響的外部因素，但不是命令式的需求限制條件。
7.假定
列出開發者所做的假設。
將所有的假設列在此的目的是讓每一個項目成員都意識到這個假設。
8.產品的範圍
8.1 工作的上下文範圍
上下文範圍圖用來表示將要開發的系統、產品與其它系統之間的關係，以確定系統邊界。
8.2 工作切分
一個事件清單，確定系統要響應的所有業務事件。清單包括：
事件名稱輸入和輸出
8.3 產品邊界
你可以使用用例圖(use-case)來確定了用戶與產品之間的邊界。
9.功能性需求與數據需求
9.1 功能性需求
對產品必須執行的動作的描述。
每個功能性需求必須有一個驗收標準。
9.2 數據需求
與產品/系統有密切關係的主題域相關的業務對象、實體、類的說明書。
進行問題域建模，生成相應的類圖。
10.觀感需求
一些與產品的用戶界面相關的需求描述。
11.易用性需求
11.1 易於使用
描述如何構建符合最終用戶期望的產品。
11.2 學習的容易程序
學習使用該產品應該多容易的說明。通常是有學習時間來衡量。
12.性能要求
12.1 速度需求
明確完成特定任務需要的時間，這常常指響應時間。
12.2 安全性的需求
對可能造成人身傷害、財產損失和環境破壞所考慮到的風險進行量化描述。
12.3 精度需求
對產品產生的結果期望的精度進行量化描述。
12.4 可靠性和可用性需求
本節量化產品所需的可靠性。這常常表述爲允許的兩次失敗之間無故障運行時間，或允許的總失敗率。
12.5 容量需求
本節明確處理的吞吐量和產品存儲數據的容量。
13.操作需求
13.1 預期的物理環境
本節明確產品將操作的物理環境，以及這種環境引起的任何特殊需求。
13.2 預期的技術環境
硬件和其它組成新產品操作環境的設備的規範。
13.3 夥伴應用程序
對產品必須與之交互的其它應用程序的描述。
14.可維護性和可移植性需求
14.1 維護該產品需要多容易
對產品作特定修改所需時間的量化描述。
14.2 是否存在一些特殊情況適用於該產品的維護
關於預期的產品發佈週期和發佈將採取的形式的規定。
14.3 可移植性需求
對產品必須支持的其他平臺或環境的描述。
15.安全性需求
15.1 該產品是保密的嗎？
關於該被授權使用該產品，以及在什麼樣的情況下授權等方面的描述。
15.2 文件完整性需求
關於需要的數據庫和其他文件完整性方面的說明。
15.3 審計需求
關於需要的審計檢查方面的說明。
16.文件和政策需求
本節包括針對社會和政策的因素的規格說明，這些因素會影響產品的可接受性。如果你開發的產品是針對外國市場的，可能要特別注意這些需求。
問一下是否產品的目標是你所不熟悉的文化環境，是否其它國家的人或其他類型的組織的人會使用該產品。人們是否有與你的文化不同的習慣、節日、迷信、文化上的社會行爲規範。
17.法律需求
17.1 該產品是否受到某些法律的管制
明確該產品的法律需求的描述。
17.2 是否有一些必須符合的標準
明確適用的標準和參考的詳細標準的描述。
18.Opend問題
對未確定但可能對產品產生重要影響的因素的問題描述。按照需求分析的術語還說，就是TBD（To Be Define）的問題。
19.COTS解決方案
19.1 是否有一些製造好的產品可以購買
應該調查現存產品清單，這些產品可以作爲潛在的解決方案。
19.2 該產品是否可使用製造好的組件
描述可能用於該產品的候選組件，包括採購的和公司自己的產品。列出來源。
19.3 是否有一些我們可以複製的東西
其他相似產品的清單。
20.新問題
20.1 新產品會在當前環境中帶來什麼問題
關於新產品將怎樣影響當前的實現環境的描述。
20.2 新的開發是否將影響某些已實施的系統
關於新產品將怎樣與現存系統協同工作的描述。
20.3 是否我們現有的用戶會受到新開發的敵對性影響
關於現有用戶可能產生的敵對性反應的細節。
20.4 預期的實現環境會存在什麼限制新產品的因素
關於新的自動化技術、新的組織結構方式的任何潛在問題的描述。
20.5 是否新產品會帶來其他問題
確定我們可能不能處理的情況。
21.任務
21.1 爲提交該產品已經做了哪些事
用來開發產品的生命週期和方法的細節。畫一個高層的過程圖展示各項任務和它們之間的接口，這可能是溝通這方面信息的最好辦法。
21.2 開發階段
關於每個開發階段和操作環境中的組件的規格說明。
22.移交
22.1 我們要讓已有數據和過程配合新產品，有什麼特殊要求
一個移交活動的列表，一個實現的時間表。
22.2 爲了新產品，哪些數據必須修改/轉換
數據轉換任務清單，同時確定新產品需要轉換的數據。
23. 風險
23.1 當你開發該產品時，要面對什麼風險
23.2 你制定了怎樣的偶然緊急情況計劃
24.費用
需求的其他費用是你必須投入到產品構建中去的錢或工作量。當需求分析規格說明書完成時，你可以使用一種估算方法來評估費用，然後以構建所需的資金或時間的形式表述出來。
25.用戶文檔
用戶文檔的清單，這些文檔將作爲產品的一部分交付。
26.後續版本的需求
這裏記錄下一些希望今後版本中實現的需求。