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

XXX項目軟件需求規(guī)格說明書XXXX20年月曰文檔信息文檔標(biāo)題XXX項目需求規(guī)格說明書歸檔日期所有者修訂歷史版本編號版本日期修訂內(nèi)容備注V0.1初始版本V0.2V0.3V0.4V0.5V0.6V0.7V0.8V0.9V1.0文檔編制、審核與批準(zhǔn)目錄TOC\o"1-5"\h\z\o"CurrentDocument"1引言 1\o"CurrentDocument"1.1目的 1\o"CurrentDocument"1.2范圍 1\o"CurrentDocument"1.3定義、簡寫和縮略語 1\o"CurrentDocument"1.4引用文件 1\o"CurrentDocument"1.5綜述 2\o"CurrentDocument"2總體描述 2\o"CurrentDocument"2.1產(chǎn)品描述 2\o"CurrentDocument"2.1.1系統(tǒng)接口 3\o"CurrentDocument"2.1.2用戶界面 3\o"CurrentDocument"2.1.3硬件接口 3\o"CurrentDocument"2.1.4軟件接口 3\o"CurrentDocument"2.1.5通信接口 4\o"CurrentDocument"2.1.6內(nèi)存約束 4\o"CurrentDocument"2.1.7操作 4\o"CurrentDocument"2.1.8現(xiàn)場適應(yīng)性需求 .4\o"CurrentDocument"2.2產(chǎn)品功能 4\o"CurrentDocument"2.3用戶特點 5\o"CurrentDocument"2.4約束 5\o"CurrentDocument"2.5假設(shè)和依賴關(guān)系 5\o"CurrentDocument"2.6需求分配 6\o"CurrentDocument"3具體需求 6\o"CurrentDocument"3.1外部接口 63.2功能 7\o"CurrentDocument"3.3性能需求 9\o"CurrentDocument"3.4數(shù)據(jù)庫邏輯需求 10\o"CurrentDocument"3.5設(shè)計約束 10\o"CurrentDocument"3.5.1標(biāo)準(zhǔn)依從性 10\o"CurrentDocument"3.6軟件系統(tǒng)屬性 11\o"CurrentDocument"3.6.1可靠性 11\o"CurrentDocument"3.6.2可用性 11\o"CurrentDocument"3.6.3安全保密性 11\o"CurrentDocument"3.6.4可維護(hù)性 11\o"CurrentDocument"3.6.5可移植性 11\o"CurrentDocument"3.7具體需求的組織 12\o"CurrentDocument"3.7.1系統(tǒng)模式 12\o"CurrentDocument"3.7.2用戶類型 13\o"CurrentDocument"對象 13\o"CurrentDocument"特征 13\o"CurrentDocument"激勵 13\o"CurrentDocument"響應(yīng) 13\o"CurrentDocument"3.7.7功能層次 13\o"CurrentDocument"3.8附加說明 14\o"CurrentDocument"4附錄 141引言本部分應(yīng)當(dāng)提供整個SRS的概述1.1目的本條宜：a） 描述SRS的目的；b） 說明SRS的預(yù)期讀者。1.2范圍本條宜：a） 通過名稱識別要生產(chǎn)/開發(fā)的軟件產(chǎn)品（例如，宿主數(shù)據(jù)庫管理系統(tǒng)（DBMS）、報告生成器等）；b） 必要時，說明軟件產(chǎn)品將做或不做什么；c） 描述規(guī)定的軟件的應(yīng)用，包括相關(guān)的收益、目標(biāo)和目的；d） 如果上層規(guī)格說明（如，系統(tǒng)需求規(guī)格說明）存在，與上層規(guī)格說明類似的陳述保持一致。1.3定義、簡寫和縮略語本條宜提供對正確解釋SRS所要求的所有術(shù)語、簡寫和縮略語的定義，這些信息可以通過引用SRS中的一個或多個附錄、或者引用其他文件的方式來提供。1.4引用文件本條宜：a）提供SRS引用的所有文件的完整清單;b） 標(biāo)識出每個文件的名稱、報告編號（適用時）、日期、出版組織；c） 標(biāo)明可以獲得引用文件的來源。這些信息可以通過引用附錄或引用其他文檔的方式提供。1.5綜述本條宜：a） 描述SRS的其余章條包含的內(nèi)容；b） 說明SRS是如何組織的。2總體描述本章宜描述影響產(chǎn)品及其需求的一般因素，而不敘述具體的需求。相反，它提供需求的背景并使它們更易理解，而在SRS的第3章將詳細(xì)定義這些需求。2.1產(chǎn)品描述本條宜把產(chǎn)品置于其他有關(guān)產(chǎn)品的全景之下。如果產(chǎn)品是獨立的和完全自我包含的，這里宜如實給予陳述。正如常出現(xiàn)的那樣，如果SRS定義的產(chǎn)品是較大系統(tǒng)的組成部分，則本章宜將軟件的功能性與較大系統(tǒng)的需求相聯(lián)系，而且宜識別軟件和系統(tǒng)之間的接口。使用框圖展示較大系統(tǒng)的主要部分、相互聯(lián)系以及外部接口是有幫助的。本條也宜描述在各種不同的約束下軟件如何運行。如，這些約束可包括：a） 系統(tǒng)接口；b） 用戶界面；c） 硬件接口；d） 軟件接口；e）通信接口;f） 內(nèi)存；g） 運行；h） 現(xiàn)場適應(yīng)性需求等。2.1.1系統(tǒng)接口本條宜列出每個系統(tǒng)接口，識別完成系統(tǒng)需求的軟件功能以及與系統(tǒng)匹配的接口描述。2.1.2用戶界面本條宜規(guī)定以下方面：a） 在軟件產(chǎn)品與用戶之間每個界面的邏輯特征。這包括完成軟件需求所需要的那些配置特征（例如，要求的屏幕顯示格式、頁面或窗口版式布局、任何報告或菜單的內(nèi)容、或者可編程功能鍵的設(shè)置）；b） 優(yōu)化系統(tǒng)用戶界面的所有方面。這可以簡單地包括一個針對系統(tǒng)對用戶的顯示方式系統(tǒng)將做什么和不做什么的清單。例如，可能是一項選擇長或短的錯誤消息方面的需求。如同所有其他需求一樣，這些需求宜是可驗證的，例如，“經(jīng)過th培訓(xùn)后，4級打字員能夠在Zrnln內(nèi)執(zhí)行功能X”，而不是“打字員能夠執(zhí)行功能X”（這也可以在標(biāo)題為使用方便性章條的軟件系統(tǒng)屬性中規(guī)定）。2.1.3硬件接口本條宜規(guī)定系統(tǒng)硬件各部件與軟件產(chǎn)品之間每個接口的邏輯特征，包括配置特征（端口數(shù)量、指令集等），同樣也覆蓋這些事項，如，支持什么設(shè)備、如何支持以及采用什么協(xié)議。例如，相對逐行支持，終端支持可能規(guī)定為全屏支持。2.1.4軟件接口本條宜規(guī)定對其他軟件產(chǎn)品（例如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)、或數(shù)學(xué)軟件包）的使用，以及與其他應(yīng)用系統(tǒng)（例如，賬戶接收系統(tǒng)和一般的會計記帳系統(tǒng)的鏈接）的接口。對于每個要求的軟件產(chǎn)品，宜提供：a） 名稱；b） 助記符；c） 規(guī)格說明編號；d） 版本號；e）來源。對于每個接口，宜提供：a） 相對此軟件產(chǎn)品，接口軟件的目的的論述；b） 按照消息內(nèi)容和格式對接口的定義，不必要詳細(xì)描述任何已文件化的接口，但要求引用定義此接口的文件。2.1.5通信接口本條宜定義不同的通信接口，如，局域網(wǎng)協(xié)議等。2.1.6內(nèi)存約束本條宜規(guī)定對主存和輔存的任何適用特征和限制。2.1.7操作本條宜規(guī)定用戶要求正常的和特定的操作，如：a） 用戶組織的不同操作模式（如，用戶引發(fā)的操作）；b） 交互操作的周期和無人值守操作的周期；c） 數(shù)據(jù)處理支持功能；d） 備份和恢復(fù)操作。注：有時此條規(guī)定作為用戶界面的一部分。2.1.8現(xiàn)場適應(yīng)性需求本條宜：a） 對于給定的現(xiàn)場、任務(wù)或運行模式（如，網(wǎng)格數(shù)、安全限制等），為任何數(shù)據(jù)或啟動順序定義需求；b） 針對軟件適應(yīng)特定的安裝現(xiàn)場或任務(wù)，規(guī)定應(yīng)當(dāng)修改的特征。2.2產(chǎn)品功能本條宜給出軟件將執(zhí)行主要功能的概要。例如，某個會計程序的SRS可在此部分關(guān)注顧客賬戶維護(hù)、顧客財務(wù)報表及發(fā)票準(zhǔn)備，而不涉及這些功能要求的大量細(xì)節(jié)。有時，本條需要的功能概要可直接從分配具體功能到軟件產(chǎn)品的更高層規(guī)格說明（如果存在）中摘錄。為了清晰，應(yīng)當(dāng)注意：a） 功能宜以這樣的方式組織，以使顧客或第一次閱讀該文件的任何讀者對功能列表容易理解；b） 可以使用文本或圖示的方法，顯示不同的功能及其之間的關(guān)系。這樣的圖示不必顯示產(chǎn)品的設(shè)計，但簡要顯示變量之間的邏輯關(guān)系。2.3用戶特點本條宜給出軟件產(chǎn)品預(yù)期用戶的一般特征，包括教育程度、經(jīng)驗、專業(yè)技術(shù)情況。它不宜指出具體的需求，但宜給出SRS第3章中為何規(guī)定某些具體需求的原因。2.4約束本條宜給出將會限制開發(fā)人員選擇的任何其他事項的一般描述。這些包括:a） 法規(guī)政策；b） 硬件局限（如，信號時間要求）；c） 與其他應(yīng)用的接口；d） 并行操作；e） 審核功能；f） 控制功能；g） 高級語言需求；h） 信號握手協(xié)議（如，XON-XOFF、ACK-NACK）；i） 可靠性需求；j） 應(yīng)用的關(guān)鍵性；k） 安全和保密安全考慮。2.5假設(shè)和依賴關(guān)系本條宜列出影響SRS規(guī)定需求的每個因素。這些因素不是軟件設(shè)計的限制條件，但是，它們的任何變更可能影響SRS中的需求。例如，某個假設(shè)可能是軟件產(chǎn)品指定的硬件具有某個特定操作系統(tǒng)，如果事實上該操作系統(tǒng)不能使用，那么SRS將做相應(yīng)的修改。2.6需求分配本條宜識別可能推遲到系統(tǒng)將來版本的需求。3具體需求本章宜包括足夠詳細(xì)的所有軟件需求，使設(shè)計人員能夠設(shè)計系統(tǒng)以滿足這需求，并且使測試人員能夠測試該系統(tǒng)滿足這些需求。貫穿本章，對于用戶、運行人員或其他外部系統(tǒng)，每個規(guī)定的需求應(yīng)當(dāng)是外部可理解的。這些需求至少應(yīng)當(dāng)包括，每個系統(tǒng)輸入（激勵）、每個系統(tǒng)輸出（響應(yīng)）以及系統(tǒng)通過響應(yīng)某個輸入或支持某個輸出所執(zhí)行的所有功能。由于這通常是SRS篇幅最大和最主要部分，以下原則適用：a） 規(guī)定的具體需求宜符合GB/T9385-20084.4描述的所有特征；b） 具體需求宜引用較早的相關(guān)文件；c） 所有的需求宜是唯一可標(biāo)識的；d） 宜注意需求的組織，使其具有最大的可讀性。在考察組織需求的具體方式之前，了解GB/T9385-20085.4.1到5.4.7組成需求的各個不同項是有益的。3.1外部接口本條宜是軟件系統(tǒng)所有輸入和輸出的詳細(xì)描述。它宜是對GB/T9385-20085.2的接口描述的補(bǔ)充，不宜重復(fù)前面已有的信息。宜包括以下內(nèi)容和格式：a） 項的名稱；b） 目的描述；c） 輸入源和輸出目的地；d） 有效范圍、準(zhǔn)確度和/或容限；e） 測量單位；f） 定時；g） 與其他輸入/輸出的關(guān)系；h） 屏顯格式/組織；i） 窗口格式/組織；j） 數(shù)據(jù)格式；k） 命令格式；l） 結(jié)束消息。功能需求宜定義軟件在接收和處理輸入以及處理和產(chǎn)生輸出中必須發(fā)生的基本動作。一般情況下使用“系統(tǒng)應(yīng)……”的方式來陳述。這些包括：a） 對輸入有效性的核查；b） 操作的準(zhǔn)確順序；c） 異常情況響應(yīng)，包括：1） 溢出；2） 通信設(shè)施；3） 錯誤處理和恢復(fù)；d） 參數(shù)影響；e） 輸入與輸出的關(guān)系，包括：1） 輸入/輸出順序；2） 從輸入到輸出轉(zhuǎn)換的公式。盡管將功能需求劃分為子功能或子過程可能是適當(dāng)?shù)模@并不意味著軟件設(shè)計同樣以這樣的方式劃分。3.2.1信息流3.2.1.1數(shù)據(jù)流圖13.2.1.1.1數(shù)據(jù)實體3.2.1.1.2有關(guān)的過程3.2.1.1.3拓?fù)鋱D3.2.1.2數(shù)據(jù)流圖23.2.1.2.1數(shù)據(jù)實體3.2.1.2.2有關(guān)的過程3.2.1.2.3拓?fù)鋱Dn數(shù)據(jù)流圖nn.1數(shù)據(jù)實體n.2有關(guān)的過程n.3拓?fù)鋱D3.2.2過程描述過程13.2.2.1.1輸入數(shù)據(jù)實體3.2.2.1.2過程算法或公式3.2.2.1.3受影響的數(shù)據(jù)實體過程21輸入數(shù)據(jù)實體3.2.2.2.2過程算法或公式3.2.2.2.3受影響的數(shù)據(jù)實體m過程mm.1輸入數(shù)據(jù)實體m.2過程算法或公式m.3受影響的數(shù)據(jù)實體3.2.3數(shù)據(jù)構(gòu)建規(guī)范構(gòu)建13.2.3.1.1記錄類型3.2.3.1.2組成字段構(gòu)建23.2.3.2.1記錄類型3.2.3.2.2組成字段p構(gòu)建pp.1記錄類型p.2組成字段3.2.4數(shù)據(jù)詞典3.2.4.1數(shù)據(jù)元素1名稱3.2.4.1.2表示法3.2.4.1.3單位/格式3.2.4.1.4精確度/準(zhǔn)確度范圍3.2.4.2數(shù)據(jù)元素2名稱3.2.4.2.2表示法3.2.4.2.3單位/格式3.2.4.2.4精確度/準(zhǔn)確度范圍q數(shù)據(jù)元素qq.1名稱q.2表示法q.3單位/格式q.4精確度/準(zhǔn)確度g.5范圍3?3性能需求本條宜規(guī)定軟件或人與軟件互作用的整體靜態(tài)的和動態(tài)的數(shù)量化需求。靜態(tài)數(shù)量化需求可能包括：a） 支持的終端數(shù)量；b） 支持同時運行的用戶數(shù)量;c）要處理的信息量和類型。有時，靜態(tài)數(shù)量需求包含在命名為“能力”的獨立部分。動態(tài)數(shù)量化需求可能包括，如，在正常和高峰工作負(fù)載條件，在某時段內(nèi)處理的事務(wù)處理數(shù)、任務(wù)數(shù)和數(shù)據(jù)量。所有這些需求宜以可測量的方式規(guī)定。如：應(yīng)在小于Is內(nèi)處理95%的交易量。而不是：操作方不需等待事務(wù)處理結(jié)束。注：適用于某個具體功能的數(shù)量化限制，通常作為該功能處理描述部分予以規(guī)定。3.4數(shù)據(jù)庫邏輯需求宜規(guī)定將置于數(shù)據(jù)庫的任何信息的邏輯需求。這可包括：a） 不同功能使用的信息類型；b） 使用頻度；c） 訪問能力；d） 數(shù)據(jù)實體及其之間的關(guān)系；e） 完整性約束；f） 數(shù)據(jù)保存需求。3.5設(shè)計約束宜規(guī)定可能由其他標(biāo)準(zhǔn)、硬件局限等引發(fā)的設(shè)計約束。3.5.1標(biāo)準(zhǔn)依從性本條宜規(guī)定來自現(xiàn)存標(biāo)準(zhǔn)或法規(guī)的需求。它們可能包括：a） 報告格式；b） 數(shù)據(jù)命名；c） 會計規(guī)程；d） 審核追蹤。例如，可以規(guī)定追蹤處理活動的軟件需求。為了最低滿足法規(guī)或財務(wù)標(biāo)準(zhǔn)，對于某些應(yīng)用這樣的追蹤是需要的。例如，審核追蹤需求可能規(guī)定，對于支付薪金數(shù)據(jù)庫的所有變更，必須在一個追蹤文檔中記錄支付前后的數(shù)額。3.6軟件系統(tǒng)屬性有一些軟件屬性可以作為需求。規(guī)定所要求的軟件屬性是重要的，這樣才能客觀地驗證屬性的實現(xiàn)情況。GB/T9385-20085.4.6.1到5.4.6.5給出了部分示例。3.6.1可靠性本條宜規(guī)定要求的因素，以便建立在交付時軟件系統(tǒng)所要求的可靠性。3.6.2可用性為了確保整個系統(tǒng)已定義的可用性程度，宜規(guī)定所要求的因素，如，檢查點、恢復(fù)以及重啟動。3.6.3安全保密性由于事故、惡意訪問、使用、修改、破壞或泄露，本條宜規(guī)定需要保護(hù)軟件的因素。這方面可能的具體需求包括：a） 使用某些密碼技術(shù)；b） 保留某些特定數(shù)據(jù)組的歷史或記錄；c） 分配某些功能到不同的模塊；d） 在程序的某些域間限制通信；e） 對于關(guān)鍵變量檢查數(shù)據(jù)的完整性。3.6.4可維護(hù)性本條宜規(guī)定與軟件本身維護(hù)簡易性有關(guān)的軟件屬性?？梢詫δK化、接口和復(fù)雜性等有一定的要求。但不宜僅因為是良好設(shè)計實踐就將其作為需求。3.6.5可移植性本條宜規(guī)定與軟件移植到其他主機(jī)和/或操作系統(tǒng)簡易性相關(guān)的軟件屬性。這可能包括：a） 依賴主機(jī)代碼模塊的百分比；b） 依賴主機(jī)代碼的百分比；c）已證明可移植語言的使用;d） 特定編譯器或語言子集的使用;e） 特定操作系統(tǒng)的使用。3.7具體需求的組織除了微小的系統(tǒng)之外，任何系統(tǒng)傾向有大量的詳細(xì)的需求。由此，宜仔細(xì)考慮這些需求的組織方式，以最優(yōu)化可理解性。對于所有的系統(tǒng)不存在單一的最優(yōu)化組織方式。不同類型的系統(tǒng)SRS的第3章有不同的需求組織方式。GB/T9385-20085.4.7.1到5.4.7.7描述了一些組織方式。3.7.1系統(tǒng)模式依賴于運行模式，某些系統(tǒng)的行為顯著不同。例如，根據(jù)其運行模式:培訓(xùn)、正常運行或者應(yīng)急，某個控制系統(tǒng)可能具有不同的功能集合。當(dāng)按照運行模式組織該部分時，宜采用第A.1章或第A.2章的提綱。需求組織方式的選擇取決于系統(tǒng)接口和性能是否依賴于運行模式。3.7.2用戶類型有些系統(tǒng)對不同的用戶提供不同的功能集合。例如，對于一般乘客、維護(hù)人員和消防人員，電梯控制系統(tǒng)顯示不同的能力。當(dāng)按照用戶類別組織該部分時，宜采用第A.3章的提綱。3.7.3對象對象是現(xiàn)實世界中的實體，系統(tǒng)具有與其對應(yīng)的部分。例如，在病人監(jiān)控系統(tǒng)中，對象包括病人、傳感器、護(hù)士、房間、醫(yī)師、醫(yī)藥等。與每個對象相聯(lián)系的是一組屬性（對象具有的）和功能（對象執(zhí)行的），這些功能也稱之為服務(wù)、方法或過程。當(dāng)按照對象組織該部分時，宜采用第A.4章的提綱。應(yīng)注意，對象組可能共有某些屬性和服務(wù)，要按照類別把這些組織在一起。3.7.4特征系統(tǒng)特征是從外部希望得到的服務(wù)，可能要求一系列的輸入以產(chǎn)生希望的結(jié)果。例如，在電話系統(tǒng)中，系統(tǒng)特征包括本地話務(wù)、話務(wù)轉(zhuǎn)接、以及會議話務(wù)。一般的，系統(tǒng)每個特征按照一系列激勵一響應(yīng)對的方式描述。當(dāng)按照系統(tǒng)特征組織該部分時，宜采用第A.5章的提綱。3.7.5激勵某些系統(tǒng)可以根據(jù)激勵描述其功能的方式最佳地組織其需求。例如，飛機(jī)自動著陸系統(tǒng)的功能，可依照動力降低、風(fēng)向切變、機(jī)身搖擺突變、垂直速度限值等，組織到相應(yīng)的部分。當(dāng)按照激勵方式組織該部分時，宜采用第A.6章的提綱。3.7.6響應(yīng)有些系統(tǒng)可以通過描述其支持產(chǎn)生