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

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