需求規(guī)格說明書模板樣本

軟件需求規(guī)格闡明書模版目錄1 簡介 41.1 編寫目 41.2 預期讀者和閱讀建議 41.3 術語、定義、符號及縮略語 41.4 參照資料 42 綜合描述 42.1 項目背景 52.2 產(chǎn)品功能 52.3 應用模型 52.4 運營環(huán)境 52.5 假設和依賴 53 功能需求 63.1 包構造模型/模塊關系模型 63.2 用例包1（采用用例模型） 63.2.1 用例模型圖 63.2.2 重要信息 63.2.3 用例1 73.3 特性1（不采用用例模型） 83.3.1 <需求N> 84 非功能性需求 114.1 性能需求 114.1.1 性能需求1 114.2 可靠性需求 114.2.1 可靠性需求1 114.3 安全需求 114.3.1 安全需求1 114.4 其她需求 114.4.1 其她需求1 115 外部接口需求 125.1 顧客接口 125.1.1 <顧客接口需求M> 125.2 硬件接口 135.2.1 <硬件接口需求M> 135.3 軟件接口 145.3.1 <軟件接口需求M> 145.4 通信接口 155.4.1 <通信接口需求M> 156 附錄 16

簡介[提出對《軟件需求規(guī)格闡明書》縱覽，協(xié)助讀者理解文檔如何編寫并且如何閱讀和解釋。]編寫目[對產(chǎn)品（也也許是項目，但是咱們統(tǒng)稱為產(chǎn)品）進行定義，在該文檔中詳盡闡明這個產(chǎn)品需求，涉及修正或發(fā)行版本號。如果這個《產(chǎn)品需求規(guī)格闡明書》只與整個系統(tǒng)一某些關于，那么只定義文檔中闡明某些或子系統(tǒng)。舉例：本文目是為了清晰地闡明產(chǎn)品要實現(xiàn)所有功能，產(chǎn)品設計、編碼和測試都要以本文內容為基本。同步，本文擬定內容還作為產(chǎn)品驗收基準?？蛻?、項目組要共同協(xié)商本文內容。]預期讀者和閱讀建議[列舉本文檔所針對不同讀者，例如開發(fā)人員、市場人員、測試人員、客戶等。描述文檔中剩余某些內容及其組織構造，提出最適合每一類型讀者閱讀文檔建議。]術語、定義、符號及縮略語[按字母或拼音順序列出所有定義和縮略語，以便讀者可以對的地理解《產(chǎn)品需求規(guī)格闡明書》，涉及詞頭和縮寫。注意：只需要列出對理解本文有用術語。舉例：PRS：ProductRequirementSpecification（產(chǎn)品需求規(guī)格闡明書）。]參照資料[列舉編寫《軟件需求規(guī)格闡明書》時所參照資料或其他來源。也許涉及顧客界面風格指引、合同、原則、系統(tǒng)需求規(guī)格闡明書、顧客需求、有關產(chǎn)品產(chǎn)品需求規(guī)格闡明書。這里應當給出參照資料詳細信息，涉及標題名稱、作者、版本號、日期、出版單位或資料來源，以以便讀者查閱這些文獻。]綜合描述[這一某些概述了正在定義產(chǎn)品以及它所運營環(huán)境、使用產(chǎn)品顧客和已知限制、假設和依賴。]項目背景[描述產(chǎn)品需求規(guī)格闡明書中所定義產(chǎn)品背景和來源。闡明該產(chǎn)品與否是產(chǎn)品系列中下一種成員，與否是成熟產(chǎn)品所改進下一代產(chǎn)品、與否是既有應用程序代替品，或者與否是一種全新產(chǎn)品。]產(chǎn)品功能[概述產(chǎn)品必要具備重要功能，本文檔在第三章對產(chǎn)品功能進行詳細描述，在此僅作概括總結，重點在系統(tǒng)層次上描述產(chǎn)品功能需求和功能分類，還也許涉及保證產(chǎn)品與外部組件對的連接需求?？梢允褂昧斜磙k法給出，也可使用圖形表達重要需求分組以及它們之間聯(lián)系，例如數(shù)據(jù)流程圖頂層圖或類圖。以使描述更加有效。]應用模型[運用場合、環(huán)境、組網(wǎng)、應用舉例。繪制產(chǎn)品構造圖示、與系統(tǒng)相交互外部對象之間關系。如果該某些內容與《市場需求分析報告》中“產(chǎn)品組網(wǎng)與應用分析”內容完全相似，請直接引用（例如：請參見《市場需求分析報告》中“產(chǎn)品組網(wǎng)與應用分析”）。]運營環(huán)境[描述產(chǎn)品運營環(huán)境，涉及為支持產(chǎn)品工作所需其他組件或者與其共存產(chǎn)品；對于軟件產(chǎn)品還應涉及硬件平臺、操作系統(tǒng)和版本、必要安裝軟件部件和其她應用軟件等。]假設和依賴[列出所有會影響需求實現(xiàn)假設因素（相對于已知事實而言），也許涉及打算要用商業(yè)組件或關于開發(fā)或運營環(huán)境問題。例如，本項目產(chǎn)品籌劃要使用某些第三方軟件產(chǎn)品或商業(yè)軟件產(chǎn)品，雖然當前尚未得到這些軟件，但咱們可以假設這些軟件一定可以得到。如果這些假設不對的、或發(fā)生變化，會影響項目開發(fā)，因而，這些假設往往又是一種風險。此外，擬定項目對外部因素存在依賴。例如，如果項目開發(fā)或項目產(chǎn)品使用要依托其他外部因素，例如與其他產(chǎn)品共用軟件包、準備重用軟件構件等，也要在此闡明。]功能需求[本章將詳細解釋產(chǎn)品所有功能需求。功能需求是依照系統(tǒng)特性即產(chǎn)品所提供重要服務來組織。你也許更喜歡通過用例、運營模式、顧客類、對象類或功能級別來組織這某些內容，你還可以使用它們組合。總之，你必要選取一種使讀者易于理解預期產(chǎn)出組織方案。如果使用老式需求分析辦法，本章每一節(jié)描述一種功能需求，每個功能需求又從編號、名稱、優(yōu)先級、輸入、解決、輸出、驗收準則7項來闡明。如果使用UML模型描述需求分析成果，本章每一節(jié)采用“使用用例”描述一種功能需求，并在此闡明參照“使用用例”文獻名；如果你采用模型工具繪制用例視圖，你應在此注明所用工具名稱、版本等信息。本章中所列出需求，規(guī)定細化到如下限度：（1）設計人員可以根據(jù)該需求設計并實現(xiàn)系統(tǒng)；（2）系統(tǒng)測試人員可以根據(jù)該需求編寫測案并對系統(tǒng)進行驗證。]包構造模型/模塊關系模型[使用UML模型描述需求分析成果時，在本節(jié)劃分出系統(tǒng)包構造，用圖表達出顧客機構與本系統(tǒng)各個包之間關系和本系統(tǒng)各包某些之間關系。使用老式需求分析辦法時，在本節(jié)劃分出系統(tǒng)各功能模塊構造，用圖表達出顧客機構與本系統(tǒng)各個功能模塊之間關系和本系統(tǒng)各功能模塊之間關系。]用例包1（采用用例模型）用例模型圖重要信息【對于每個包應當闡明如下信息：名稱簡要闡明該包所擁有用例列表該包所擁有角色列表直屬該包包列表】用例1優(yōu)先級[該需求優(yōu)先級，按高、中、低優(yōu)先級分類。對高、中、低解釋如下：高：核心功能特性，必選，不能實現(xiàn)意味著無法滿足客戶需求。所有“高”優(yōu)先級需求必要在本次項目開發(fā)中實現(xiàn)。中：重要功能，必選，不能實現(xiàn)也許會影響產(chǎn)品銷售和客戶滿意度。所有“中”優(yōu)先級需求都應當作為產(chǎn)品功能點，但在時間、資源壓力下，可以考慮在產(chǎn)品下一種版本中實現(xiàn)。低：有用功能或性能提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質性影響，但也許會在特定應用場合增長產(chǎn)品賣點，在時間、資源容許狀況下，可以考慮在產(chǎn)品某一版本中實現(xiàn)。]簡要闡明【用例簡要闡明應反映用例角色和目。在撰寫闡明時，應參照用例中所涉及主角、詞匯表，并依照需要定義新概念。如下是回收機系統(tǒng)中“回收貯藏物品”用例簡要闡明示例：回收貯藏物品：顧客使用本機器來自動記錄所有回收物品（瓶子、罐子以及箱子），并得到一張收據(jù)。收據(jù)將在收銀機處兌現(xiàn)。】參加者事件流【用例事件流包括用例建模工作所得到最重要信息。應當清晰地闡明用例事件流，讓外行也能很容易地理解它。請記住，事件流應當闡明系統(tǒng)做什么，而不是闡明為了執(zhí)行所需行為而對系統(tǒng)進行設計。事件流兩個重要某些是主事件流和擴展事件流。主事件流應涉及在執(zhí)行用例時“普通”會發(fā)生事件。擴展事件流涉及與正常行為有關可選或異常特性行為，同步也涉及正常行為各種變形。您可以將擴展事件流看作是主事件流“繞行道”，有些擴展事件流將返回到主事件流，而有些將結束此用例執(zhí)行?！恐魇录鲾U展事件流前置條件【前置條件或后置條件所闡明狀態(tài)應當是顧客可以觀測到狀態(tài)?！邦櫩鸵呀?jīng)登錄系統(tǒng)”或“顧客已經(jīng)打開文檔”都是可觀測狀態(tài)示例。前置條件是對用例何時開始約束。它并不是使用例開始事件。例如自動柜員機中“提取鈔票”用例前置條件為：客戶擁有一張個人專用卡，這張卡正好可以塞進讀卡器，并且該卡已經(jīng)分到一種PIN號，還向銀行業(yè)務系統(tǒng)進行了登記?！坑|發(fā)條件【觸發(fā)條件是闡明觸發(fā)用例執(zhí)行條件。例如“預定客房”用例觸發(fā)條件是客戶申請預定客房，其前置條件是當前有空客房?！亢笾脳l件【例如，自動柜員機中“提取鈔票”用例后置條件為：當用例結束時，所有帳戶和交易日記都已收支平衡，與銀行業(yè)務系統(tǒng)通信已重新初始化，并且銀行卡已經(jīng)返還給客戶?！刻匦?（不采用用例模型）[在此對<特性1>進行概要性闡明，例如：此模塊中包括實現(xiàn)預付費業(yè)務所需所有功能。]<需求N>[本節(jié)標題<需求N>需以實際需求名代替。]編號[為需求定義一種唯一編號，便于需求跟蹤。]名稱及闡明[需求名稱，如果需要可以在此對需求內容作簡要描述。]優(yōu)先級[該需求優(yōu)先級，按高、中、低優(yōu)先級分類。對高、中、低解釋如下：高：核心功能特性，必選，不能實現(xiàn)意味著無法滿足客戶需求。所有“高”優(yōu)先級需求必要在本次項目開發(fā)中實現(xiàn)。中：重要功能，必選，不能實現(xiàn)也許會影響產(chǎn)品銷售和客戶滿意度。所有“中”優(yōu)先級需求都應當作為產(chǎn)品功能點，但在時間、資源壓力下，可以考慮在產(chǎn)品下一種版本中實現(xiàn)。低：有用功能或性能提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質性影響，但也許會在特定應用場合增長產(chǎn)品賣點，在時間、資源容許狀況下，可以考慮在產(chǎn)品某一版本中實現(xiàn)。]輸入[列出本需求所有輸入（觸發(fā)條件、輸入?yún)?shù)）。對每項輸入，也許屬性如下：輸入名闡明類型[例如：Int、String]輸入值范疇輸入來源格式]解決[描述為了滿足該項功能應進行哪些事務解決?？梢杂梦谋痉绞?、偽指令或流程圖來描述。]輸出[列出本需求所有輸出（輸出參數(shù)、解決成果）。對每項輸出，也許屬性如下：輸出名闡明類型輸出值范疇輸出值目的格式]非功能性需求性能需求性能需求1編號名稱及闡明優(yōu)先級驗收準則可靠性需求可靠性需求1編號名稱及闡明優(yōu)先級驗收準則安全需求安全需求1編號名稱及闡明優(yōu)先級驗收準則其她需求其她需求1編號名稱及闡明優(yōu)先級驗收準則外部接口需求表三：外部接口需求分類表需求類別編號需求名稱優(yōu)先級描述顧客接口[陳述產(chǎn)品中所需要顧客界面。描述每個顧客界面邏輯特性。如下是也許要涉及某些特性：將要采用圖形顧客界面原則或整個產(chǎn)品系列風格；屏幕布局；將出當前每個屏幕原則按鈕（如協(xié)助）、功能或導航鏈接；鍵盤快捷鍵；錯誤信息顯示原則。如果必要，顧客接口需求細節(jié)可在獨立顧客接口規(guī)格文獻中描述。]<顧客接口需求M>[本節(jié)標題需以實際需求名代替。]編號[為需求定義一種唯一編號，便于需求跟蹤。]名稱及闡明[需求名稱，如果需要可以在此對需求內容作簡要描述。]優(yōu)先級[該需求優(yōu)先級，按高、中、低優(yōu)先級分類。對高、中、低解釋如下：高：核心功能特性，必選，不能實現(xiàn)意味著無法滿足客戶需求。所有“高”優(yōu)先級需求必要在本次項目開發(fā)中實現(xiàn)。中：重要功能，必選，不能實現(xiàn)也許會影響產(chǎn)品銷售和客戶滿意度。所有“中”優(yōu)先級需求都應當作為產(chǎn)品功能點，但在時間、資源壓力下，可以考慮在產(chǎn)品下一種版本中實現(xiàn)。低：有用功能或性能提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質性影響，但也許會在特定應用場合增長產(chǎn)品賣點，在時間、資源容許狀況下，可以考慮在產(chǎn)品某一版本中實現(xiàn)。]驗收準則[闡明用于驗證滿足需求驗收準則。]硬件接口[描述系統(tǒng)中軟件和硬件每一接口特性，也許涉及軟件所支持設備類型、軟硬件之間交流數(shù)據(jù)和控制信息性質、通訊合同等。]<硬件接口需求M>[本節(jié)標題需以實際需求名代替。]編號[為需求定義一種唯一編號，便于需求跟蹤。]名稱及闡明[需求名稱，如果需要可以在此對需求內容作簡要描述。]優(yōu)先級[該需求優(yōu)先級，按高、中、低優(yōu)先級分類。對高、中、低解釋如下：高：核心功能特性，必選，不能實現(xiàn)意味著無法滿足客戶需求。所有“高”優(yōu)先級需求必要在本次項目開發(fā)中實現(xiàn)。中：重要功能，必選，不能實現(xiàn)也許會影響產(chǎn)品銷售和客戶滿意度。所有“中”優(yōu)先級需求都應當作為產(chǎn)品功能點，但在時間、資源壓力下，可以考慮在產(chǎn)品下一種版本中實現(xiàn)。低：有用功能或性能提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質性影響，但也許會在特定應用場合增長產(chǎn)品賣點，在時間、資源容許狀況下，可以考慮在產(chǎn)品某一版本中實現(xiàn)。]驗收準則[闡明用于驗證滿足需求驗收準則。]軟件接口[闡明本產(chǎn)品與其他外部組件（涉及數(shù)據(jù)庫、操作系統(tǒng)、工具、運營庫、集成商業(yè)部件等，要指明它們名字和版本）連接。明確并描述在軟件組件之間互換數(shù)據(jù)或消息目。描述所需要服務以及內部組件通信性質。擬定將在組件之間共享數(shù)據(jù)。如果必要用一種特殊辦法來實現(xiàn)數(shù)據(jù)共享機制，例如在多任務操作系統(tǒng)中一種全局數(shù)據(jù)區(qū)，那么就必要把它定義為一種實現(xiàn)上限制。]<軟件接口需求M>[本節(jié)標題需以實際需求名代替。]編號[為需求定義一種唯一編號，便于需求跟蹤。]名稱及闡明[需求名稱，如果需要可以在此對需求內容作簡要描述。]優(yōu)先級[該需求優(yōu)先級，按高、中、低優(yōu)先級分類。對高、中、低解釋如下：高：核心功能特性，必選，不能實現(xiàn)意味著無法滿足客戶需求。所有“高”優(yōu)先級需求必要在本次項目開發(fā)中實現(xiàn)。中：重要功能，必選，不能實現(xiàn)也許會影響產(chǎn)品銷售和客戶滿意度。所有“中”優(yōu)先級需求都應當作為產(chǎn)品功能點，但在時間、資源壓力下，可以考慮在產(chǎn)品下一種版本中實現(xiàn)。低：有用功能或性能提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質性影響，但也許會在特定應用場合增長產(chǎn)品賣點，在時間、資源容許狀況下，可以考慮在產(chǎn)品某一版本中實現(xiàn)。]驗收準則[闡明用于驗證滿足需求驗收準則。]通信接口[描述與產(chǎn)品所使用通信功能有關需求，例如電子郵件、WEB瀏覽器、網(wǎng)絡通信原則或合同及電子表格等。定義有關信息格式，指明要遵守通訊原則，如FTP，HTTP等。闡明在通訊中安全和加密問題、數(shù)據(jù)傳播速率、同步機制等。]<通信接口需求M>[本節(jié)標題需以實際需求名代替。]編號[為需求定義一種唯一編號，便于需求跟蹤。]