軟件技術(shù)文檔編寫規(guī)范

1、目第一章§ 1.1§ 1.2§ 1.3§ 1.4§ 1.5第二章§ 1§ 1§ 1§ 1§ 1§ 1第三章§ § § § 第四章4.11.11.2第五章5.15.25.35.45.55.6第六章111錄引言1目的1文檔約定1預(yù)期讀者和閱讀建議1產(chǎn)品的范圍1參考文獻(xiàn)1綜合描敘1產(chǎn)品的前景1產(chǎn)品的功能1用戶類和特征2運(yùn)行環(huán)境2設(shè)計(jì)和實(shí)現(xiàn)上的限制2假設(shè)和依賴2外部接口需求2用戶界面2硬件接口3軟件接口3通信接口3系統(tǒng)特性3說明和優(yōu)先級3激勵(lì)響應(yīng)序列3功

2、能需求3其他非功能需求3性能需求3安全設(shè)施需求4安全性需求4軟件質(zhì)量屬性4業(yè)務(wù)規(guī)則4用戶文檔4其他需求4詞匯表4分析模型4待確定問題列表5第1章引言引言提出了對軟件需求規(guī)格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。6 目的對產(chǎn)品進(jìn)行定義，在該文檔中詳盡說明了這個(gè)產(chǎn)品的軟件需求，包括修正或發(fā)行版本號。如果這個(gè)軟件需求規(guī)格說明只與整個(gè)系統(tǒng)的一部分有關(guān)系，那么就只定義文檔中說明的部分或子系統(tǒng)。6 文檔約定描述編寫文檔時(shí)所采用的標(biāo)準(zhǔn)或排版約定，包括正文風(fēng)格、提示區(qū)或重要符號。例如，說明了高層需求的優(yōu)先級是否可以被其所有細(xì)化的需求所繼承，或者每個(gè)需求陳述是否都有其自身的優(yōu)先級。6 預(yù)期

3、讀者和閱讀建議列舉了軟件需求規(guī)格說明所針對的不同讀者，例如開發(fā)人員、項(xiàng)目經(jīng)理、營銷人員、用戶、測試人員或文檔的編寫人員。描述了文檔中剩余部分的內(nèi)容及其組織結(jié)構(gòu)。提出了最適合于每一類型讀者閱讀文檔的建議。6 產(chǎn)品的范圍提供了對指定的軟件及其目的的簡短描述，包括利益和目標(biāo)。把軟件與企業(yè)目標(biāo)或業(yè)務(wù)策略相聯(lián)系?？梢詤⒖柬?xiàng)目視圖和范圍文檔而不是將其內(nèi)容復(fù)制到這里。6 參考文獻(xiàn)列舉了編寫軟件需求規(guī)格說明時(shí)所參考的資料或其它資源。這可能包括用戶界面風(fēng)格指導(dǎo)、合同、標(biāo)準(zhǔn)、系統(tǒng)需求規(guī)格說明、使用實(shí)例文檔，或相關(guān)產(chǎn)品的軟件需求規(guī)格說明。在這里應(yīng)該給出詳細(xì)的信息，包括標(biāo)題名稱、作者、版本號、日期、出版單位或資料來源

4、，以方便讀者查閱這些文獻(xiàn)。如：a.本項(xiàng)目的經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書或合同、上級機(jī)關(guān)的批文；b.屬于本項(xiàng)目的其他已發(fā)表的文件；c.本文件中各處引用的文件、資料、包括所要用到的軟件開發(fā)標(biāo)準(zhǔn)。列出這些文件資料的標(biāo)題、文件編號、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。第2章綜合描敘這一部分概述了正在定義的產(chǎn)品以及它所運(yùn)行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設(shè)和依賴。a 產(chǎn)品的前景描述了軟件需求規(guī)格說明中所定義的產(chǎn)品的背景和起源。說明了該產(chǎn)品是否是產(chǎn)品系列中的下一成員，是否是成熟產(chǎn)品所改進(jìn)的下一代產(chǎn)品、是否是現(xiàn)有應(yīng)用程序的替代品，或者是否是一個(gè)新型的、自含型產(chǎn)品。如果軟件需求規(guī)格說明定義了大系統(tǒng)

5、的一個(gè)組成部分，那么就要說明這部分軟件是怎樣與整個(gè)系統(tǒng)相關(guān)聯(lián)的，并且要定義出兩者之間的接口。a 產(chǎn)品的功能概述了產(chǎn)品所具有的主要功能。其詳細(xì)內(nèi)容將在d中描述，所以在此只需要概略地總結(jié)，例如用列表的方法給出。很好地組織產(chǎn)品的功能，使每個(gè)讀者都易于理解。用圖形表示主要的需求分組以及它們之間的聯(lián)系，例如數(shù)據(jù)流程圖的頂層圖或類圖，都是有用的。a 用戶類和特征確定你覺得可能使用該產(chǎn)品的不同用戶類并描述它們相關(guān)的特征（見第7章）。有一些需求可能只與特定的用戶類相關(guān)。將該產(chǎn)品的重要用戶類與那些不太重要的用戶類區(qū)分開。a 運(yùn)行環(huán)境描述了軟件的運(yùn)行環(huán)境，包括硬件平臺、操作系統(tǒng)和版本，還有其它的軟件組件或與其共存

6、的應(yīng)用程序。a 設(shè)計(jì)和實(shí)現(xiàn)上的限制確定影響開發(fā)人員自由選擇的問題，并說明這些問題為什么成為一種限制?？赡艿南拗瓢ㄈ缦聝?nèi)容：a. 必須使用或者避免的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫。b. 所要求的開發(fā)規(guī)范或標(biāo)準(zhǔn)（例如，如果由客戶的公司負(fù)責(zé)軟件維護(hù)，就必須定義轉(zhuǎn)包者所使用的設(shè)計(jì)符號表示和編碼標(biāo)準(zhǔn)。c. 企業(yè)策略、政府法規(guī)或工業(yè)標(biāo)準(zhǔn)。d. 硬件限制，例如定時(shí)需求或存儲器限制。e. 數(shù)據(jù)轉(zhuǎn)換格式標(biāo)準(zhǔn)。§2.6假設(shè)和依賴確定影響開發(fā)人員自由選擇的問題，并說明這些問題為什么成為一種限制。可能的限制包括如下內(nèi)容：a. 必須使用或者避免的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫。b. 所要求的開發(fā)規(guī)范或標(biāo)

7、準(zhǔn)（例如，如果由客戶的公司負(fù)責(zé)軟件維護(hù)，就必須定義轉(zhuǎn)包者所使用的設(shè)計(jì)符號表示和編碼標(biāo)準(zhǔn)。c. 企業(yè)策略、政府法規(guī)或工業(yè)標(biāo)準(zhǔn)。d. 硬件限制，例如定時(shí)需求或存儲器限制。e. 數(shù)據(jù)轉(zhuǎn)換格式標(biāo)準(zhǔn)。第3章外部接口需求利用本節(jié)來確定可以保證新產(chǎn)品與外部組件正確連接的需求。關(guān)聯(lián)圖表示了高層抽象的外部接口。需要把對接口數(shù)據(jù)和控制組件的詳細(xì)描述寫入數(shù)據(jù)字典中。如果產(chǎn)品的不同部分有不同的外部接口，那么應(yīng)把這些外部接口的詳細(xì)需求并入到這一部分的實(shí)例中。5.2 用戶界面陳述所需要的用戶界面的軟件組件。描述每個(gè)用戶界面的邏輯特征。以下是可能要包括的一些特征：1.1.1 將要采用的圖形用戶界面（GUI）標(biāo)準(zhǔn)或產(chǎn)品系列的

8、風(fēng)格。2.2.2 屏幕布局或解決方案的限制。3.3.3 將出現(xiàn)在每個(gè)屏幕的標(biāo)準(zhǔn)按鈕、功能或?qū)Ш芥溄樱ɡ缫粋€(gè)幫助按鈕）。,快捷鍵。4.4.4 錯(cuò)誤信息顯示標(biāo)準(zhǔn)。對于用戶界面的細(xì)節(jié)，例如特定對話框的布局，應(yīng)該寫入一個(gè)獨(dú)立的用戶界面規(guī)格說明中，而不能寫入軟件需求規(guī)格說明中。5.3 硬件接口描述系統(tǒng)中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間交流的數(shù)據(jù)和控制信息的性質(zhì)以及所使用的通信協(xié)議。5.4 軟件接口描述該產(chǎn)品與其它外部組件（由名字和版本識別）的連接，包括數(shù)據(jù)庫、操作系統(tǒng)、工具、庫和集成的商業(yè)組件。明確并描述在軟件組件之間交換數(shù)據(jù)或消息的目的。描述所需要的服務(wù)以及內(nèi)部組

9、件通信的性質(zhì)。確定將在組件之間共享的數(shù)據(jù)。如果必須用一種特殊的方法來實(shí)現(xiàn)數(shù)據(jù)共享機(jī)制，例如在多任務(wù)操作系統(tǒng)中的一個(gè)全局?jǐn)?shù)據(jù)區(qū)，那么就必須把它定義為一種實(shí)現(xiàn)上的限制。5.5 通信接口Web瀏覽描述與產(chǎn)品所使用的通信功能相關(guān)的需求，包括電子郵件、器、網(wǎng)絡(luò)通信標(biāo)準(zhǔn)或協(xié)議及電子表格等等。定義了相關(guān)的消息格式。規(guī)定通信安全或加密問題、數(shù)據(jù)傳輸速率和同步通信機(jī)制。對我有用0丟個(gè)板磚0引用舉報(bào)管理TOPcsdsq(=1=0=1=0=1=0=1=)等級：#6樓得分：0回復(fù)于：2003-04-2902:18:05第4章系統(tǒng)特性功能需求是根據(jù)系統(tǒng)特性即產(chǎn)品所提供的主要服務(wù)來組織的。你可能更喜歡通過使用實(shí)例、運(yùn)行模

10、式、用戶類、對象類或功能等級來組織這部分內(nèi)容（IEEE1998）。你還可以使用這些元素的組合。總而言之，你必須選擇一種使讀者易于理解預(yù)期產(chǎn)品的組織方案。僅用簡短的語句說明特性的名稱，例如“4.1拼寫檢查和拼寫字典管理”。無論你想說明何種特性，闡述每種特性時(shí)都將重述從4.14.3這三步系統(tǒng)特性。1. 說明和優(yōu)先級提出了對該系統(tǒng)特性的簡短說明并指出該特性的優(yōu)先級是高、中，還是低?；蛘吣氵€可以包括對特定優(yōu)先級部分的評價(jià)，例如利益、損失、費(fèi)用和風(fēng)險(xiǎn)，具相對優(yōu)先等級可以從1（低）到9（高）。1. 激勵(lì)響應(yīng)序列列出輸入激勵(lì)（用戶動(dòng)作、來自外部設(shè)備的信號或其它觸發(fā)器）和定義這一特性行為的系統(tǒng)響應(yīng)序列。就像在

11、第8章討論的那樣，這些序列將與使用實(shí)例相關(guān)的對話元素相對應(yīng)。1. 功能需求詳列出與該特性相關(guān)的詳細(xì)功能需求。這些是必須提交給用戶的軟件功能，使用戶可以使用所提供的特性執(zhí)行服務(wù)或者使用所指定的使用實(shí)例執(zhí)行任務(wù)。描述產(chǎn)品如何響應(yīng)可預(yù)知的出錯(cuò)條件或者非法輸入或動(dòng)作。就像本章開頭所描述的那樣，你必須唯一地標(biāo)識每個(gè)需求。第5章其他非功能需求這部分列舉出了所有非功能需求，而不是外部接口需求和限制。b 性能需求闡述了不同的應(yīng)用領(lǐng)域?qū)Ξa(chǎn)品性能的需求，并解釋它們的原理以幫助開發(fā)人員作出合理的設(shè)計(jì)選擇。確定相互合作的用戶數(shù)或者所支持的操作、響應(yīng)時(shí)間以及與實(shí)時(shí)系統(tǒng)的時(shí)間關(guān)系。你還可以在這里定義容量需求，例如存儲器和

12、磁盤空間的需求或者存儲在數(shù)據(jù)庫中表的最大行數(shù)。盡可能詳細(xì)地確定性能需求?？赡苄枰槍γ總€(gè)功能需求或特性分別陳述其性能需求，而不是把它們都集中在一起陳述。例如，“在運(yùn)行微軟Window2000的450MHzPentiumII的計(jì)算機(jī)上，當(dāng)系統(tǒng)至少有50%的空閑資源時(shí)，95%的目錄數(shù)據(jù)庫查詢必須在兩秒內(nèi)完成”。b 安全設(shè)施需求詳盡陳述與產(chǎn)品使用過程中可能發(fā)生的損失、破壞或危害相關(guān)的需求。定義必須采取的安全保護(hù)或動(dòng)作，還有那些預(yù)防的潛在的危險(xiǎn)動(dòng)作。明確產(chǎn)品必須遵從的安全標(biāo)準(zhǔn)、策略或規(guī)則。一個(gè)安全設(shè)施需求的范例如下：“如果油箱的壓力超過了規(guī)定的最大壓力的95%,那么必須在1秒鐘內(nèi)終止操作”。b 安全性

13、需求詳盡陳述與系統(tǒng)安全性、完整性或與私人問題相關(guān)的需求，這些問題將會(huì)影響到產(chǎn)品的使用和產(chǎn)品所創(chuàng)建或使用的數(shù)據(jù)的保護(hù)。定義用戶身份確認(rèn)或授權(quán)需求。明確產(chǎn)品必須滿足的安全性或保密性策略。你可能更喜歡通過稱為完整性的質(zhì)量屬性來闡述這些需求，完整性將在第11章介紹。一個(gè)軟件系統(tǒng)的安全需求的范例如下：“每個(gè)用戶在第一次登錄后，必須更改他的最初登錄密碼。最初的登錄密碼不能重用?！?#167;5.4軟件質(zhì)量屬性詳盡陳述與客戶或開發(fā)人員至關(guān)重要的其它產(chǎn)品質(zhì)量特性（見第11章）。這些特性必須是確定、定量的并在可能時(shí)是可驗(yàn)證的。至少應(yīng)指明不同屬性的相對側(cè)重點(diǎn)，例如易用程度優(yōu)于易學(xué)程度，或者可移植性優(yōu)于有效性。2.

14、3.d 業(yè)務(wù)規(guī)則列舉出有關(guān)產(chǎn)品的所有操作規(guī)則，例如什么人在特定環(huán)境下可以進(jìn)行何種操作。這些本身不是功能需求，但它們可以暗示某些功能需求執(zhí)行這些規(guī)則。一個(gè)業(yè)務(wù)規(guī)則的范例如下：“只有持有管理員密碼的用戶才能執(zhí)行$100.00或更大額的退款操作?！?.4.d 用戶文檔列舉出將與軟件一同發(fā)行的用戶文檔部分，例如，用戶手冊、在線幫助和教程。明確所有已知的用戶文檔的交付格式或標(biāo)準(zhǔn)。第6章其他需求定義在軟件需求規(guī)格說明的其它部分未出現(xiàn)的需求，例如國際化需求或法律上的需求。你還可以增加有關(guān)操作、管理和維護(hù)部分來完善產(chǎn)品安裝、配置、啟動(dòng)和關(guān)閉、修復(fù)和容錯(cuò)，以及登錄和監(jiān)控操作等方面的需求。在模板中加入與你的項(xiàng)目相

15、關(guān)的新部分。如果你不需要增加其它需求，就省略這一部分。詞匯表定義所有必要的術(shù)語，以便讀者可以正確地解釋軟件需求規(guī)格說明，包括詞頭和縮寫。你可能希望為整個(gè)公司創(chuàng)建一張跨越多項(xiàng)項(xiàng)目的詞匯表，并且只包括特定于單一項(xiàng)目的軟件需求規(guī)格說明中的術(shù)語。分析模型這個(gè)可選部分包括或涉及到相關(guān)的分析模型的位置，例如數(shù)據(jù)流程圖、類圖、狀態(tài)轉(zhuǎn)換圖或?qū)嶓w-關(guān)系圖待確定問題列表編輯一張?jiān)谲浖枨笠?guī)格說明中待確定問題的列表，其中每一表項(xiàng)都是編上號的，以便于跟蹤調(diào)查。計(jì)算機(jī)軟件需求說明編制指南引言目的和作用本指南為軟件需求實(shí)踐提供了一個(gè)規(guī)范化的方法。本指南不提倡把軟件需求說明（SoftwareRequirementsSpec

16、ifications,以下簡稱SRS）劃分成等級，避免把它定義成更小的需求子集。本指南適用對象：軟件客戶（Customer,以便精確地描述他們想獲得什么樣的產(chǎn)品。軟件開發(fā)者（Suppliers）,以便準(zhǔn)確地理解客戶需要什么樣的產(chǎn)品。對于任一要實(shí)現(xiàn)下列目標(biāo)的單位和（或）個(gè)人：a.要提出開發(fā)規(guī)范化的SRS提綱；b.定義自己需要的具體的格式和內(nèi)容；c.產(chǎn)生附加的局部使用條款，如SRS質(zhì)量檢查清單或者SRS作者手冊等。SRS將完成下列目標(biāo)：a.在軟件產(chǎn)品完成目標(biāo)方面為客戶和開發(fā)者之間建立共同協(xié)議創(chuàng)立一個(gè)基礎(chǔ)。對要實(shí)現(xiàn)的軟件功能做全面描述，幫助客戶判斷所規(guī)定的軟件是否符合他們的要求，或者怎樣修改這種軟件

17、才能適合他們的要求；b.提高開發(fā)效率。編制SRS的過程將使客戶在設(shè)計(jì)開始之前周密地思考全部需求，從而減少事后重新設(shè)計(jì)、重新編碼和重新測試的返工活動(dòng)。在SRS中對各種需求仔細(xì)地進(jìn)行復(fù)查，還可以在開發(fā)早期發(fā)現(xiàn)若干遺漏、錯(cuò)誤的理解和不一致性，以便及時(shí)加以糾正；c.為成本計(jì)價(jià)和編制計(jì)劃進(jìn)度提供基礎(chǔ)。SRS提供的對被開發(fā)軟件產(chǎn)品的描述，是計(jì)算機(jī)軟件產(chǎn)品成本核算的基礎(chǔ)，并且可以為各方的要價(jià)和付費(fèi)提供依據(jù)。SRS對軟件的清晰描述，有助于估計(jì)所必須的資源，并用作編制進(jìn)度的依據(jù)；d.為確認(rèn)和驗(yàn)證提供一個(gè)基準(zhǔn)。任何組織將更有效地編制他們的確認(rèn)和驗(yàn)證計(jì)劃。作為開發(fā)合同的一部分，SRS還可以提供一個(gè)可以度量和遵循的基

18、準(zhǔn)（然而，反之則不成立，即任一有關(guān)軟件的合同都不能作為SRS。因?yàn)檫@種文件幾乎不包括詳盡的需求說明，并且通常不完全的）；e.便于移植。有了SRS就便于移值軟件產(chǎn)品，以適應(yīng)新的用戶或新的機(jī)種?？蛻粢惨子谝浦财滠浖狡渌块T，而開發(fā)者同樣也易于把軟件移植到新的客戶；f.作為不斷提高的基礎(chǔ)。由于SRS所討論的是軟件產(chǎn)品，而不是開發(fā)這個(gè)產(chǎn)品的設(shè)計(jì)。因此SRS是軟件產(chǎn)品繼續(xù)提高的基礎(chǔ)。雖然SRS也可能要改變，但是原來的SRS還是軟件產(chǎn)品改進(jìn)的可靠基礎(chǔ)。1.2范圍本指南適用于編寫軟件需求規(guī)格說明，它描述了一個(gè)SRS所必須的內(nèi)容和質(zhì)量，并且在第6章中提供了SRS大綱。引用標(biāo)準(zhǔn)GB8566計(jì)算機(jī)軟件開發(fā)規(guī)范G

19、B8567計(jì)算機(jī)軟件產(chǎn)品開發(fā)文件編制指南GB/T11457軟件工程術(shù)語定義GB/T11457所列術(shù)語和下列定義適用于本指南。合同（contract）是由客戶和開發(fā)者共同簽署的具有法律約束力的文件。其中包括產(chǎn)品的技術(shù)、組織、成本和進(jìn)度計(jì)劃要求等內(nèi)容?？蛻簦╟ustomer）指個(gè)人或單位，他們?yōu)楫a(chǎn)品開發(fā)提供資金，通常（但有時(shí)也不必）還提出各種需求。文件中的客戶和開發(fā)者也可能是同一個(gè)組織的成員。語言（language是具有語法和語義的通信工具，包括一組表達(dá)式、慣例和傳遞信息的有關(guān)規(guī)則。分割（partitioning）把一個(gè)整體分成若干部分。開發(fā)者（supplier）指為客戶生產(chǎn)某種軟件產(chǎn)品的個(gè)人或集

20、團(tuán)。在本指南中，客戶和開發(fā)者可能是同一個(gè)組織的成員。用戶（user）指運(yùn)行系統(tǒng)或者直接與系統(tǒng)發(fā)生交互作用的個(gè)人或集團(tuán)。用戶和客戶通常不是同些人。編寫SRS的背景信息SRS的基本要求SRS是對要完成一定功能、性能的軟件產(chǎn)品、程序或一組程序的說明。對SRS的描述有兩項(xiàng)基本要求：a.必須描述一定的功能、性能；b.必須用確定的方法敘述這些功能、性能。SRS的環(huán)境必須認(rèn)識到SRS在整個(gè)軟件開發(fā)規(guī)范（見GB8566）所規(guī)定的有關(guān)階段都起作用。正因?yàn)槿绱?，SRS的起草者必須特別注意不要超出這種作用的范圍。這意味著要滿足下列要求：SRS必須正確地定義所有的軟件需求；除了設(shè)計(jì)上的特殊限制之外，SRS中一般不描述

21、任何設(shè)計(jì)、驗(yàn)證或項(xiàng)目管理細(xì)節(jié)。SRS的特點(diǎn)無歧義性當(dāng)且僅當(dāng)它對每一個(gè)需求只有一種解釋時(shí)，SRS者是無歧義的。a.要求最終產(chǎn)品的每一個(gè)特性用某一術(shù)語描述；b.若某一術(shù)語在某一特殊的行文中使用時(shí)具有多種歧義，那么對該術(shù)語的每種含義作出解釋并指出其適用場合。需求通常是用自然語言編寫的，使用自然語言的SRS起草者必須特別注意消除其需求的歧義性。提倡使用形式化需求說明語言。完整性如果一個(gè)SRS能滿足下列要求，則該SRS就是完整的：a.包括全部有意義的要求，無論是關(guān)系到功能的、性能的、設(shè)計(jì)約束的，還是關(guān)系到屬性或外部接口方面的需求；對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應(yīng)予以定義，要對合法和非合法的輸入值的響應(yīng)做出

22、規(guī)定；要符合SRS要求。如果個(gè)別章節(jié)不適用，則在SRS中要保留章節(jié)號；填寫SRS中的全部插圖、表、圖示標(biāo)記和參照，并且定義全部術(shù)語和度量單位。4.3,2.1關(guān)于使用“待定”一詞的規(guī)定任何一個(gè)使用“待定”的SRS都是不完全的。若萬一遇到使用“待定”一詞時(shí)，作如下處理：對產(chǎn)生“待定”一詞的條件進(jìn)行描述，使得問題能被解決；描述必須干什么事，以刪除這個(gè)“待定”；包含有“待定”一詞的任何SRS的項(xiàng)目文件應(yīng)該：標(biāo)識與此特定文件有關(guān)的版本號或敘述其專門的發(fā)布號；拒絕任何仍標(biāo)識為“待定”一詞的SRS章節(jié)的許諾?？沈?yàn)證性當(dāng)且僅當(dāng)SRS中描述的每一個(gè)需求都是可以驗(yàn)證的，該SRS才是可以驗(yàn)證的；當(dāng)且僅當(dāng)在某一性能價(jià)

23、格比可取的有限處理過程，人或機(jī)器能通過該過程檢查軟件產(chǎn)品能否滿足需求時(shí)，才稱這個(gè)需求是可以驗(yàn)證的。一致性當(dāng)且僅當(dāng)SRS中各個(gè)需求的描述是不矛盾時(shí)SRS才是一致的?？尚薷男匀绻粋€(gè)SRS的結(jié)構(gòu)和風(fēng)格在需求有必要改變時(shí)是易于實(shí)現(xiàn)的、完整性的、一致的，那么這個(gè)SRS就是可以修改的?？尚薷男砸骃RS具備以下條件：a.具有一個(gè)有條不紊的易于使用的內(nèi)容組織，具有目錄表，索引和明確的交叉引用表；b.沒有冗余。即同一需求不能在SRS中出現(xiàn)多次。(1)冗余本身不是錯(cuò)誤，但是容易發(fā)生錯(cuò)誤。冗余可增加SRS的可讀性，但是在一個(gè)冗余文件被更新時(shí)容易出現(xiàn)問題。例如：假設(shè)一個(gè)明確的需求在兩個(gè)地方詳細(xì)列出，后來發(fā)現(xiàn)這個(gè)需

24、求需要改變，若只修改一個(gè)地方，于是SRS就變得不一致了。冗余是否必須，SRS一定要包含一個(gè)詳細(xì)的交叉引用表，以便SRS具備可修改性?？勺粉櫺匀绻恳粋€(gè)需求的源流是清晰的，在進(jìn)一步產(chǎn)生和改變文件編制時(shí)，可以方便地引證每一個(gè)需求，則該SRS就是可追蹤的。建議采用如下兩種類型的追蹤：a.向后追蹤(即向已開發(fā)過的前一階段追蹤)。根據(jù)先前文件或本文件前面的每一個(gè)需求進(jìn)行追蹤。b.向前追蹤(即是向由SRS派生的所有文件追蹤)。根據(jù)SRS中具有唯一的名字和參照號的每一個(gè)需求進(jìn)行追蹤。當(dāng)SRS中的一個(gè)需求表達(dá)另一個(gè)需求的一種指派或者是派生的，向前、向后的追蹤都要提供。例如：(1)從總的用戶響應(yīng)時(shí)間需求中分配給

25、數(shù)據(jù)庫操作響應(yīng)時(shí)間；(2)識別帶有一定功能和用戶接口的需求的報(bào)告格式；(3)支持法律或行政上需要的某個(gè)軟件產(chǎn)品(例如，計(jì)算稅收)。在這種情況下，要指出軟件所支持的確切的法律或行政文件。當(dāng)軟件產(chǎn)品進(jìn)入運(yùn)行和維護(hù)階段時(shí)，SRS的向前可追蹤性顯得特別重要。當(dāng)編碼和設(shè)計(jì)文件作修改時(shí)，重要的是要查清這些修改所影響的全部需求。運(yùn)行和維護(hù)階段的可使用性SRS必須滿足運(yùn)行和維護(hù)階段的需要，包括軟件最終替換。a.維護(hù)常常是由與原來開發(fā)無聯(lián)系的人來進(jìn)行的。局部的改變（修正）可以借助于好的代碼注釋來實(shí)現(xiàn)。對于較大范圍的改變。設(shè)計(jì)和需求文件是必不可少的，這里隱含了兩個(gè)作用：（1）如4.3.5條指出，SRS必須是可修改

26、的；（2）SRS中必須包括一個(gè)記錄，它記錄那些應(yīng)用于各個(gè)成分的所有具體條文。例如：它們的危急性（如故障可能危及完全或?qū)е麓罅控?cái)政方面和社會(huì)方面的損失）；它們僅與暫時(shí)的需要相關(guān)（如支持一種可立即恢復(fù)原狀的顯示）；它們的來源（如某功能是由已存在的軟件產(chǎn)品的全部拷貝復(fù)制而成）。b.要求在SRS中清楚地寫明功能的來源和目的，因?yàn)閷δ艿膩碓春鸵朐摴δ艿哪康牟磺宄脑?，通常不可能很好地完成軟件的維護(hù)。SRS的編制者軟件開發(fā)的過程是由開發(fā)者和客戶雙方同意開發(fā)什么樣的軟件協(xié)議開始的。這種協(xié)議要使用SRS的形式，應(yīng)該由雙方聯(lián)合起草。這是因?yàn)椋嚎蛻敉ǔ浖O(shè)計(jì)和開發(fā)過程了解較少，而不能寫出可用的SRS;開發(fā)

27、者通常對于客戶的問題和意圖了解較少，從而不可能寫出一個(gè)令人滿意的系統(tǒng)需求。SRS的改進(jìn)軟件產(chǎn)品的開發(fā)過程中，在項(xiàng)目的開始階段不可能詳細(xì)說明某些細(xì)節(jié)，在開發(fā)過程中可能發(fā)現(xiàn)SRS的缺陷、缺點(diǎn)和錯(cuò)誤之類的問題，所以可能要對SRS進(jìn)行改進(jìn)。在SRS的改進(jìn)中，應(yīng)注意如下事項(xiàng)：盡管可以預(yù)見校正版本的開發(fā)以后不可避免，而對需求還必須盡可能完全、清楚地描述。一旦最初識別出項(xiàng)目的變化，應(yīng)引入一個(gè)正式的改變規(guī)程來標(biāo)識、控制、追蹤和報(bào)告項(xiàng)目的改變。批準(zhǔn)了的需求改變，用如下的方法編入SRS之中：a.提供各種改變后的正確的、完全的審查記錄；b.允許對SRS當(dāng)前的和被替代部分的審查。SRS的編制工具編制SRS最顯而易見的

28、方法是用自然語言來描述。盡管自然語言是豐富多彩的,但不易精確，用形式化的方法較好。4.6.1形式化說明方法在SRS中是否使用形式化方法要依據(jù)下列因素：a.程序規(guī)模和復(fù)雜性；客戶合同中是否要求使用；SRS是否是一個(gè)合同工具或僅僅是一個(gè)內(nèi)部文件；SRS文件是否成為設(shè)計(jì)文件的根據(jù)；e.具有支持這種方法的計(jì)算機(jī)設(shè)備。生產(chǎn)工具軟件產(chǎn)品生產(chǎn)中有多種生產(chǎn)工具。比如，計(jì)算機(jī)的字處理器就是非常有用的生產(chǎn)輔助工具。一個(gè)SRS通常有若干作者?？赡芙?jīng)歷若干版本，并且要進(jìn)行多次重新組織內(nèi)容。故生產(chǎn)工具是必要的。表達(dá)工具在SRS中有許多詞匯，特別是許多名詞和動(dòng)詞，專門涉及到系統(tǒng)的實(shí)體和許多活動(dòng)，所以表達(dá)SRS需要若干工具

29、。比如：可以驗(yàn)證實(shí)體或活動(dòng)，無論在SRS中什么地方都是同一名字。；可以標(biāo)識一個(gè)特殊的實(shí)體或動(dòng)作在規(guī)格說明中的描述位置。此外，可以使用若干種形式化方法，以便允許自動(dòng)處理SRS內(nèi)容，只要作某些限制就可以做到；用一些表格或圖示法來顯示需求。用詳細(xì)分層體系自動(dòng)檢查SRS的需求，這里每一個(gè)分層自身是完全的，但是也可以擴(kuò)展為下一層，或是上一層的一個(gè)組成成分。自動(dòng)檢查SRS具有在4.3條描述的部分或全部特點(diǎn)。5軟件需求SRS中每一個(gè)軟件需求是要求開發(fā)軟件產(chǎn)品的某些基本功能和性能的一個(gè)陳述。表達(dá)軟件需求的方法軟件需求可以用若干種方法來表達(dá)：a.通過輸入、輸出說明；使用代表性的例子；用規(guī)范化的模型。輸入、輸出說

30、明用輸入輸出序列來描述一個(gè)軟件產(chǎn)品所要求的特性是很有效的。途徑根據(jù)被描述的軟件的性質(zhì)，至少有三種不同的途徑：a.有些軟件產(chǎn)品（如報(bào)表系統(tǒng)）要求著重說明輸出。一般情況下，致力于輸出的系統(tǒng)主要是在數(shù)據(jù)文卷上操作。用戶的輸入通常是致力于提供控制信息和啟動(dòng)數(shù)據(jù)文卷的處理；有些軟件產(chǎn)品需要著重說明輸入、輸出特性。關(guān)注輸入、輸出的系統(tǒng)主要是在當(dāng)前的輸入上操作，要求生成與輸入相匹配的輸出（類似于數(shù)據(jù)轉(zhuǎn)換例行程序或一個(gè)數(shù)學(xué)函數(shù)包）；還有一些系統(tǒng)（如過程控制系統(tǒng)）要求記憶它們的狀態(tài)?？梢愿鶕?jù)本次輸入和上一次輸入進(jìn)行應(yīng)答。也就是說，它的行為如同一個(gè)有限狀態(tài)機(jī)。在此種情況下，既要關(guān)注輸入/輸出對，又要關(guān)注這些輸入/

31、輸出對的次序。困難多數(shù)軟件產(chǎn)品可能接收無限的序列作為輸入，于是，為了通過輸入輸出序列完整地說明產(chǎn)品的特性，就要求SRS包括一個(gè)無限長的輸入和所需的輸出充列。然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。典型例子一種選擇是用典型例子來說明要求的特性。例如，假設(shè)一個(gè)系統(tǒng)中當(dāng)接收“0”時(shí)用“1”來回答。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型的序列可以十分清楚地理解系統(tǒng)的特性。下面是一組四種對話的典型的例子，用它描述系統(tǒng)特性。010101010101010101010101這些對話僅提供了要求的輸入和輸出之間的關(guān)系，但是不能完全描述系統(tǒng)的特性。模型另一種表達(dá)需求的方法是模型的

32、方式，這是表達(dá)復(fù)雜需求的精確和有效方法。至少可以提出三種可供使用的通用模型：數(shù)學(xué)型、功能型、計(jì)時(shí)型。應(yīng)注意區(qū)別各種模型的應(yīng)用場合，參考5.1.3.5c數(shù)學(xué)模型數(shù)學(xué)模型是使用數(shù)學(xué)關(guān)系描述軟件特性的模型。數(shù)學(xué)模型對某些特殊應(yīng)用領(lǐng)域是特別有用的。例如，導(dǎo)航、線性規(guī)劃、計(jì)量經(jīng)濟(jì)、信號處理和氣象分析等。用數(shù)學(xué)模型能夠?qū)?.1.2中所討論的典型例子描述如下：(01)*。這里，”i號表示括號內(nèi)的字符串可以重復(fù)一次或多次。功能模型功能模型是提供從略語以輸出映象的模型。象有限狀態(tài)機(jī)或Petri網(wǎng)，這些功能模型可以有助于標(biāo)識和定義軟件的各種特點(diǎn)，或者可以表示系統(tǒng)所要進(jìn)行的操作。對前面用數(shù)學(xué)模型描述的例子?？捎脠D1

33、所示的有限狀態(tài)機(jī)形式的功能模型來描述。圖中進(jìn)入的箭頭表示啟動(dòng)狀態(tài)。雙線的方框表示接收狀態(tài)。在各線記號x/y的含義是：x代表接受的輸入，而y是產(chǎn)生的輸出。計(jì)時(shí)模型計(jì)時(shí)模型是一種增加了時(shí)間限制的模型。這種模型對于表達(dá)軟件特性的形式和細(xì)節(jié)特別有用。尤其是實(shí)時(shí)系統(tǒng)或考慮人為因素的系統(tǒng)。計(jì)時(shí)模型可以把下列限制加到圖1的模型中去：激活因素0將在進(jìn)入S1狀態(tài)30S之內(nèi)出現(xiàn)；響應(yīng)1將在進(jìn)入S2狀態(tài)2s之內(nèi)出現(xiàn)。其他模型隊(duì)了上面提及的模型外。對一些特殊的應(yīng)用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統(tǒng)可以使用表格。要注意的是，對SRS使用形式需求語言，通常含有使用特殊模型的意思。警告

34、無論使用哪一類型的模型，都要：在SRS中或在SRS涉及到的一個(gè)文件中對它嚴(yán)格定義。這個(gè)定義應(yīng)該規(guī)定：模型中的參數(shù)所要求的范圍；使用時(shí)的限定值；c.結(jié)果的精確度；d.負(fù)載的能力；e.要求的執(zhí)行時(shí)間；f.缺省或失敗時(shí)的響應(yīng)。必須注意，在需求的定義域內(nèi)要保持一個(gè)模型定義。每當(dāng)一個(gè)SRS使用一個(gè)模型時(shí)：a.它意味著此模型提供一個(gè)十分有效和精確的方法說明需求；b.并不意味著軟件產(chǎn)品的實(shí)現(xiàn)必須基于這個(gè)模型。一個(gè)模型用于解釋文件所寫的需求是有效的，但是對于實(shí)際軟件的實(shí)現(xiàn)可能并不是最適宜的。軟件需求的注釋有關(guān)軟件產(chǎn)品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是對于生命攸關(guān)的應(yīng)用。而另一些可能并不

35、那么重要。SRS中每一個(gè)需求必須進(jìn)行注釋，以便區(qū)別其重要的程度。有這種方法注釋需求，可以：a.幫助客戶對每一個(gè)需求給予更周密的考慮，通?？梢栽谛枨笾谐吻咫[藏的假設(shè)；b.幫助開發(fā)者做出正確的設(shè)計(jì)決定，并對軟件產(chǎn)品不同部分作出相應(yīng)的努力。穩(wěn)定性注釋需求的一種方法是使用穩(wěn)定性量綱。當(dāng)一個(gè)需求在軟件預(yù)期的生存期間內(nèi)描述不改變的話，可以認(rèn)為該需求是穩(wěn)定的，否則可以認(rèn)為是易變的。必要性等級注釋的另一種方法是把需求分成必須保證級、期望級和任選級。a.必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受；b.期望是指這些需求將提高軟件產(chǎn)品的功能，但是如果缺省的話也是可接受的；c.任選是給開發(fā)者一個(gè)機(jī)會(huì)

36、，可以提供某些超出SRS規(guī)定的目標(biāo)。注意事項(xiàng)在注釋需求之前，必須徹底理解這種注釋的實(shí)質(zhì)性含義。在表達(dá)需求時(shí)遇到的共同弊病SRS的基本點(diǎn)是它必須說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果的手段。編寫需求的人必須描述的基本問題是：a.功能一一所設(shè)計(jì)的軟件要做什么；性能一一是指軟件功能在執(zhí)行過程中的速度、可使用性、響應(yīng)時(shí)間、各種軟件功能的恢復(fù)時(shí)間、吞吐能力、精度、頻率等等；強(qiáng)加于實(shí)現(xiàn)的設(shè)計(jì)限制一一在效果、實(shí)現(xiàn)的語言、數(shù)據(jù)庫完整性、資源限制、操作環(huán)境等等方面所要求的標(biāo)準(zhǔn)；d.屬性一一可移植性、正確性、可維護(hù)性及安全性等方面的考慮因素；e.外部接口一一與人、硬件、其他軟件和其他硬件的相互關(guān)系。編寫需求的人

37、應(yīng)當(dāng)避免把設(shè)計(jì)或項(xiàng)目需求寫入SRS之中，應(yīng)當(dāng)對說明需求設(shè)計(jì)約束與規(guī)劃設(shè)計(jì)兩者有清晰的區(qū)別。在SRS中嵌入了設(shè)計(jì)在SRS中嵌入設(shè)計(jì)說明，會(huì)過多地約束軟件設(shè)計(jì)，并且人為地把具有潛在危險(xiǎn)的需求放入SRS中。SRS必須描述在干什么數(shù)據(jù)上、為誰完成什么功能、在什么地方、產(chǎn)生什么結(jié)果。SRS應(yīng)把注意力集中在要完成的服務(wù)目標(biāo)上。通常不指定如下的設(shè)計(jì)項(xiàng)目：a.把軟件劃分成若干模塊；b.給每一個(gè)模塊分配功能；c.描述模塊間的信息流程或者控制流程；選擇數(shù)據(jù)結(jié)構(gòu)。5.3.1.2把設(shè)計(jì)完全同SRS隔離開來始終是不現(xiàn)實(shí)的。安全和保密方面的周密考慮可能增加一些直接反映設(shè)計(jì)約束的需求。例如：a.在一些分散的模塊中保持某些功

38、能;允許在程序的某些區(qū)域之間進(jìn)行有限的通訊；計(jì)算臨界值的檢查和。5.3.1.3通常應(yīng)考慮到，若要為軟件選擇高層次的設(shè)計(jì)，就可能需要大量的資源（可能占整個(gè)產(chǎn)品開發(fā)成本的10%-20%以上）。有兩種選擇：a.不顧本指南的警告，在SRS中描述了設(shè)計(jì)。這意味著，或者將一個(gè)潛在不適當(dāng)?shù)脑O(shè)計(jì)作為一個(gè)需求進(jìn)行描述（因?yàn)椋粢玫胶玫脑O(shè)計(jì)，所花費(fèi)的時(shí)間是不夠的），或者在需求階段花費(fèi)了過多的時(shí)間（因?yàn)樵赟RS完成之前整個(gè)設(shè)計(jì)分析都要完成）；b.采用本指南中5.1.3條中的建議，用模型設(shè)計(jì)描述需求，這種模型設(shè)計(jì)只用于輔助描述需求，而不使之成為實(shí)際的設(shè)計(jì)。5.3.2在SRS中嵌入了一些項(xiàng)目要求SRS應(yīng)當(dāng)是描寫一個(gè)軟

39、件產(chǎn)品，而不是描述生產(chǎn)軟件產(chǎn)品的過程。項(xiàng)目要求表達(dá)客戶和開發(fā)者之間對于軟件生產(chǎn)方面合同性事宜的理解（因此不應(yīng)當(dāng)包括在SRS中）例如：a.成本；b.交貨進(jìn)度；報(bào)表處理；軟件開發(fā)方法；質(zhì)量保證；確認(rèn)和驗(yàn)證的標(biāo)準(zhǔn)；驗(yàn)收過程。項(xiàng)目需求在另外的文件中描述。在SRS中提供的只是關(guān)于軟件產(chǎn)品本身的需求。6SRS大綱本章著重討論SRS的每一個(gè)基本部分，可以作為一個(gè)SRS的大綱。表1給出該大綱目錄，表2至表5給出大綱中第3章的具體需求內(nèi)容。各開發(fā)者和客戶應(yīng)當(dāng)根據(jù)所描述的實(shí)際情況，按本指南有關(guān)規(guī)定編寫自己的SRS。目錄前言目的范圍定義、縮寫詞、略語參考資料項(xiàng)目概述產(chǎn)品描述產(chǎn)品功能用戶特點(diǎn)一般約束假設(shè)和依據(jù)具體需求

40、（參閱本指南6.3.2條中具體需求的組織形式）附錄索引前言（SRS第1章）本章提供整個(gè)SRS綜述。目的（SRS的1.1條）在這一條包括下列內(nèi)容：描述實(shí)際SRS的目的；說明SRS所預(yù)期的讀者。范圍（SRS的1.2條）a.用一個(gè)名字標(biāo)識被生產(chǎn)的軟件產(chǎn)品。比如：xxx數(shù)據(jù)庫系統(tǒng)，報(bào)表生成程序等等；說明軟件產(chǎn)品將干什么，如果需要的話，還要說明軟件產(chǎn)品不干什么；描述所說明的軟件的應(yīng)用。應(yīng)當(dāng)：（1）盡可能精確地描述所有相關(guān)的利閃、目的、以及最終目標(biāo)。（2）如果有一個(gè)較高層次的說明存在，則應(yīng)該使其和高層次說明中的類似的陳述相一致（例如，系統(tǒng)的需求規(guī)格說明）。定義、縮寫詞、略語（SRS的1.3條）本條中必須提

41、供全部需求的術(shù)語、縮寫詞及略語的定義，以便對SRS進(jìn)行適當(dāng)?shù)慕忉尅＿@些信息可以由SRS的附錄提供。也可以參考其他的文件。參考資料（SRS的1.4條）本條應(yīng)包括：在SRS中各處參照的文件的全部清單，如經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書，上級機(jī)關(guān)批文、合同等；列出其他參考資料，如屬本項(xiàng)目的其他已發(fā)表的文件和主要文獻(xiàn)等。每一個(gè)文件、文獻(xiàn)要有標(biāo)題，索引號或文件號，發(fā)布或發(fā)表日期以及出版單位；詳細(xì)說明可以得到該參考文件的來源。這個(gè)信息可以通過引用附錄或其他文件提供。6.2項(xiàng)目概述（SRS第2章）本章應(yīng)描述影響產(chǎn)品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易于理解。產(chǎn)品描述（SRS的2.1條）這一條是把一個(gè)產(chǎn)品用其他有關(guān)的產(chǎn)品或項(xiàng)目來描述。a.如果這個(gè)產(chǎn)品是獨(dú)立的，而且全部內(nèi)容自含，應(yīng)在此說明；b.如果SRS定義的產(chǎn)品是一個(gè)較大的系統(tǒng)或項(xiàng)目中的一個(gè)組成部分，那