精選優質文檔-----傾情為你奉上精選優質文檔-----傾情為你奉上專心---專注---專業專心---專注---專業精選優質文檔-----傾情為你奉上專心---專注---專業軟件需求規格說明書產品發布標識[本模板用于軟件需求開發管理流程中軟件需求規格說明書的編寫。其中包括用方括號括起來并以藍色斜體（樣式=infoblue）顯示的文本，它們用于向作者提供指導，在發布此文檔之前應該將其刪除。按此樣式輸入的段落將被自動設置為普通樣式（樣式=正文）。一般說來，一個產品需求對應一份軟件需求，在軟件需求中也可以分成多個分冊。此時本文檔可命名為“軟件需求規格說明書_產品標識_XXX分冊”。][軟件需求規格說明書的定義：詳細描述系統或者子系統的范圍、邊界、用戶界面、外部行為等。此文檔用來讓讀者了解系統或者子系統的外部黑盒概念，并指導《高層設計》、《測試案例》以及后續開發，以及作為系統測試的依據，指導系統測試案例的開發。[當某一章/節沒有內容時，必須注明N/A，同時標注理由。例如：本章/節內容無需考慮。特別說明：當某章/節內容參見其它文檔時，不能注明N/A，而應該寫明參見某文檔的具體章節。]]文檔版本號：文檔編號：文檔密級：保密歸屬部門/項目：產品名：子系統名：編寫人：編寫日期：kkfun技術（深圳）有限公司版權所有內部資料注意保密修訂記錄：修訂版本號修訂人修訂日期修訂描述V1.0AXXX2004-5-8創建初稿V1.0BBBB2006-4-21根據適應性修訂

目錄TOC\o"1-6"\h\z

簡介[本章應提供整個系統或者子系統的概述。它應包括此系統或者子系統的目的、范圍、定義、首字母縮寫詞、縮略語、參考資料以及依賴和假設。][注：軟件需求規格說明書完整地記錄本系統或者子系統的需求。]目的[本節應描述此文檔的目的。本說明書是整個軟件開發的依據，它對以后階段的工作起指導作用。本文也是項目完成后系統驗收的依據。同時本說明書還是《用戶手冊》和《測試計劃》的編寫依據。]范圍[簡要說明此產品需求規格說明書文檔的范圍、它的相關產品，以及受到此文檔影響的任何其他事物。本節應提供此軟件需求規格說明書所涉及的軟件及其目的的簡短描述，包括利益和目標。把軟件與企業目標或業務策略相聯系。可以參考項目視圖和范圍文檔而不是將其內容復制到這里]預期的讀者和閱讀建議[本節應列舉此軟件需求規格說明書所針對的不同讀者，預期讀者包括但不限于：產品經理、設計人員、開發人員和測試人員，也可供客戶、第三方產品的相關人員閱讀。本文檔組織方式以及閱讀建議：簡介；對文檔目的、范圍等進行說明，并說明文檔的組織方式；整體說明；對軟件進行整體說明；有助于了解軟件的整體概貌。功能性需求，對功能性需求進行詳細說明，包括用例的詳細說明，以指導后續的架構設計、軟件設計工作，并對測試工作提供參考；設計人員和開發人員可以從這個部分得到功能性的需求描述，并據此進行設計、開發工作；測試人員可以據此進行測試案例的設計和測試計劃的制定。界面及接口，描述界面及接口方面的需求；設計人員和開發人員可以從這個部分得到功能特性的界面組織形式，從而更好的理解需求并設計和實現需求。非功能性需求，對軟件的非功能性需求進行描述，以指導后續的架構設計、軟件設計工作，并對測試工作提供參考；設計人員和開發人員在設計、開發過程中應當包含對這些需求的設計、開發工作；測試人員在測試過程中應當包含對這些需求的測試案例及驗證；文檔需求，描述文檔需求；附錄]參考資料[此小節應完整地列出軟件需求規格說明書中所參考的資料或其它資源。這可能包括但并不限于包括用戶界面風格指導、合同、標準、系統需求規格說明、使用實例文檔，或相關產品的軟件需求規格說明。每個文檔應標有標題、報告號（如果適用）、日期和出版單位。列出可以獲取這些參考資料的來源。這些信息可以通過參考附錄或其他文檔來提供。同時，文檔中說明為引用、參考的文檔也應該在這里列出。參考文檔需要按包含、相關的關系分別在下面的小節中列出。]包含文檔[當本文有包含文檔時，需要提供相關的包含文檔列表。包含文檔：作為本軟件需求規格說明書的一部分，是不可分割的組成部分，是讀者閱讀本文檔時必須同時也閱讀的文檔。如當本軟件需求規格說明書非常復雜而有分冊時，則分冊就屬于本文檔的包含文檔。通常情況下，軟件需求規格說明書沒有包含文檔]相關文檔[當本文有相關文檔時，需要提供相關文檔列表。相關文檔：具有關聯關系的文檔。讀者在閱讀本軟件需求規格說明書時如果有必要可以參考閱讀的文檔。如相關產品、子系統或者模塊的產品需求、軟件需求、用戶界面風格指導，相關方請求等相關文檔。]定義、首字母縮寫詞和縮略語[此小節應提供正確理解此軟件需求規格說明書所需的全部術語的定義、首字母縮寫詞和縮略語，以便讀者可以正確地解釋軟件需求說明。可以通過參考項目詞匯表來獲取這些信息。]縮略語/術語全稱說明整體說明[本節應概述正在定義的產品以及它所運行的環境、使用產品的用戶和已知的限制、假設和依賴，說明影響系統及其需求的一般因素。本節并不列出具體的需求，而只是提供在第3節中詳述的各種需求的背景，以使這些需求便于理解。所包括的內容有：? 產品總體效果? 假設與依賴關系]功能簡介[本節應對產品的基本功能做簡介的介紹，包括以下內容：1.本系統的開發意圖、應用目標及作用范圍。2．概略介紹系統所具有的主要功能。可以用列表的方法給出，也可以用圖形表示主要的需求分組以及它們之間的聯系，例如數據流程圖的頂層圖或類圖等。3．說明本系統與其他相關系統的關系，是獨立系統還是一個較大系統的組成部分。可以用表示外部接口和數據流的系統高層次圖，或者方框圖說明。注：可以引用或者參考《產品需求說明書》中相應章節的內容]運行環境1.硬件環境：[如果客戶對于硬件有特殊要求，在此必須按照客戶的要求把硬件環境描述出來；如果客戶對于硬件沒有特別指定，則在此處應詳細列出本軟件運行時所必須的最低硬件配置、推薦硬件配置(如主機、顯示器、外部設備等)以及其它特殊設備。]2.軟件環境：[如果客戶對于軟件環境有特別要求，則在此處應按照客戶的要求把軟件環境描述出來；如果客戶對于軟件環境沒有特別要求，則在此處應詳細列出本軟件運行時所必須的軟件環境，例如操作系統、網絡軟件、數據庫系統以及其它特殊軟件要求。]假設和依賴[列舉出在對軟件需求規格說明中影響需求陳述的假設因素。如果這些假設不正確、不一致或被更改，就會使項目受到影響。本節列舉的假設和依賴可能包括但并不限于以下內容：確定項目對外部因素存在的依賴。例如，如果你打算把其它項目開發的組件集成到系統中，那么你就要依賴那個項目按時提供正確的操作組件。如果這些依賴已經記錄到其它文檔(例如項目計劃)中了，那么在此就可以參考其它文檔。如果本系統的某些功能特性必須依賴于其他系統的功能或者數據，這依賴于與相關方達成一致共識，包括與相關方達成接口契約以及法律方面的協議等，對于一些有爭議或者需要裁剪或者簡化的軟件功能特性，已經獲得用戶的認可。……(其他假設和依賴)注：當產品需求與軟件需求一一對應時，可以直接參考和引用《產品需求規格說明書》“假設與依賴”部分章節的內容；但如果產品需求分解成多個軟件需求時，那么軟件需求應根據實際情況把該部分的假設和依賴進行更細致的描述。]外部約束[本節應說明本軟件在實現時所必須滿足的條件和所受的限制，并給出相應的原因。條件與限制包括但并不限于（主要指軟件環境、硬件環境，市場環境以及政策法規）：必須使用或者避免的特定技術、工具、編程語言和數據庫；企業策略、政府法規或工業標準；例如SOX對于MISC的限制硬件限制，例如定時需求或存儲器限制；經費限制、開發期限；項目對外部因素存在的依賴。例如其它項目開發的軟件。等等]功能性需求[列出產品的特性。特性是為讓用戶獲益而必須具備的高級系統功能。每一項特性都是外部所需的服務，它通常需要一系列輸入來實現預期的結果。此節為設計的系統功能性需求,一般以用例結合自然語言來表達。此節通常按特性來組織，但也可能會有其他適用的組織方式。這一節應包含所有的產品需求，其詳細程度應使架構設計人員和軟件需求設計人員能夠設計出可以滿足這些需求的系統，包括可選流程和異常流程，對具體語義做約束。]特性集名稱一[此節可把《產品需求說明書》章節對應的特性集復制到此處。在此處應描述該特性集有哪些特性。]特性一[此節可把《產品需求說明書》章節對應的特性集復制到此處]功能劃分[此節應從使用用戶的角度描述將特性劃分成相應的功能用例，并給出總體功能結構。對于復雜的系統，還需要對主要子系統中的基本功能進行描述。描述方法包括結構圖、流程圖或對象圖或者表格等等。但應注意此處劃分成的部分并不對應于最終程序實現時的不同功能模塊。本節應包括對應功能特征各部分的內容，包括下列內容：此功能對應的用例圖以及相關的用例說明；此處可以用用例圖來描述：關于用例的編號規則：SFR<編號>。對應用例的編號、簡要說明。此處如用表格來描述，建議采用以下表格：用例編號用例名稱簡要說明]功能點1[此節應對系統的基本功能進行描述，并描述該功能點與內部模塊、外部系統或外部模塊之間的關系a、功能描述b、該功能與內部模塊的關系c、該功能與外部系統或模塊的關系]功能點2[此節應對系統的基本功能進行描述，并描述該功能點與內部模塊、外部系統或外部模塊之間的關系]a、功能描述b、該功能與內部模塊的關系c、該功能與外部系統或模塊的關系]SFR<編號>：XXX功能性需求(二選一)[如果是報表部分功能特征開發，可不選擇本節模板。此處可用圖例簡單描述用例，說明該用例的使用角色，業務實體，以及相關的業務實體等]角色描述[描述角色相關的事項，例如角色的名稱，角色的職責等；角色：誰使用此功能，或者在此功能之外與該功能進行交互的人或事務。角色并不單純指某個人，也可能包括某個其他功能或者構件]用例概述[此處描述用例的相應事項，例如相關的業務實體等。]前置條件[本節應描述本用例發生的前置條件，包括前置用例，輸入條件或者進入用例的約束]SFR<編號>.<場景編號>：場景1[在本節應描述對應用例的正常流，即滿足該用例執行時所有條件時的正常執行過程。]前置條件[在此處應場景1發生的前置條件。]執行步驟[在此處應描述用例正常執行，即滿足該用例執行時所有條件時的正常執行過程以及步驟說明]后置條件[此處應描述在正常流程執行完畢以后的結果，例如輸出，或者是觸發下一個用例。]SFR<編號>.<場景編號>：場景2前置條件[在此處應描述場景2發生的前置條件。]執行步驟[在此處應描述用例執行時，由于某種情況產生的分支流，異常事件也是屬于一種分支流，在此處可以用時序圖/活動圖把該分支流發生的邏輯描述出來。]后置條件[在此處應描述當用例執行時產生的分支流輸出的結果，例如輸出結果，或者是否啟動另外一個用例。]SFR<編號>.<場景編號>：場景3前置條件[在此處應描述場景3發生的前置條件。]執行步驟[在此處應描述用例執行時，由于某種情況產生的分支流，異常事件也是屬于一種分支流，在此處可以用活動圖把該分支流發生的邏輯描述出來。]后置條件[在此處應描述當用例執行時產生的分支流輸出的結果，例如輸出結果，或者是否啟動另外一個用例。]界面示意圖[在本節應出具用例相關的界面示意圖，以指導后續的設計活動開發]SFR<編號>：XXX報表(二選一)[本節主要是針對于面向BI/Report實現的功能性需求描述。本節應包括對應功能特征各部分的內容，包括下列內容：功能描述：描述該功能的作用，以及為客戶帶來的價值。]指標說明[此處應描述該報表有哪些指標。至于指標的定義和算法，可以參考指標相關的技術文檔。]維度說明[此處應描述該報表展現的維度]輸入條件[此處應描述查詢報表時的輸入條件，如有必要，可以提供查詢界面Demo。]樣例說明[注：對于面向BI/Report的功能來說，樣例說明即其界面示意。可以比較準確的描述分析或者報表的界面，以對后續的開發活動做出指導。指標1指標2指標3……]包含內容[此處應說明報表的數據包含的數據內容，例如：CS：包含全網SP以及本地接入全網SP的短信業務匯總數據。PS：包含全網SP以及本省/直轄市的全網本地接入SP、本地SP的短信業務匯總數據。]適用范圍[此處應說明報表的適用范圍，是適用于中央，還是各省市，以及全網等]報表標題[此處應說明報表的標題，如果有分集團和省報表，應分別定義報表的名稱，例如：CS：短信業務各SP分地區分用戶品牌基礎報表PS：短信業務各SP分地區分用戶品牌基礎報表（2空格）（省份）]排序方式[此處應說明報表內容的排序方式，如果有多級排序，應在此說明排序的順序，例如：排序順序排序維度排序方式1SP服務代碼升序排列2企業代碼升序排列3地區代碼升序排列]統計周期[此處應說明報表報表的統計周期，例如：本報表的統計周期為：日，周，月]……[此處如果有其他需要特別說明，可在此增加章節說明。]特性二特性集名稱二界面及接口總體界面效果[本小節概要描述產品特性包含的的用戶界面效果，要求且僅要求提供總體性的說明。]總體接口描述[本小節列舉產品外部接口，要求且僅要求能說明各接口關聯到的相關產品實體間的關系。]非功能性需求[如健壯性、安全保密性、復用性、靈活性、易用性、可維護性、可移植性等。指明不同屬性的相對側重點，例如易用程度優于易學程度，或者可移植優于有效性。健壯性：說明軟件在容錯能力，故障處理能力上需要達到的目標，保證系統穩定可靠；安全保密性：包括用戶身份確認或授權方面的需求，保密性策略，系統所創建或使用的數據的保護等等；復用性：說明本項目是否可以復用已有軟件、是否可為其它系統復用；靈活性：說明在運行環境、與其他軟件的接口以及開發計劃等發生變化時，應具有的適應能力。]獲取來源[列舉非功能性需求的獲取來源。例如：客戶提出的，并已經與其他相關方達成一致的非功能性需求；已經存在的特定類型產品所能參照的業界標準；采用相應的測試工具測試同類產品或原型產品所獲取的數據；同類產品已經存在的參考基準。]適用的標準[列出產品必須符合的所有標準。其中可能包括法律和法規（FDA、UCC）標準、通訊標準（TCP/IP、ISDN）、平臺一致性標準（Windows、Unix等）以及質量和安全標準（UL、ISO、CMM）。]準確性[此節應描述對系統準確性的要求。例如數據準確性]可用性[此節應包括所有影響可用性的需求，參考《架構設計說明書》相關章節。例如，? 指出普通用戶和高級用戶要高效地執行特定操作所需的培訓時間? 指出典型任務的可評測任務次數或根據用戶已知或喜歡的其他系統確定新系統的可用性需求? 指出在符合公認的可用性標準（如IBM的CUA標準和Microsoft的GUI標準）方面的需求]SNR<編號>：可用性需求一[在此給出需求說明。例子：SNR1:系統必須提供良好的用戶界面以方便用戶訂購和使用業務。一個閱讀過FAQ或觀看過使用演示的用戶能夠在10分鐘內完成一次用戶登陸->瀏覽服務信息->定購服務操作。SNR2:同時要求能夠對所有系統級和應用級的錯誤，包括用戶的輸入錯誤都能有友好的出錯提示頁面。參見附錄A提示語定義。]安全性[本節應詳盡陳述與系統安全性、完整性或與私人問題相關的需求，這些問題將會影響到產品的使用和產品所創建或使用的數據的保護。定義用戶身份確認或授權需求。明確產品必須滿足的安全性或保密性策略。][此節應列出將提高所構建系統的安全性的所有需求。具體的要求參見《產品安全性需求》可維護性遵循此方案的策略。建立公司級別的產品安全標準,針對各產品的特性確定安全級別.系統安全:根據各產品安全級別的設定,各產品需要從界面到接口到內核到數據層層設防,以便保證系統不可能被輕易入侵,關鍵數據不可能被輕易破壞和修改.操作安全:根據各產品安全級別的設定,各產品需要建立產品內的審計系統,做到所有高危操作均有據可循,所記錄的信息滿足內部審計和問題排查的要求.操作監控:根據各產品安全級別的設定,各產品需要有相關的監測工具對系統的非正常操作進行監查,一旦發現異常操作及時告警.數據安全:根據各產品安全級別的設定,各產品對核心數據需要有相關的保護措施,做到非正常操作無法破壞和非法修改,并發現有異動可及時告警.維護工具:根據各產品安全級別的設定,將有操作風險的維護工作均全部工具化和界面化,隔離維護者直接接觸系統.數據監控:各產品需要建立相應的業務數據變動異常的標準,開發相關的工具對以上業務數據異常進行監控和分析,以便及時發現SP利用MISC系統漏洞或其他手段違規.算法安全:產品線需要根據各產品的安全級別設定,提高內部管理方法及手段,嚴格控制關鍵代碼和關鍵算法,以便防止關鍵算法和業務流程外泄.針對安全問題的處理,產品線需要建立相關的處理機制并配置相關的人員,以便跟進和產品有關的安全問題的后續處理和問題分析.針對各產品的安全標準和安全規劃,需要在產品設計階段在控制范圍內進行專項討論,并會合相關部門一起確定相關方案和規劃,并安排產品經理制定產品的長期安全目標和短期目標并跟蹤加以實施.產品安全標準設計相關級別為(1-5),根據安全性的要求決定在產品中接口安全,核心邏輯安全,數據安全,審計手段,維護工具,防攻擊手段,安全分析手段,產品部署建議方案中的投入力度.開發相關級別為(1-3),根據安全性的要求決定關鍵算法和關鍵業務邏輯的相關代碼的開發范圍及代碼擴散范圍,并根據相關級別對開發中采用的算法和業務邏輯進行審核檢查.測試相關級別為(1-3),根據安全性的要求決定安全相關PATCH的測試范圍和告知人員.并根據相關級別對產品進行相關的安全性測試.本節如包含多項可維護性需求，可分多小節描述。]可靠性[對系統可靠性的需求應在此處說明，詳盡陳述在軟件使用過程中可能發生的損失、破壞或危害相關的需求。定義必須采取的安全保護或動作，還有那些預防的潛在的危險動作。明確產品必須遵從的安全標準、策略或規則。本節可參考《架構設計說明書》相關章節。以下是一些建議：? 可用性—指出可用時間百分比(xx.xx%)、使用小時數、維護訪問權、降級模式操作等。? 平均故障間隔時間(MTBF)—通常表示為小時數，但也可表示為天數、月數或年數。? 平均修復時間(MTTR)—系統在發生故障后可以暫停運行的時間。? 精確度—指出系統輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。? 最高錯誤或缺陷率—通常表示為每千行代碼的錯誤數目(bugs/KLOC)或每個功能點的錯誤數目(bugs/function-point)。? 錯誤或缺陷率—按照小錯誤、大錯誤和嚴重錯誤來分類。需求中必須對“嚴重”錯誤進行界定，例如：數據完全丟失或完全不能使用系統的某部分功能。]SNR<編號>：可靠性需求一[需求說明。例子：可靠性指系統在規定的時間內及規定的環境條件下，完成規定功能的能力。SNR6:參照現網WAPPortal的運行情況。要求在連續的7天內，在網絡環境正常、與系統相連的MISC，ISMG，SSO，WTBS，SP平臺功能正常的情況下，在系統的額定處理能力之內（額定處理能力參考下文的計算方法），系統發生故障后，從開始處理到系統恢復的時間不能超過30分鐘（按一次計算，超過30min的概率低于20％，從系統正式商用開始統計,此處人員到場的延誤，及分析和處理問題的時間）。SNR7:系統發生異常到系統發出告警的時間的時延不能超過3分鐘。SNR8:健壯性要求：當用戶輸入非法數據時，不能引起系統的運行故障，要保證系統功能95％可用；SNR9:要求在HPRP5470（每臺配置4*550Mhz4GB內存），數據庫服務器配置為HPRP5470（每臺配置4*550Mhz4GB內存）條件下，30天內，當cpu的使用率低于60％，內存使用率低于70％，且系統處理能力不高于額定的處理能力的情況下，系統的外部環境出現問題，如網絡異常、與系統相連的MISC，ISMG，SSO平臺等外部系統發生故障，并在20分鐘內全部恢復正常運行后，M-ZonePortal系統功能在10分鐘內自動恢復次數不能少于總故障次數的80％。]性能[此節應概述系統的性能特征，參考《系統需求說明書》相關章節。其中需包括具體的響應時間。如果可行，按名稱引用相關用例。? 對事務的響應時間（平均、最長）? 吞吐量，例如每秒處理的事務數? 容量，例如系統可以容納的客戶或事務數? 降級模式（當系統以某種形式降級時可接受的運行模式）? 資源利用情況，如內存、磁盤、通信等應盡可能詳細地確定性能需求。可能需要針對每個功能需求或特性分別陳述其性能需求，而不是把它們都集中在一起陳述SNR<編號>：性能需求一【闡述不同的軟件功能對系統性能的需求，并解釋它們的原理以幫助開發人員作出合理的設計選擇。這些性能需求例如：數據精確度：根據實際情況，確定軟件最終輸出數據(包括傳輸中)的數據精確度。時間特性：說明開發的軟件在響應時間、更新處理時間、數據轉換與傳輸時間、運行時間等方面所需達到的時間特性。用戶數：最大用戶數，并發用戶數，以及相互合作的用戶數或者所支持的操作；容量需求，例如存儲器和磁盤容量的需求或者存儲在數據庫中表的最大行數】。例子：SNR10:處理能力在對性能做要求時，我們參考WWWPortal1.6和PDAPortal1.6的性能測試結果。計算方法如下：用戶行為模型：50％的服