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

1、北京中科金財科技股份有限公司 軟件需求規(guī)格說明書模版軟件需求規(guī)格說明書模版 目錄1簡介41.1編寫目的41.2預期的讀者和閱讀建議41.3術語、定義、符號及縮略語41.4參考資料42綜合描述42.1項目背景52.2產品功能52.3應用模型52.4運行環(huán)境52.5假設和依賴53功能需求63.1包結構模型/模塊關系模型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 編寫目的對產品（也可能是項目，但是我們統(tǒng)稱為產品）進行定義，在該文檔中詳盡說明這個產品的需求，包括修正或發(fā)行版本號。如果這個產品需求規(guī)格說明書只與整個系統(tǒng)的一部分有關

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

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

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

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

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

8、具的名稱、版本等信息。本章中所列出的需求，要求細化到如下程度：（1）設計人員可以依據(jù)該需求設計并實現(xiàn)系統(tǒng)；（2）系統(tǒng)測試人員可以依據(jù)該需求編寫測案并對系統(tǒng)進行驗證。3.1 包結構模型/模塊關系模型使用UML模型描述需求分析結果時，在本節(jié)劃分出系統(tǒng)的包結構，用圖表示出用戶機構與本系統(tǒng)各個包之間的關系和本系統(tǒng)各包部分之間的關系。使用傳統(tǒng)的需求分析方法時，在本節(jié)劃分出系統(tǒng)的各功能模塊結構，用圖表示出用戶機構與本系統(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)可能會影響產品的銷售和客戶滿意度。所有“中”優(yōu)先級的需求都應該作為產品的功能點，但在時間、資源的壓力下，可以考慮在產品的下一個版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xià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、生的事件。擴展事件流包括與正常行為相關的可選或異常特征的行為，同時也包括正常行為的各種變形。您可以將擴展事件流看作是主事件流的“繞行道”，有些擴展事件流將返回到主事件流，而有些將結束此用例的執(zhí)行。】3.2.3.4.1 主事件流3.2.3.4.2 擴展事件流3.2.3.5 前置條件【前置條件或后置條件所說明的狀態(tài)應該是用戶可以觀察到的狀態(tài)?！坝脩粢呀浀卿浵到y(tǒng)”或“用戶已經打開文檔”都是可觀察狀態(tài)的示例。前置條件是對用例何時開始的約束。它并不是使用例開始的事件。例如自動柜員機中“提取現(xiàn)金”用例的前置條件為：客戶擁有一張個人專用卡，這張卡正好可以塞進讀卡器，并且該卡已經分到一個 PIN 號，還向銀行

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

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

14、在產品的某一版本中實現(xiàn)。3.3.1.4 輸入列出本需求所有的輸入（觸發(fā)條件、輸入參數(shù)）。對每項輸入，可能的屬性如下：輸入名說明類型例如：Int、String輸入值的范圍輸入來源格式3.3.1.5 處理描述為了滿足該項功能應進行哪些事務處理?？梢杂梦谋痉绞健沃噶罨蛄鞒虉D來描述。3.3.1.6 輸出列出本需求所有的輸出（輸出參數(shù)、處理結果）。對每項輸出，可能的屬性如下：輸出名說明類型輸出值的范圍輸出值的目標格式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 用戶接口陳述產品中所需要的用戶界面。描述每個用戶界面的邏輯特征。以下是可能要包括的一些特征：l 將要采用的圖形用戶界面標準或整個產品系列的風格；l 屏幕布局；l 將出現(xiàn)在

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

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

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

19、的情況下，可以考慮在產品的某一版本中實現(xiàn)。5.2.1.4 驗收準則說明用于驗證滿足需求的驗收準則。5.3 軟件接口說明本產品與其它外部組件（包括數(shù)據(jù)庫、操作系統(tǒng)、工具、運行庫、集成的商業(yè)部件等，要指明它們的名字和版本）的連接。明確并描述在軟件組件之間交換數(shù)據(jù)或消息的目的。描述所需要的服務以及內部組件通信的性質。確定將在組件之間共享的數(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 名稱及說明需求名稱，如果需要可以在此對需求的內容作簡要的描述。5.3.1.3 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：l 高：關鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的需求必須在本次項目開發(fā)中實現(xiàn)。l 中：重要的功能，必選，不能實現(xiàn)可能會影響產品的銷售和客戶滿意度。所有“中”優(yōu)先級的需求都應該作為產品的功能點，但在時間、資源的壓力下，可以考慮在產品的下一個版本中實現(xiàn)。l 低：有用的功能或