1、機構圖標 項目名稱 產品需求規格說明書文件狀態： 草稿 正式發布 正在修改文件標識：Company-Project-RD-PRS當前版本：X.Y作 者：完成日期：Year-Month-Day機構公開信息版 本 歷 史版本/狀態作者參與者起止日期備注 目 錄 0. 文檔介紹40.1 文檔目的40.2 文檔范圍40.3 讀者對象40.4 參考文檔40.5 術語與縮寫解釋41. 產品介紹52. 產品面向的用戶群體53. 產品應當遵循的標準或規范54. 產品范圍55. 產品中的角色56. 產品的功能性需求66.0 功能性需求分類66.m Feature M66.m.n Function M.N67.

2、產品的非功能性需求77.1 用戶界面需求77.2 軟硬件環境需求77.3 產品質量需求77.n 其他需求7附錄A：需求建模與分析報告8A.1 需求模型18A.n 需求模型N8附錄B：需求確認90. 文檔介紹0.1 文檔目的0.2 文檔范圍0.3 讀者對象0.4 參考文檔提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：標識符 作者，文獻名稱，出版單位（或歸屬單位），日期例如：SPP-PROC-PP SEPG，需求開發規范，機構名稱，日期0.5 術語與縮寫解釋縮寫、術語解 釋1. 產品介紹提示：（1）說明產品是什么，什么用途。（2）介紹產品的開發背景。2. 產品面向的用戶群體提示：

3、（1）描述本產品面向的用戶（客戶、最終用戶）的特征，（2）說明本產品將給他們帶來什么好處？他們選擇本產品的可能性有多大？3. 產品應當遵循的標準或規范提示：闡述本產品應當遵循什么標準、規范或業務規則（Business Rules），違反標準、規范或業務規則的產品通常不太可能被接受。4. 產品范圍提示：闡述本產品“適用的領域”和“不適用的領域”，本產品“應當包含的內容”和“不包含的內容”。說清楚產品范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發精力集中在產品范圍之內，少干吃力不討好的事情；（3）有助于控制需求的變更。5. 產品中的角色提示：闡述本產品的各種角色及其職責。

4、各種角色的具體行為將在功能性需求中描述。角色名稱職責描述6. 產品的功能性需求6.0 功能性需求分類提示：將功能性需求先粗分再細分，下表中的 Feature A, Function A.1等符號應當被替換成有含義的名稱。功能類別子功能Feature AFunction A.1Function A.2Feature BFunction B.1Function B.26.m Feature M提示：此處寫一些承上啟下的文字。6.m.n Function M.N名稱、標識符功能描述優先級輸入操作序列輸出補充說明7. 產品的非功能性需求7.1 用戶界面需求需求名稱詳細要求7.2 軟硬件環境需求需求名稱

5、詳細要求7.3 產品質量需求主要質量屬性詳細要求正確性健壯性可靠性性能，效率易用性清晰性安全性可擴展性兼容性可移植性7.n 其他需求附錄A：需求建模與分析報告建議用Rational Rose對產品需求進行建模與分析。A.1 需求模型1A.n 需求模型N附錄B：需求確認提示：需求確認規程請參見SPP-PROC-RM，主要分兩步：（1）需求評審，（2）需求承諾。對需求的評審應當采用“正式技術評審方式”，將產生一份“需求評審報告”，規程請參見SPP-PROC-TR。在獲取責任人（Stakeholders）對需求的承諾之前，該產品需求規格說明書必須先通過需求評審。需求評審報告摘要需求文檔輸入名稱，標識符，版本，作者，完成日期，需求評審報告輸入名稱，標識符，評審日期，評審結論 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。 工作成果基本合格，需要作少量的修改，之后通過審核即可。 工作成果不合格，需要作比較大