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

1、北京中科金財科技股份有限公司 軟件需求規(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包結(jié)構(gòu)模型/模塊關系模型63.2用例包1（采用用例模型）63.2.1用例模型圖63.2.2主要信息63.2.3用例173.3特性1（不采用用例模型）83.3.1<需求N>84非功能性需求114.1性能需求114.1.1性能需求1114.2可靠性需求114.2.1可靠性需求1114.3安全需求11

2、4.3.1安全需求1114.4其他需求114.4.1其他需求1115外部接口需求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附錄161 簡介提出對軟件需求規(guī)格說明書的縱覽，幫助讀者理解文檔如何編寫并且如何閱讀和解釋。1.1 編寫目的對產(chǎn)品（也可能是項目，但是我們統(tǒng)稱為產(chǎn)品）進行定義，在該文檔中詳盡說明這個產(chǎn)品的需求，包括修正或發(fā)行版本號。如果這個產(chǎn)品需求規(guī)格說明書只與整個系統(tǒng)的一部分有關

3、，那么只定義文檔中說明的部分或子系統(tǒng)。舉例：本文的目的是為了清晰地說明產(chǎn)品要實現(xiàn)的所有功能，產(chǎn)品的設計、編碼和測試都要以本文的內(nèi)容為基礎。同時，本文確定的內(nèi)容還作為產(chǎn)品驗收的基準?？蛻?、項目組要共同協(xié)商本文內(nèi)容。1.2 預期的讀者和閱讀建議列舉本文檔所針對的不同讀者，例如開發(fā)人員、市場人員、測試人員、客戶等。描述文檔中剩余部分的內(nèi)容及其組織結(jié)構(gòu)，提出最適合每一類型讀者閱讀文檔的建議。1.3 術語、定義、符號及縮略語按字母或拼音順序列出所有的定義和縮略語，以便讀者可以正確地理解產(chǎn)品需求規(guī)格說明書，包括詞頭和縮寫。注意：只需要列出對理解本文有用的術語。舉例：PRS：Product Requirem

4、ent Specification（產(chǎn)品需求規(guī)格說明書）。 1.4 參考資料列舉編寫軟件需求規(guī)格說明書時所參考的資料或其它來源?？赡馨ㄓ脩艚缑骘L格指導、合同、標準、系統(tǒng)需求規(guī)格說明書、用戶需求、相關產(chǎn)品的產(chǎn)品需求規(guī)格說明書。這里應該給出參考資料詳細的信息，包括標題名稱、作者、版本號、日期、出版單位或資料來源，以方便讀者查閱這些文獻。2 綜合描述這一部分概述了正在定義的產(chǎn)品以及它所運行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設和依賴。2.1 項目背景描述產(chǎn)品需求規(guī)格說明書中所定義的產(chǎn)品的背景和起源。說明該產(chǎn)品是否是產(chǎn)品系列中的下一個成員，是否是成熟產(chǎn)品所改進的下一代產(chǎn)品、是否是現(xiàn)有應用程序的替代

5、品，或者是否是一個全新的產(chǎn)品。2.2 產(chǎn)品功能概述產(chǎn)品必須具備的主要功能，本文檔在第三章對產(chǎn)品功能進行詳細描述，在此僅作概括總結(jié)，重點在系統(tǒng)層次上描述產(chǎn)品的功能需求和功能分類，還可能包括保證產(chǎn)品與外部組件正確連接的需求?？梢允褂昧斜淼姆椒ńo出，也可使用圖形表示主要的需求分組以及它們之間的聯(lián)系，例如數(shù)據(jù)流程圖的頂層圖或類圖。以使描述更加有效。2.3 應用模型運用場合、環(huán)境、組網(wǎng)、應用舉例。繪制產(chǎn)品的結(jié)構(gòu)圖示、與系統(tǒng)相交互的外部對象之間的關系。如果該部分內(nèi)容與市場需求分析報告中“產(chǎn)品的組網(wǎng)與應用分析”內(nèi)容完全相同，請直接引用（例如：請參見市場需求分析報告中“產(chǎn)品的組網(wǎng)與應用分析”）。2.4 運行環(huán)

6、境描述產(chǎn)品的運行環(huán)境，包括為支持產(chǎn)品工作所需的其它的組件或者與其共存的產(chǎn)品；對于軟件產(chǎn)品還應包括硬件平臺、操作系統(tǒng)和版本、必須安裝的軟件部件和其他應用軟件等。2.5 假設和依賴列出所有會影響需求實現(xiàn)的假設因素（相對于已知的事實而言），可能包括打算要用的商業(yè)組件或有關開發(fā)或運行環(huán)境的問題。例如，本項目產(chǎn)品計劃要使用某些第三方軟件產(chǎn)品或商業(yè)軟件產(chǎn)品，雖然目前還未得到這些軟件，但我們可以假設這些軟件一定能夠得到。如果這些假設不正確、或發(fā)生改變，會影響項目的開發(fā)，因此，這些假設往往又是一種風險。此外，確定項目對外部因素存在的依賴。例如，如果項目的開發(fā)或項目產(chǎn)品的使用要依靠其它外部因素，比如與其它產(chǎn)品共

7、用的軟件包、準備重用的軟件構(gòu)件等，也要在此說明。3 功能需求本章將詳細解釋產(chǎn)品所有的功能需求。功能需求是根據(jù)系統(tǒng)特性即產(chǎn)品所提供的主要服務來組織的。你可能更喜歡通過用例、運行模式、用戶類、對象類或功能等級來組織這部分內(nèi)容，你還可以使用它們的組合?？傊?，你必須選擇一種使讀者易于理解預期產(chǎn)出的組織方案。如果使用傳統(tǒng)的需求分析方法，本章的每一節(jié)描述一個功能需求，每個功能需求又從編號、名稱、優(yōu)先級、輸入、處理、輸出、驗收準則7項來說明。如果使用UML模型描述需求分析結(jié)果，本章的每一節(jié)采用“使用用例”描述一個功能需求，并在此說明參考的“使用用例”文件名；如果你采用模型工具繪制用例視圖，你應在此注明所用工

8、具的名稱、版本等信息。本章中所列出的需求，要求細化到如下程度：（1）設計人員可以依據(jù)該需求設計并實現(xiàn)系統(tǒng)；（2）系統(tǒng)測試人員可以依據(jù)該需求編寫測案并對系統(tǒng)進行驗證。3.1 包結(jié)構(gòu)模型/模塊關系模型使用UML模型描述需求分析結(jié)果時，在本節(jié)劃分出系統(tǒng)的包結(jié)構(gòu)，用圖表示出用戶機構(gòu)與本系統(tǒng)各個包之間的關系和本系統(tǒng)各包部分之間的關系。使用傳統(tǒng)的需求分析方法時，在本節(jié)劃分出系統(tǒng)的各功能模塊結(jié)構(gòu)，用圖表示出用戶機構(gòu)與本系統(tǒng)各個功能模塊之間的關系和本系統(tǒng)各功能模塊之間的關系。3.2 用例包1（采用用例模型）3.2.1 用例模型圖3.2.2 主要信息【對于每個包應當說明以下信息：名稱簡要說明該包所擁有的用例列表

9、該包所擁有的角色列表直屬該包的包列表】3.2.3 用例13.2.3.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)生實質(zhì)性影響，但可能會在特定的應用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版本中實現(xiàn)。3.2.3.2

10、 簡要說明【用例的簡要說明應反映用例的角色和目的。在撰寫說明時，應參考用例中所涉及的主角、詞匯表，并根據(jù)需要定義新概念。以下是回收機系統(tǒng)中“回收貯藏物品”用例的簡要說明示例：回收貯藏物品：用戶使用本機器來自動統(tǒng)計所有回收物品（瓶子、罐子以及箱子），并得到一張收據(jù)。收據(jù)將在收銀機處兌現(xiàn)?！?.2.3.3 參與者3.2.3.4 事件流【用例事件流包含用例建模工作所得到的最重要的信息。應該清楚地說明用例的事件流，讓外行也能很容易地理解它。請記住，事件流應該說明系統(tǒng)做什么，而不是說明為了執(zhí)行所需的行為而對系統(tǒng)進行的設計。事件流的兩個主要部分是主事件流和擴展事件流。主事件流應包括在執(zhí)行用例時“通?！睍l(fā)

11、生的事件。擴展事件流包括與正常行為相關的可選或異常特征的行為，同時也包括正常行為的各種變形。您可以將擴展事件流看作是主事件流的“繞行道”，有些擴展事件流將返回到主事件流，而有些將結(jié)束此用例的執(zhí)行?！?.2.3.4.1 主事件流3.2.3.4.2 擴展事件流3.2.3.5 前置條件【前置條件或后置條件所說明的狀態(tài)應該是用戶可以觀察到的狀態(tài)?！坝脩粢呀?jīng)登錄系統(tǒng)”或“用戶已經(jīng)打開文檔”都是可觀察狀態(tài)的示例。前置條件是對用例何時開始的約束。它并不是使用例開始的事件。例如自動柜員機中“提取現(xiàn)金”用例的前置條件為：客戶擁有一張個人專用卡，這張卡正好可以塞進讀卡器，并且該卡已經(jīng)分到一個 PIN 號，還向銀行

12、業(yè)務系統(tǒng)進行了登記?！?.2.3.6 觸發(fā)條件【觸發(fā)條件是說明觸發(fā)用例執(zhí)行的條件。例如“預定客房”用例的觸發(fā)條件是客戶申請預定客房，其前置條件是當前有空的客房。】3.2.3.7 后置條件【例如，自動柜員機中“提取現(xiàn)金”用例的后置條件為：當用例結(jié)束時，所有帳戶和交易日志都已收支平衡，與銀行業(yè)務系統(tǒng)的通信已重新初始化，并且銀行卡已經(jīng)返還給客戶。】3.3 特性1（不采用用例模型）在此對<特性1>進行概要性說明，例如：此模塊中包含實現(xiàn)預付費業(yè)務所需的所有功能。3.3.1 <需求N>本節(jié)的標題<需求N>需以實際的需求名代替。3.3.1.1 編號為需求定義一個唯一的編號

13、，便于需求跟蹤。3.3.1.2 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。3.3.1.3 優(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)生實質(zhì)性影響，但可能會在特定的應用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮

14、在產(chǎn)品的某一版本中實現(xiàn)。3.3.1.4 輸入列出本需求所有的輸入（觸發(fā)條件、輸入?yún)?shù)）。對每項輸入，可能的屬性如下：輸入名說明類型例如：Int、String輸入值的范圍輸入來源格式3.3.1.5 處理描述為了滿足該項功能應進行哪些事務處理?？梢杂梦谋痉绞?、偽指令或流程圖來描述。3.3.1.6 輸出列出本需求所有的輸出（輸出參數(shù)、處理結(jié)果）。對每項輸出，可能的屬性如下：輸出名說明類型輸出值的范圍輸出值的目標格式4 非功能性需求4.1 性能需求4.1.1 性能需求14.1.1.1 編號4.1.1.2 名稱及說明4.1.1.3 優(yōu)先級4.1.1.4 驗收準則4.2 可靠性需求4.2.1 可靠性需求1

15、4.2.1.1 編號4.2.1.2 名稱及說明4.2.1.3 優(yōu)先級4.2.1.4 驗收準則4.3 安全需求4.3.1 安全需求14.3.1.1 編號4.3.1.2 名稱及說明4.3.1.3 優(yōu)先級4.3.1.4 驗收準則4.4 其他需求4.4.1 其他需求14.4.1.1 編號4.4.1.2 名稱及說明4.4.1.3 優(yōu)先級4.4.1.4 驗收準則5 外部接口需求表三：外部接口需求分類表需求類別編號需求名稱優(yōu)先級描述5.1 用戶接口陳述產(chǎn)品中所需要的用戶界面。描述每個用戶界面的邏輯特征。以下是可能要包括的一些特征：l 將要采用的圖形用戶界面標準或整個產(chǎn)品系列的風格；l 屏幕布局；l 將出現(xiàn)在

16、每個屏幕的標準按鈕（如幫助）、功能或?qū)Ш芥溄?；l 鍵盤快捷鍵；l 錯誤信息顯示標準。如果必要，用戶接口需求的細節(jié)可在獨立的用戶接口規(guī)格文件中描述。5.1.1 <用戶接口需求M>本節(jié)的標題需以實際的需求名代替。5.1.1.1 編號為需求定義一個唯一的編號，便于需求跟蹤。5.1.1.2 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。5.1.1.3 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：l 高：關鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的需求必須在本次項目開發(fā)中實現(xiàn)。l 中：重要的功能，必選，不能實現(xiàn)可能會影

17、響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先級的需求都應該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個版本中實現(xiàn)。l 低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在特定的應用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版本中實現(xiàn)。5.1.1.4 驗收準則說明用于驗證滿足需求的驗收準則。5.2 硬件接口描述系統(tǒng)中軟件和硬件每一接口的特征，可能包括軟件所支持的設備類型、軟硬件之間交流的數(shù)據(jù)和控制信息的性質(zhì)、通訊協(xié)議等。5.2.1 <硬件接口需求M>本節(jié)的標題需以實際的需求名代替。5.2.1.1 編號為需求定義一個唯一

18、的編號，便于需求跟蹤。5.2.1.2 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。5.2.1.3 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：l 高：關鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的需求必須在本次項目開發(fā)中實現(xiàn)。l 中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先級的需求都應該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個版本中實現(xiàn)。l 低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在特定的應用場合增加產(chǎn)品的賣點，在時間、資源允許

19、的情況下，可以考慮在產(chǎn)品的某一版本中實現(xiàn)。5.2.1.4 驗收準則說明用于驗證滿足需求的驗收準則。5.3 軟件接口說明本產(chǎn)品與其它外部組件（包括數(shù)據(jù)庫、操作系統(tǒng)、工具、運行庫、集成的商業(yè)部件等，要指明它們的名字和版本）的連接。明確并描述在軟件組件之間交換數(shù)據(jù)或消息的目的。描述所需要的服務以及內(nèi)部組件通信的性質(zhì)。確定將在組件之間共享的數(shù)據(jù)。如果必須用一種特殊的方法來實現(xiàn)數(shù)據(jù)共享機制，例如在多任務操作系統(tǒng)中的一個全局數(shù)據(jù)區(qū)，那么就必須把它定義為一種實現(xiàn)上的限制。5.3.1 <軟件接口需求M>本節(jié)的標題需以實際的需求名代替。5.3.1.1 編號為需求定義一個唯一的編號，便于需求跟蹤。5.3.1.2 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。5.3.1.3 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：l 高：關鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的需求必須在本次項目開發(fā)中實現(xiàn)。l 中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先級的需求都應該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個版本中實現(xiàn)。l 低：有用的功能或