CMMI5文檔之軟件需求規(guī)格說明書模板

1、軟件需求規(guī)格說明書模板文檔編號：FHI_CMMI_RD_TEM_RSPEC文檔信息：軟件需求規(guī)格說明書模版文檔名稱：軟件需求規(guī)格說明書模版文檔類別：CMMI模板密 級：內(nèi)部秘密版本信息：1.1建立日期：2016-1-5創(chuàng)建人：EPG批準(zhǔn)人：李慶林批準(zhǔn)日期：2016.2.25存放位置：集成公司組織資產(chǎn)庫/組織標(biāo)準(zhǔn)過程編輯軟件：Microsoft Office 2003中文版文檔修訂記錄（引用時請修改為實際項目的信息）版本編號或者更改記錄編勺變化狀態(tài)簡要說明（變更內(nèi)容和變更范圍）修改日期變更人批準(zhǔn)日期批準(zhǔn)人V1.0C創(chuàng)建2016-1-5張娜娜2016-2-25李慶林V1.1M文檔編號去掉版本號20

2、16-4-17鄧沛沛2016-4-17李慶林*變化狀態(tài)：C創(chuàng)建， A-增加，M-修改，D一一刪除1引言51.1 編寫目的51.2 產(chǎn)品的范圍51.3 預(yù)期的讀者和閱讀建議 51.4 術(shù)語、定義、符號及縮略語 51.5 參考資料52 綜合描述52.1 產(chǎn)品的背景62.2 用戶類和特征62.3 產(chǎn)品的功能62.4 遵循的標(biāo)準(zhǔn)和規(guī)范62.5 應(yīng)用模型62.6 運行環(huán)境62.7 設(shè)計和實現(xiàn)上的限制 62.8 假設(shè)和依賴73 功能需求73.1 功能需求關(guān)系模型83.2 功能1 83.3 功能n 84 功能需求 94.1 包結(jié)構(gòu)模型/模塊關(guān)系模型 錯誤！未定義書簽。4.2 <Package A>

3、; (With UseCase) 錯誤！未定義書簽。4.2.1 <Package A>概述 錯誤！未定義書簽。4.2.2 Use Cases目錄 錯誤！未定義書簽。4.2.3 Use Cases模型錯誤！未定義書簽。4.2.4 Use Cases序列圖錯誤！未定義書簽。4.2.5 Use Cases活動圖錯誤！未定義書簽。4.2.6 Use Cases描述錯誤！未定義書簽。4.3 Feature B> ( Without UseCase) 錯誤！未定義書簽。4.3.1 < Feature B >概述錯誤！未定義書簽。4.3.2 <需求N> 錯誤！未定義

4、書簽。5 非功能需求125.1 性能需求125.1.1 <性能需求M> 125.2 可靠性需求135.2.1 可靠性需求M> 135.3 安全設(shè)施需求145.3.1 <安全設(shè)施需求 M> 145.4 安全性需求155.4.1 安全性需求 M> 155.5 質(zhì)量屬性165.5.1 <質(zhì)量屬性需求 M> 165.6 用戶文檔與幫助系統(tǒng)175.6.1 用戶文檔與幫助系統(tǒng)需求 M> 175.7 其它需求185.7.1 <其它需求M> 186 接口需求196.1 用戶接口 196.1.1 <用戶接口需求 M> 196.2 硬件

5、接口 206.2.1 <硬件接口需求 M> 206.3 軟件接口 216.3.1 <軟件接口需求 M> 216.4 通信接口 226.4.1 <通信接口需求 M> 227 驗收標(biāo)準(zhǔn)238 附錄238.1 附錄A:分析模型238.2 附錄B:待確定問題的列表 238.3 附錄C:編寫需求文檔的原則 231引言提出對軟件需求規(guī)格說明書的縱覽，幫助讀者理解文檔如何編寫并且如何閱讀和解釋。1.1 編寫目的對產(chǎn)品（也可能是項目，但是我們統(tǒng)稱為產(chǎn)品）進行定義，在該文檔中詳盡說明這個產(chǎn)品的需 求，包括修正或發(fā)行版本號。如果這個軟件需求規(guī)格說明書只與整個系統(tǒng)的一部分有關(guān)，那

6、么 只定義文檔中說明的部分或子系統(tǒng)。舉例：本文的目的是為了清晰地說明產(chǎn)品要實現(xiàn)的所有功能， 產(chǎn)品的設(shè)計、編碼和測試都要以本文的內(nèi)容為基礎(chǔ)。同時，本文確定的內(nèi)容還作為產(chǎn)品驗收的基準(zhǔn)。 客戶、項目組要共同協(xié)商本文內(nèi)容。1.2 產(chǎn)品的范圍提供對指定的產(chǎn)品及其目的的簡短描述，解釋產(chǎn)品要做什么，不做什么，產(chǎn)品適用的領(lǐng)域和不 適用的領(lǐng)域，應(yīng)當(dāng)包含的內(nèi)容和不包含的內(nèi)容，說明產(chǎn)品將如何被使用，以及相關(guān)的利益和目標(biāo)。 可以參考產(chǎn)品概述文檔，但不是將其內(nèi)容復(fù)制到這里。1.3 預(yù)期的讀者和閱讀建議列舉本文檔所針對的不同讀者，例如開發(fā)人員、市場人員、測試人員、客戶等。描述文檔中剩 余部分的內(nèi)容及其組織結(jié)構(gòu)，提出最適合

7、每一類型讀者閱讀文檔的建議。1.4 術(shù)語、定義、符號及縮略語按字母或拼音順序列出所有的定義和縮略語，以便讀者可以正確地理解軟件需求規(guī)格說明書包括詞頭和縮寫。注意：只需要列出對理解本文有用的術(shù)語。1.5 參考資料列舉編寫軟件需求規(guī)格說明書時所參考的資料或其它來源?？赡馨ㄓ脩艚缑骘L(fēng)格指導(dǎo)、 合同、標(biāo)準(zhǔn)、系統(tǒng)需求規(guī)格說明書、用戶需求、相關(guān)產(chǎn)品的軟件需求規(guī)格說明書。這里應(yīng)該給出參 考資料詳細(xì)的信息，包括標(biāo)題名稱、作者、版本號、日期、出版單位或資料來源，以方便讀者查閱 這些文獻。2綜合描述這一部分概述了正在定義的產(chǎn)品以及它所運行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設(shè)和 依賴。2.1 產(chǎn)品的背景描述軟

8、件需求規(guī)格說明書中所定義的產(chǎn)品的背景和起源。說明該產(chǎn)品是否是產(chǎn)品系列中的下一 個成員，是否是成熟產(chǎn)品所改進的下一代產(chǎn)品、是否是現(xiàn)有應(yīng)用程序的替代品，或者是否是一個全 新的產(chǎn)品。如果軟件需求規(guī)格說明書定義了大系統(tǒng)的一個組成部分，那么就要說明這部分子系統(tǒng)是怎樣與 整個系統(tǒng)相關(guān)聯(lián)的，并且要定義出兩者之間的接口。建議使用系統(tǒng)結(jié)構(gòu)圖或者實體關(guān)系圖表示。2.2 用戶類和特征將可能使用本產(chǎn)品的用戶進行分類。由于用戶在使用產(chǎn)品的頻率、使用的功能集、技術(shù)水平、 權(quán)限級別、工作經(jīng)驗等方面的不同，會形成各種類型的用戶群。對每類用戶，描述其特點、期望的 需求、如何使用產(chǎn)品、產(chǎn)品滿足的優(yōu)先級等。有一些需求可能只與特定的

9、用戶類相關(guān)。將該產(chǎn)品的 重要用戶類與那些不太重要的用戶類區(qū)分開。2.3 產(chǎn)品的功能概述產(chǎn)品必須具備的主要功能，本文檔在第三章對產(chǎn)品功能進行詳細(xì)描述，在此僅作概括總結(jié),重點在系統(tǒng)層次上描述產(chǎn)品的功能需求和功能分類，還可能包括保證產(chǎn)品與外部組件正確連接的需求?？梢允褂昧斜淼姆椒ńo出，也可使用圖形表示主要的需求分組以及它們之間的聯(lián)系，例如數(shù)據(jù)流程圖的頂層圖或類圖。以使描述更加有效。2.4 遵循的標(biāo)準(zhǔn)和規(guī)范闡述本產(chǎn)品應(yīng)當(dāng)遵循什么標(biāo)準(zhǔn)、規(guī)范、業(yè)務(wù)規(guī)則。2.5 應(yīng)用模型運用場合、環(huán)境、組網(wǎng)、應(yīng)用舉例。繪制產(chǎn)品的結(jié)構(gòu)圖示、與系統(tǒng)相交互的外部對象之間的關(guān)系。2.6 運行環(huán)境描述產(chǎn)品的運行環(huán)境，包括為支持產(chǎn)品工

10、作所需的其它的組件或者與其共存的產(chǎn)品；對于軟件 產(chǎn)品還應(yīng)包括硬件平臺、操作系統(tǒng)和版本、必須安裝的軟件部件和其他應(yīng)用軟件等。2.7 設(shè)計和實現(xiàn)上的限制確定影響開發(fā)人員自由選擇的問題，并說明這些問題為什么成為一種限制?？赡艿南拗瓢ǎ罕仨毷褂没蛘弑苊獾奶囟夹g(shù)、工具、編程語言、數(shù)據(jù)庫;經(jīng)費、進度、資源等方面的限制；所要求的開發(fā)規(guī)范或標(biāo)準(zhǔn)；企業(yè)策略、政府法規(guī)或工業(yè)標(biāo)準(zhǔn)；硬件限制，例如定時需求或存儲器限制；數(shù)據(jù)轉(zhuǎn)換格式標(biāo)準(zhǔn)。其它。2.8 假設(shè)和依賴列出所有會影響需求實現(xiàn)的假設(shè)因素（相對于已知的事實而言），可能包括打算要用的商業(yè)組件或有關(guān)開發(fā)或運行環(huán)境的問題。例如，本項目產(chǎn)品計劃要使用某些第三方軟件產(chǎn)品

11、或商業(yè)軟件產(chǎn)品，雖然目前還未得到這些軟件，但我們可以假設(shè)這些軟件一定能夠得到。如果這些假設(shè)不正確、或發(fā) 生改變，會影響項目的開發(fā)，因此，這些假設(shè)往往又是一種風(fēng)險。此外，確定項目對外部因素存在的依賴。例如，如果項目的開發(fā)或項目產(chǎn)品的使用要依靠其它外部因素，比如與其它產(chǎn)品共用的軟件包、準(zhǔn)備重用的軟件構(gòu)件等，也要在此說明。3章和4章編寫功能需求的方式可以根據(jù)項目情況任意選擇一個。3功能需求需求編號規(guī)則：一級功能1,二級功能1.1,三級功能1.1.1,順序向下排。下表中只填寫到二級模塊，詳細(xì)模塊見下面的明細(xì)說明。需求跟蹤時跟蹤到葉子節(jié)點，在需求跟蹤矩陣上只填寫葉子節(jié)點。如果某功能是復(fù)用公司平臺或其他項

12、目組組件，在描述中標(biāo)識“復(fù)用”，說明復(fù)用的組件。需求編號模塊名稱優(yōu)先級描述1功能11.1功能1.1高1.2功能1.2高復(fù)用詳細(xì)列出與該特性相關(guān)的功能需求。這些是必須提交給用戶的軟件功能，使用戶可以使用所提供的特性執(zhí)行服務(wù)或者使用所指定的用例執(zhí)行任務(wù)。描述產(chǎn)品如何響應(yīng)可預(yù)知的出錯條件或非法輸入或動作。3.1 功能需求關(guān)系模型3.2 功能1(1)編號和名稱本功能的編號和名稱。(2)輸入描述本功能的輸入信息(包括需要訪問的存儲信息)(3)過程對本功能將做什么進行詳細(xì)的描述。(4)輸出描述本功能的輸出信息(包括需要訪問的存儲信息)(5)候選可重用軟件說明識別出的候選可重用軟件。(6)驗收準(zhǔn)則說明用于驗

13、證滿足需求的驗收準(zhǔn)則。3.3功能n(1)編號和名稱本功能的編號和名稱。(2)輸入描述本功能的輸入信息(包括需要訪問的存儲信息)(3)過程對本功能將做什么進行詳細(xì)的描述。(4)輸出描述本功能的輸出信息(包括需要訪問的存儲信息)(5)候選可重用軟件說明識別出的候選可重用軟件。(6)驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。4功能需求本章將詳細(xì)解釋產(chǎn)品所有的功能需求。功能需求是根據(jù)系統(tǒng)特性即產(chǎn)品所提供的主要服務(wù)來組織的。你可能更喜歡通過用例、運行模式、用戶類、對象類或功能等級來組織這部分內(nèi)容，你還可 以使用它們的組合?？傊?，你必須選擇一種使讀者易于理解預(yù)期產(chǎn)出的組織方案。如果使用傳統(tǒng)的需求分析方法，本

14、章的每一節(jié)描述一個功能需求，每個功能需求又從編號、名稱、優(yōu)先級、輸入、處理、輸出、驗收準(zhǔn)則7項來說明。如果使用 UML模型描述需求分析結(jié)果，本章的每一節(jié)采用“使用用例”描述一個功能需求，并在此說明參考的“使用用例”文件名；如果 你采用模型工具繪制用例視圖，你應(yīng)在此注明所用工具的名稱、版本等信息。本章中所列出的需求，要求細(xì)化到如下程度：(1)設(shè)計人員可以依據(jù)該需求設(shè)計并實現(xiàn)系統(tǒng)；(2)系統(tǒng)測試人員可以依據(jù)該需求編寫測案并對系統(tǒng)進行驗證。4.1 包結(jié)構(gòu)模型/模塊關(guān)系模型使用UML模型描述需求分析結(jié)果時，在本節(jié)劃分出系統(tǒng)的包結(jié)構(gòu)，用圖表示出用戶機構(gòu)與本 系統(tǒng)各個包之間的關(guān)系和本系統(tǒng)各包部分之間的關(guān)系

15、。使用傳統(tǒng)的需求分析方法時，在本節(jié)劃分出系統(tǒng)的各功能模塊結(jié)構(gòu)，用圖表示出用戶機構(gòu)與本系統(tǒng)各個功能模塊之間的關(guān)系和本系統(tǒng)各功能模塊之間的關(guān)系。4.2 Package A (With UseCase )本節(jié)示范使用 UML模型描述需求分析結(jié)果時的文檔結(jié)構(gòu)。本節(jié)詳細(xì)描述Package A的需求,其中標(biāo)題Package A需以實際的功能類別名代替。4.2.1 Package A 概述在此對Package A進行概要性說明，例如：此包中包含實現(xiàn)預(yù)付費業(yè)務(wù)所需的所有功能。4.2.2 用例目錄在此列出Package A中所有涉及的用例目錄，建議采用表格形式，例如下表：用例編號規(guī)則：一級功能1,二級功能1,1

16、,三級功能1.1.1,順序向下排。下表中可只填寫到二級模塊，詳細(xì)模塊見下面的明細(xì)說明。需求跟蹤時跟蹤到葉子節(jié)點，在需 求跟蹤矩陣上只填寫葉子節(jié)點。如果某功能是復(fù)用公司平臺或其他項目組組件，在描述中標(biāo)識 “復(fù)用”，說明復(fù)用的組件。一模塊編號模塊名稱優(yōu)先級描述1功能1中1.1功能1.1高n功能n中其中該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：高：關(guān)鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的需求 必須在本次項目開發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先級的 需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源

17、的壓力下，可以考慮在產(chǎn)品的下一個版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在特定 的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版本中實現(xiàn)。4.2.3 用例模型用例之間的關(guān)系的圖示，例如：appmanager clientSecurity(from ucv prepaid appserver)E Enhanced security(from tmpucv_lwb)Muti-Card Registration(from tmpucv_lwb)Current creditAbbreviated dialling(from uc

18、v prepaid appserver)(from ucv prepaid appserver)(from ucv prepaid appserver)-Abbre Dial Num ModificationCaller Binding(from ucv appserver) 飛，raidus client %(from ucv appserver)Prepaid ManagerASB SDK Client API(from ucv appserver) /Prepaid AppPrompt and collect userinformation(from ucv prepaid appser

19、ver)1Destination restricted calling(from ucv prepaid appserver)Balance Transfer(from tmpucv liye)- Basic Call Flow(from tmpucv_liye)PIN modification(from ucv prepaid appserver)4.2.4 業(yè)務(wù)對象模型4.2.5 用例描述 <用例 M>用例M的詳細(xì)描述，例如下表:用例名稱主參與名輔助參與者狀態(tài)簡述主流1、輔助流/候補流/場景牛寸殊向求1、假設(shè)前置條件1、后置條件1、編寫日志修改人修改時間版本簡述5

20、非功能需求編號規(guī)則：一級功能NF1,二級功能NF1.1 ,三級功能NF1.1.1 ,順序向下排。如果某功能是復(fù)用公司平臺或其他項目組組件，在描述中標(biāo)識“復(fù)用” ，說明復(fù)用的組件。下表模塊列表只寫到一級模塊，需求跟蹤時跟蹤到葉子節(jié)點，詳細(xì)模塊見下面的詳細(xì)說明。表二：非功能需求分類表需求類別編力需求名稱優(yōu)先級描述5.1 性能需求說明本軟件產(chǎn)品要滿足的量化性能需求，以體現(xiàn)不同的應(yīng)用領(lǐng)域?qū)Ξa(chǎn)品性能的要求，包括：支 持的終端數(shù)、并行操作的用戶數(shù)、相互合作的用戶數(shù)或者所支持的操作、要處理的信息的數(shù)量和類 型、響應(yīng)時間以及與實時系統(tǒng)的時間關(guān)系、相同負(fù)載情況下的持續(xù)處理時間等。還可以在這里定義 容量需求，例如

21、存儲器和磁盤空間的需求或者存儲在數(shù)據(jù)庫中表的最大行數(shù)。所有這些需求必須以量化或可度量的方式盡可能詳細(xì)地描述，解釋它們的原理并說明每項需求 的理由，以幫助開發(fā)人員做出合理的設(shè)計選擇。可能需要針對每個功能需求或特性分別陳述其性能 需求，而不是把它們都集中在一起陳述。例如，“在運行微軟 Window 2000的450 MHzPentium n的計算機上，當(dāng)系統(tǒng)至少有 50%的空閑資源時，95%的目錄數(shù)據(jù)庫查詢必須在兩秒內(nèi)完成”。5.1.1 <性能需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。需求名稱，如果需要可以在此對需求的內(nèi)容作簡要

22、的描述。 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：對高、中、低的解釋如下：高：關(guān)鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的 需求必須在本次項目開發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先 級的需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個 版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明

23、用于驗證滿足需求的驗收準(zhǔn)則。5.2 可靠性需求例如:說明本軟件產(chǎn)品要滿足的量化可靠性需求，以體現(xiàn)不同的應(yīng)用領(lǐng)域?qū)Ξa(chǎn)品可靠性的要求，滿配置情況下，連續(xù)無故障工作時間不小于5000小時。所有這些需求必須以量化或可度量的方式盡可能詳細(xì)地描述，解釋它們的原理并說明每項需求 的理由，以幫助開發(fā)人員做出合理的設(shè)計選擇?？赡苄枰槍γ總€功能需求或特性分別陳述其可靠 性需求，而不是把它們都集中在一起陳述。5.2.1 可靠性需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。5.2

24、.1.3 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：對高、中、低的解釋如下：高：關(guān)鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的 需求必須在本次項目開發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先 級的需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個 版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需

25、求的驗收準(zhǔn)則。5.3 安全設(shè)施需求詳盡陳述與產(chǎn)品使用過程中可能發(fā)生的損失、破壞或危害相關(guān)的需求。定義必須采取的安全保 護或動作，還有那些預(yù)防的潛在的危險動作。明確產(chǎn)品必須遵從的安全標(biāo)準(zhǔn)、策略或規(guī)則。一個安 全設(shè)施需求的范例如下：“如果設(shè)備的溫度超過了規(guī)定的最大工作溫度，那么必須在1秒鐘內(nèi)終止操作”。5.3.1 <安全設(shè)施需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：

26、高：關(guān)鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的 需求必須在本次項目開發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先 級的需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個 版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。5.4 安全性需求陳述與系統(tǒng)安全性、完整性或私人問題相關(guān)的需求，說明軟件產(chǎn)品防止由于意外或惡

27、意的訪問、不正確的使用或修改所帶來的破壞的要求，這些問題將會影響到產(chǎn)品的使用和產(chǎn)品所創(chuàng)建或使用的 數(shù)據(jù)的保護。這些要求可能包括，密碼系統(tǒng)、身份認(rèn)證、數(shù)據(jù)加密、備份機制等。一個安全需求的 范例如下：“每個用戶在第一次登錄后，必須更改他的最初登錄密碼。最初的登錄密碼不能重用?！?.4.1 安全性需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下: 高：關(guān)鍵的功能特性，必選，不能實現(xiàn)

28、意味著無法滿足客戶的需求。所有“高”優(yōu)先級的 需求必須在本次項目開發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先 級的需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個 版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。5.5 質(zhì)量屬性詳盡陳述與客戶或開發(fā)人員至關(guān)重要的質(zhì)量特性，指明產(chǎn)品在可靠性、可移植性、實用性、可 維護性等方面的目標(biāo)。應(yīng)盡量

29、以明確的、量化的、可檢驗的方式來描述。至少應(yīng)指明不同屬性的相 對側(cè)重點，例如易用程度優(yōu)于易學(xué)程度，或者可移植性優(yōu)于有效性。如果某個這樣的質(zhì)量屬性比較重要（例如：可移植性） ，可以單獨用新的一節(jié)來描述。5.5.1 <質(zhì)量屬性需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。 優(yōu)先級該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：高：關(guān)鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的 需求必須在本次項目開

30、發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先級的需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源的壓力下，可以考慮在產(chǎn)品的下一個 版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。5.6 用戶文檔與幫助系統(tǒng)列舉出將與產(chǎn)品一同發(fā)行的用戶文檔部分，例如，用戶手冊、在線幫助和教程。明確所有已知 的用戶文檔的交付格式或標(biāo)準(zhǔn)。5.6.1 用戶文檔與幫助系統(tǒng)需求M>本節(jié)的標(biāo)題需

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

32、能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。5.7 其它需求對其它需要描述但未在本模板中列出的需求，在此進行說明。例如國際化需求、法律上的需求,有關(guān)操作、管理和維護部分來完善產(chǎn)品安裝、配置、啟動和關(guān)閉、修復(fù)和容錯，以及登錄和監(jiān)控操作等方面的需求等。如果某個這樣的需求比較重要，可以單獨用新的一節(jié)來描述。如果不需要增加其它需求，就標(biāo)記為“無"。5.7.1 <其它需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。5.7.

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

34、本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。6接口需求編號規(guī)則：一級功能IF1,二級功能IF1.1 ,三級功能IF1.1.1 ,順序向下排。如果某功能是復(fù)用公司平臺或其他項目組組件，在描述中標(biāo)識“復(fù)用” ，說明復(fù)用的組件。下表模塊列表可只寫到一級模塊，需求跟蹤時跟蹤到葉子節(jié)點，詳細(xì)模塊見下面的詳細(xì)說明。表三：接口需求分類表需求類別編P需求名稱優(yōu)先級描述6.1 用戶接口陳述產(chǎn)品中所需要的用戶界面。描述每個用戶界面的邏輯特征。以下是可能要包括的一些特征:將要采用的圖形用戶界面標(biāo)準(zhǔn)或整個產(chǎn)品系列的風(fēng)格；屏幕布局；將出現(xiàn)在每個屏幕的標(biāo)準(zhǔn)按鈕（如幫助）、功能或?qū)Ш芥溄?；鍵盤快捷鍵；

35、錯誤信息顯示標(biāo)準(zhǔn)。如果必要，用戶接口需求的細(xì)節(jié)可在獨立的用戶接口規(guī)格文件中描述。6.1.1 <用戶接口需求 M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容作簡要的描述。該需求的優(yōu)先級，按高、中、低的優(yōu)先級分類。對高、中、低的解釋如下：高：關(guān)鍵的功能特性，必選，不能實現(xiàn)意味著無法滿足客戶的需求。所有“高”優(yōu)先級的 需求必須在本次項目開發(fā)中實現(xiàn)。中：重要的功能，必選，不能實現(xiàn)可能會影響產(chǎn)品的銷售和客戶滿意度。所有“中”優(yōu)先 級的需求都應(yīng)該作為產(chǎn)品的功能點，但在時間、資源的壓

36、力下，可以考慮在產(chǎn)品的下一個 版本中實現(xiàn)。低：有用的功能或性能的提高，可選，不能實現(xiàn)不會對產(chǎn)品產(chǎn)生實質(zhì)性影響，但可能會在 特定的應(yīng)用場合增加產(chǎn)品的賣點，在時間、資源允許的情況下，可以考慮在產(chǎn)品的某一版 本中實現(xiàn)。 驗收準(zhǔn)則說明用于驗證滿足需求的驗收準(zhǔn)則。6.2 硬件接口描述系統(tǒng)中軟件和硬件每一接口的特征，可能包括軟件所支持的設(shè)備類型、軟硬件之間交流的 數(shù)據(jù)和控制信息的性質(zhì)、通訊協(xié)議等。6.2.1 <硬件接口需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需求的內(nèi)容

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

38、的驗收準(zhǔn)則。6.3 軟件接口說明本產(chǎn)品與產(chǎn)品組件間的接口需求，本產(chǎn)品與其它外部組件 （包括數(shù)據(jù)庫、操作系統(tǒng)、工具、運行庫、集成的商業(yè)部件等，要指明它們的名字和版本）的連接。明確并描述在軟件組件之間交換 數(shù)據(jù)或消息的目的。描述所需要的服務(wù)以及內(nèi)部組件通信的性質(zhì)。確定將在組件之間共享的數(shù)據(jù)。如果必須用一種特殊的方法來實現(xiàn)數(shù)據(jù)共享機制，例如在多任務(wù)操作系統(tǒng)中的一個全局?jǐn)?shù)據(jù)區(qū)，那么就必須把它定義為一種實現(xiàn)上的限制。6.3.1 <外部接口需求M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在此對需

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

40、需求的驗收準(zhǔn)則。6.3.2 <內(nèi)部接口需求 M>內(nèi)部接口是指系統(tǒng)內(nèi)部模塊與模塊之間消息（或數(shù)據(jù)）傳遞的測試。 接口名稱編號需求描述發(fā)送方模塊 編號接收方模 塊編號驗收準(zhǔn)則6.4 通信接口描述與產(chǎn)品所使用的通信功能相關(guān)的需求，例如電子郵件、WEB瀏覽器、網(wǎng)絡(luò)通信標(biāo)準(zhǔn)或協(xié)議及電子表格等。定義相關(guān)的信息格式，指明要遵守的通訊標(biāo)準(zhǔn)，如FTP, HTTP等。說明在通訊中的安全和加密問題、數(shù)據(jù)傳輸速率、同步機制等。6.4.1 <通信接口需求 M>本節(jié)的標(biāo)題需以實際的需求名代替。 編號為需求定義一個唯一的編號，便于需求跟蹤。 名稱及說明需求名稱，如果需要可以在