計(jì)算機(jī)軟件需求說明編制指南
1 引言
1.1 目的和作用
本指南為軟件需求實(shí)踐提供了一個(gè)規(guī)范化的方法。本指南不提倡把軟件需求說明（Software Requirements Specifications，以下簡(jiǎn)稱SRS）劃分成等級(jí)，避免把它定義成更小的需求子集。
本指南適用對(duì)象：
軟件客戶（Customers），以便精確地描述他們想獲得什么樣的產(chǎn)品。
軟件開發(fā)者（Suppliers），以便準(zhǔn)確地理解客戶需要什么樣的產(chǎn)品。
對(duì)于任一要實(shí)現(xiàn)下列目標(biāo)的單位和（或）個(gè)人：
a. 要提出開發(fā)規(guī)范化的SRS提綱；
b. 定義自己需要的具體的格式和內(nèi)容；
c. 產(chǎn)生附加的局部使用條款，如SRS質(zhì)量檢查清單或者SRS作者手冊(cè)等。
SRS將完成下列目標(biāo)：
a. 在軟件產(chǎn)品完成目標(biāo)方面為客戶和開發(fā)者之間建立共同協(xié)議創(chuàng)立一個(gè)基礎(chǔ)。對(duì)要實(shí)現(xiàn)的軟件功能做全面描述，幫助客戶判斷所規(guī)定的軟件是否符合他們的要求，或者怎樣修改這種軟件才能適合他們的要求；
b. 提高開發(fā)效率。編制SRS的過程將使客戶在設(shè)計(jì)開始之前周密地思考全部需求，從而減少事后重新設(shè)計(jì)、重新編碼和重新測(cè)試的返工活動(dòng)。在SRS中對(duì)各種需求仔細(xì)地進(jìn)行復(fù)查，還可以在開發(fā)早期發(fā)現(xiàn)若干遺漏、錯(cuò)誤的理解和不一致性，以便及時(shí)加以糾正；
c. 為成本計(jì)價(jià)和編制計(jì)劃進(jìn)度提供基礎(chǔ)。SRS提供的對(duì)被開發(fā)軟件產(chǎn)品的描述，是計(jì)算機(jī)軟件產(chǎn)品成本核算的基礎(chǔ)，并且可以為各方的要價(jià)和付費(fèi)提供依據(jù)。SRS對(duì)軟件的清晰描述，有助于估計(jì)所必須的資源，并用作編制進(jìn)度的依據(jù)；
d. 為確認(rèn)和驗(yàn)證提供一個(gè)基準(zhǔn)。任何組織將更有效地編制他們的確認(rèn)和驗(yàn)證計(jì)劃。作為開發(fā)合同的一部分，SRS還可以提供一個(gè)可以度量和遵循的基準(zhǔn)（然而，反之則不成立，即任一有關(guān)軟件的合同都不能作為SRS。因?yàn)檫@種文件幾乎不包括詳盡的需求說明，并且通常不完全的）；
e. 便于移植。有了SRS就便于移值軟件產(chǎn)品，以適應(yīng)新的用戶或新的機(jī)種。客戶也易于移植其軟件到其他部門，而開發(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大綱。
2 引用標(biāo)準(zhǔn)
GB 8566 計(jì)算機(jī)軟件開發(fā)規(guī)范
GB 8567 計(jì)算機(jī)軟件產(chǎn)品開發(fā)文件編制指南
GB/T 11457 軟件工程術(shù)語
3 定義
GB/T 11457所列術(shù)語和下列定義適用于本指南。
合同（contract）
是由客戶和開發(fā)者共同簽署的具有法律約束力的文件。其中包括產(chǎn)品的技術(shù)、組織、成本和進(jìn)度計(jì)劃要求等內(nèi)容。
客戶（customer）
指?jìng)€(gè)人或單位，他們?yōu)楫a(chǎn)品開發(fā)提供資金，通常（但有時(shí)也不必）還提出各種需求。文件中的客戶和開發(fā)者也可能是同一個(gè)組織的成員。
語言（language）
是具有語法和語義的通信工具，包括一組表達(dá)式、慣例和傳遞信息的有關(guān)規(guī)則。
分割（partitioning）
把一個(gè)整體分成若干部分。
開發(fā)者（supplier）
指為客戶生產(chǎn)某種軟件產(chǎn)品的個(gè)人或集團(tuán)。在本指南中，客戶和開發(fā)者可能是同一個(gè)組織的成員。
用戶（user）
指運(yùn)行系統(tǒng)或者直接與系統(tǒng)發(fā)生交互作用的個(gè)人或集團(tuán)。用戶和客戶通常不是同一些人。
4 編寫SRS的背景信息
4.1 SRS的基本要求
SRS是對(duì)要完成一定功能、性能的軟件產(chǎn)品、程序或一組程序的說明。
對(duì)SRS的描述有兩項(xiàng)基本要求：
a. 必須描述一定的功能、性能；
b. 必須用確定的方法敘述這些功能、性能。
4.2 SRS的環(huán)境
必須認(rèn)識(shí)到SRS在整個(gè)軟件開發(fā)規(guī)范（見GB 8566）所規(guī)定的有關(guān)階段都起作用。正因?yàn)槿绱?，SRS的起草者必須特別注意不要超出這種作用的范圍。這意味著要滿足下列要求：
a. SRS必須正確地定義所有的軟件需求；
b. 除了設(shè)計(jì)上的特殊限制之外，SRS中一般不描述任何設(shè)計(jì)、驗(yàn)證或項(xiàng)目管理細(xì)節(jié)。
4.3 SRS的特點(diǎn)
4.3.1 無歧義性
當(dāng)且僅當(dāng)它對(duì)每一個(gè)需求只有一種解釋時(shí)，SRS者是無歧義的。
a. 要求最終產(chǎn)品的每一個(gè)特性用某一術(shù)語描述；
b. 若某一術(shù)語在某一特殊的行文中使用時(shí)具有多種歧義，那么對(duì)該術(shù)語的每種含義作出解釋并指出其適用場(chǎng)合。
需求通常是用自然語言編寫的，使用自然語言的SRS起草者必須特別注意消除其需求的歧義性。提倡使用形式化需求說明語言。
4.3.2 完整性
如果一個(gè)SRS能滿足下列要求，則該SRS就是完整的：
a. 包括全部有意義的要求，無論是關(guān)系到功能的、性能的、設(shè)計(jì)約束的，還是關(guān)系到屬性或外部接口方面的需求；
b. 對(duì)所有可能出現(xiàn)的輸入數(shù)據(jù)的響應(yīng)予以定義，要對(duì)合法和非合法的輸入值的響應(yīng)做出規(guī)定；
c. 要符合SRS要求。如果個(gè)別章節(jié)不適用，則在SRS中要保留章節(jié)號(hào)；
d. 填寫SRS中的全部插圖、表、圖示標(biāo)記和參照，并且定義全部術(shù)語和度量單位。
4.3.2.1 關(guān)于使用“待定”一詞的規(guī)定
任何一個(gè)使用“待定”的SRS都是不完全的。
a. 若萬一遇到使用“待定”一詞時(shí)，作如下處理：
（1） 對(duì)產(chǎn)生“待定”一詞的條件進(jìn)行描述，使得問題能被解決；
（2） 描述必須干什么事，以刪除這個(gè)“待定”；
b. 包含有“待定”一詞的任何SRS的項(xiàng)目文件應(yīng)該：
（1） 標(biāo)識(shí)與此特定文件有關(guān)的版本號(hào)或敘述其專門的發(fā)布號(hào)；
（2） 拒絕任何仍標(biāo)識(shí)為“待定”一詞的SRS章節(jié)的許諾。
4.3.3 可驗(yàn)證性
當(dāng)且僅當(dāng)SRS中描述的每一個(gè)需求都是可以驗(yàn)證的，該SRS才是可以驗(yàn)證的；當(dāng)且僅當(dāng)在某一性能價(jià)格比可取的有限處理過程，人或機(jī)器能通過該過程檢查軟件產(chǎn)品能否滿足需求時(shí)，才稱這個(gè)需求是可以驗(yàn)證的。
4.3.4 一致性
當(dāng)且僅當(dāng)SRS中各個(gè)需求的描述是不矛盾時(shí)SRS才是一致的。
4.3.5 可修改性
如果一個(gè)SRS的結(jié)構(gòu)和風(fēng)格在需求有必要改變時(shí)是易于實(shí)現(xiàn)的、完整性的、一致的，那么這個(gè)SRS就是可以修改的。可修改性要求SRS具備以下條件：
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è)需求需要改變，若只修改一個(gè)地方，于是SRS就變得不一致了。
（2）不管冗余是否必須，SRS一定要包含一個(gè)詳細(xì)的交叉引用表，以便SRS具備可修改性。
4.3.6 可追蹤性
如果每一個(gè)需求的源流是清晰的，在進(jìn)一步產(chǎn)生和改變文件編制時(shí)，可以方便地引證每一個(gè)需求，則該SRS就是可追蹤的。建議采用如下兩種類型的追蹤：
a. 向后追蹤（即向已開發(fā)過的前一階段追蹤）。根據(jù)先前文件或本文件前面的每一個(gè)需求進(jìn)行追蹤。
b. 向前追蹤（即是向由SRS派生的所有文件追蹤）。根據(jù)SRS中具有唯一的名字和參照號(hào)的每一個(gè)需求進(jìn)行追蹤。
當(dāng)SRS中的一個(gè)需求表達(dá)另一個(gè)需求的一種指派或者是派生的，向前、向后的追蹤都要提供。例如：
（1）從總的用戶響應(yīng)時(shí)間需求中分配給數(shù)據(jù)庫(kù)操作響應(yīng)時(shí)間；
（2）識(shí)別帶有一定功能和用戶接口的需求的報(bào)告格式；
（3）支持法律或行政上需要的某個(gè)軟件產(chǎn)品（例如，計(jì)算稅收）。在這種情況下，要指出軟件所支持的確切的法律或行政文件。
當(dāng)軟件產(chǎn)品進(jìn)入運(yùn)行和維護(hù)階段時(shí)，SRS的向前可追蹤性顯得特別重要。當(dāng)編碼和設(shè)計(jì)文件作修改時(shí)，重要的是要查清這些修改所影響的全部需求。
4.3.7 運(yùn)行和維護(hù)階段的可使用性
SRS必須滿足運(yùn)行和維護(hù)階段的需要，包括軟件最終替換。
a. 維護(hù)常常是由與原來開發(fā)無聯(lián)系的人來進(jìn)行的。局部的改變（修正）可以借助于好的代碼注釋來實(shí)現(xiàn)。對(duì)于較大范圍的改變。設(shè)計(jì)和需求文件是必不可少的，這里隱含了兩個(gè)作用：
（1）如4.3.5 條指出，SRS必須是可修改的；
（2）SRS中必須包括一個(gè)記錄，它記錄那些應(yīng)用于各個(gè)成分的所有具體條文。例如：
它們的危急性（如故障可能危及完全或?qū)е麓罅控?cái)政方面和社會(huì)方面的損失）；
它們僅與暫時(shí)的需要相關(guān)（如支持一種可立即恢復(fù)原狀的顯示）；
它們的來源（如某功能是由已存在的軟件產(chǎn)品的全部拷貝復(fù)制而成）。
b. 要求在SRS中清楚地寫明功能的來源和目的，因?yàn)閷?duì)功能的來源和引入該功能的目的不清楚的話，通常不可能很好地完成軟件的維護(hù)。
4.4 SRS的編制者
軟件開發(fā)的過程是由開發(fā)者和客戶雙方同意開發(fā)什么樣的軟件協(xié)議開始的。這種協(xié)議要使用SRS的形式，應(yīng)該由雙方聯(lián)合起草。這是因?yàn)椋?
a. 客戶通常對(duì)軟件設(shè)計(jì)和開發(fā)過程了解較少，而不能寫出可用的SRS；
b. 開發(fā)者通常對(duì)于客戶的問題和意圖了解較少，從而不可能寫出一個(gè)令人滿意的系統(tǒng)需求。
4.5 SRS的改進(jìn)
軟件產(chǎn)品的開發(fā)過程中，在項(xiàng)目的開始階段不可能詳細(xì)說明某些細(xì)節(jié)，在開發(fā)過程中可能發(fā)現(xiàn)SRS的缺陷、缺點(diǎn)和錯(cuò)誤之類的問題，所以可能要對(duì)SRS進(jìn)行改進(jìn)。
在SRS的改進(jìn)中，應(yīng)注意如下事項(xiàng)：
4.5.1 盡管可以預(yù)見校正版本的開發(fā)以后不可避免，而對(duì)需求還必須盡可能完全、清楚地描述。
4.5.2 一旦最初識(shí)別出項(xiàng)目的變化，應(yīng)引入一個(gè)正式的改變規(guī)程來標(biāo)識(shí)、控制、追蹤和報(bào)告項(xiàng)目的改變。批準(zhǔn)了的需求改變，用如下的方法編入SRS之中：
a. 提供各種改變后的正確的、完全的審查記錄；
b. 允許對(duì)SRS當(dāng)前的和被替代部分的審查。
4.6 SRS的編制工具
編制SRS最顯而易見的方法是用自然語言來描述。盡管自然語言是豐富多彩的，但不易精確，用形式化的方法較好。
4.6.1 形式化說明方法
在SRS中是否使用形式化方法要依據(jù)下列因素：
a. 程序規(guī)模和復(fù)雜性；
b. 客戶合同中是否要求使用；
c. SRS是否是一個(gè)合同工具或僅僅是一個(gè)內(nèi)部文件；
d. SRS文件是否成為設(shè)計(jì)文件的根據(jù)；
e. 具有支持這種方法的計(jì)算機(jī)設(shè)備。
4.6.2 生產(chǎn)工具
軟件產(chǎn)品生產(chǎn)中有多種生產(chǎn)工具。比如，計(jì)算機(jī)的字處理器就是非常有用的生產(chǎn)輔助工具。一個(gè)SRS通常有若干作者?？赡芙?jīng)歷若干版本，并且要進(jìn)行多次重新組織內(nèi)容。故生產(chǎn)工具是必要的。
4.6.3 表達(dá)工具
在SRS中有許多詞匯，特別是許多名詞和動(dòng)詞，專門涉及到系統(tǒng)的實(shí)體和許多活動(dòng)，所以表達(dá)SRS需要若干工具。比如：
a. 可以驗(yàn)證實(shí)體或活動(dòng)，無論在SRS中什么地方都是同一名字。；
b. 可以標(biāo)識(shí)一個(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è)陳述。
5.1 表達(dá)軟件需求的方法
軟件需求可以用若干種方法來表達(dá)：
a. 通過輸入、輸出說明；
b. 使用代表性的例子；
c. 用規(guī)范化的模型。
5.1.1 輸入、輸出說明
用輸入輸出序列來描述一個(gè)軟件產(chǎn)品所要求的特性是很有效的。
5.1.1.1 途徑
根據(jù)被描述的軟件的性質(zhì)，至少有三種不同的途徑：
a. 有些軟件產(chǎn)品（如報(bào)表系統(tǒng)）要求著重說明輸出。一般情況下，致力于輸出的系統(tǒng)主要是在數(shù)據(jù)文卷上操作。用戶的輸入通常是致力于提供控制信息和啟動(dòng)數(shù)據(jù)文卷的處理；
b. 有些軟件產(chǎn)品需要著重說明輸入、輸出特性。關(guān)注輸入、輸出的系統(tǒng)主要是在當(dāng)前的輸入上操作，要求生成與輸入相匹配的輸出（類似于數(shù)據(jù)轉(zhuǎn)換例行程序或一個(gè)數(shù)學(xué)函數(shù)包）；
c. 還有一些系統(tǒng)（如過程控制系統(tǒng)）要求記憶它們的狀態(tài)。可以根據(jù)本次輸入和上一次輸入進(jìn)行應(yīng)答。也就是說，它的行為如同一個(gè)有限狀態(tài)機(jī)。在此種情況下，既要關(guān)注輸入/輸出對(duì)，又要關(guān)注這些輸入/輸出對(duì)的次序。
5.1.1.2 困難
多數(shù)軟件產(chǎn)品可能接收無限的序列作為輸入，于是，為了通過輸入輸出序列完整地說明產(chǎn)品的特性，就要求SRS包括一個(gè)無限長(zhǎng)的輸入和所需的輸出充列。然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。
5.1.2 典型例子
一種選擇是用典型例子來說明要求的特性。例如，假設(shè)一個(gè)系統(tǒng)中當(dāng)接收“0”時(shí)用“1”來回答。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型的序列可以十分清楚地理解系統(tǒng)的特性。下面是一組四種對(duì)話的典型的例子，用它描述系統(tǒng)特性。
0101
010101010101
01
010101
這些對(duì)話僅提供了要求的輸入和輸出之間的關(guān)系，但是不能完全描述系統(tǒng)的特性。
5.1.3 模型
另一種表達(dá)需求的方法是模型的方式，這是表達(dá)復(fù)雜需求的精確和有效方法。
至少可以提出三種可供使用的通用模型：數(shù)學(xué)型、功能型、計(jì)時(shí)型。
應(yīng)注意區(qū)別各種模型的應(yīng)用場(chǎng)合，參考5.1.3.5。
5.1.3.1 數(shù)學(xué)模型
數(shù)學(xué)模型是使用數(shù)學(xué)關(guān)系描述軟件特性的模型。數(shù)學(xué)模型對(duì)某些特殊應(yīng)用領(lǐng)域是特別有用的。例如，導(dǎo)航、線性規(guī)劃、計(jì)量經(jīng)濟(jì)、信號(hào)處理和氣象分析等。
用數(shù)學(xué)模型能夠?qū)?span lang="EN-US">5.1.2中所討論的典型例子描述如下：
（01）*。
這里，“*”號(hào)表示括號(hào)內(nèi)的字符串可以重復(fù)一次或多次。
5.1.3.2 功能模型
功能模型是提供從略語以輸出映象的模型。象有限狀態(tài)機(jī)或Petri網(wǎng)，這些功能模型可以有助于標(biāo)識(shí)和定義軟件的各種特點(diǎn)，或者可以表示系統(tǒng)所要進(jìn)行的操作。
對(duì)前面用數(shù)學(xué)模型描述的例子?？捎脠D1所示的有限狀態(tài)機(jī)形式的功能模型來描述。圖中進(jìn)入的箭頭表示啟動(dòng)狀態(tài)。雙線的方框表示接收狀態(tài)。在各線記號(hào)x/y的含義是：x代表接受的輸入，而y是產(chǎn)生的輸出。
5.1.3.3 計(jì)時(shí)模型
計(jì)時(shí)模型是一種增加了時(shí)間限制的模型。這種模型對(duì)于表達(dá)軟件特性的形式和細(xì)節(jié)特別有用。尤其是實(shí)時(shí)系統(tǒng)或考慮人為因素的系統(tǒng)。
計(jì)時(shí)模型可以把下列限制加到圖1的模型中去：
a. 激活因素0將在進(jìn)入S1狀態(tài)30S之內(nèi)出現(xiàn)；
b. 響應(yīng)1將在進(jìn)入S2狀態(tài)2S之內(nèi)出現(xiàn)。
5.1.3.4 其他模型
隊(duì)了上面提及的模型外。對(duì)一些特殊的應(yīng)用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統(tǒng)可以使用表格。要注意的是，對(duì)SRS使用形式需求語言，通常含有使用特殊模型的意思。
5.1.3.5 警告
無論使用哪一類型的模型，都要：
在SRS中或在SRS涉及到的一個(gè)文件中對(duì)它嚴(yán)格定義。這個(gè)定義應(yīng)該規(guī)定：
a. 模型中的參數(shù)所要求的范圍；
b. 使用時(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è)模型用于解釋文件所寫的需求是有效的，但是對(duì)于實(shí)際軟件的實(shí)現(xiàn)可能并不是最適宜的。
5.2 軟件需求的注釋
有關(guān)軟件產(chǎn)品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是對(duì)于生命攸關(guān)的應(yīng)用。而另一些可能并不那么重要。
SRS中每一個(gè)需求必須進(jìn)行注釋，以便區(qū)別其重要的程度。
有這種方法注釋需求，可以：
a. 幫助客戶對(duì)每一個(gè)需求給予更周密的考慮，通?？梢栽谛枨笾谐吻咫[藏的假設(shè)；
b. 幫助開發(fā)者做出正確的設(shè)計(jì)決定，并對(duì)軟件產(chǎn)品不同部分作出相應(yīng)的努力。
5.2.1 穩(wěn)定性
注釋需求的一種方法是使用穩(wěn)定性量綱。當(dāng)一個(gè)需求在軟件預(yù)期的生存期間內(nèi)描述不改變的話，可以認(rèn)為該需求是穩(wěn)定的，否則可以認(rèn)為是易變的。
5.2.2 必要性等級(jí)
注釋的另一種方法是把需求分成必須保證級(jí)、期望級(jí)和任選級(jí)。
a. 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受；
b. 期望是指這些需求將提高軟件產(chǎn)品的功能，但是如果缺省的話也是可接受的；
c. 任選是給開發(fā)者一個(gè)機(jī)會(huì)，可以提供某些超出SRS規(guī)定的目標(biāo)。
5.2.3 注意事項(xiàng)
在注釋需求之前，必須徹底理解這種注釋的實(shí)質(zhì)性含義。
5.3 在表達(dá)需求時(shí)遇到的共同弊病
SRS的基本點(diǎn)是它必須說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果的手段。
編寫需求的人必須描述的基本問題是：
a. 功能——所設(shè)計(jì)的軟件要做什么；
b. 性能——是指軟件功能在執(zhí)行過程中的速度、可使用性、響應(yīng)時(shí)間、各種軟件功能的恢復(fù)時(shí)間、吞吐能力、精度、頻率等等；
c. 強(qiáng)加于實(shí)現(xiàn)的設(shè)計(jì)限制——在效果、實(shí)現(xiàn)的語言、數(shù)據(jù)庫(kù)完整性、資源限制、操作環(huán)境等等方面所要求的標(biāo)準(zhǔn)；
d. 屬性——可移植性、正確性、可維護(hù)性及安全性等方面的考慮因素；
e. 外部接口——與人、硬件、其他軟件和其他硬件的相互關(guān)系。
編寫需求的人應(yīng)當(dāng)避免把設(shè)計(jì)或項(xiàng)目需求寫入SRS之中，應(yīng)當(dāng)對(duì)說明需求設(shè)計(jì)約束與規(guī)劃設(shè)計(jì)兩者有清晰的區(qū)別。
5.3.1 在SRS中嵌入了設(shè)計(jì)
在SRS中嵌入設(shè)計(jì)說明，會(huì)過多地約束軟件設(shè)計(jì)，并且人為地把具有潛在危險(xiǎn)的需求放入SRS中。
5.3.1.1 SRS必須描述在干什么數(shù)據(jù)上、為誰完成什么功能、在什么地方、產(chǎn)生什么結(jié)果。SRS應(yīng)把注意力集中在要完成的服務(wù)目標(biāo)上。通常不指定如下的設(shè)計(jì)項(xiàng)目：
a. 把軟件劃分成若干模塊；
b. 給每一個(gè)模塊分配功能；
c. 描述模塊間的信息流程或者控制流程；
d. 選擇數(shù)據(jù)結(jié)構(gòu)。
5.3.1.2 把設(shè)計(jì)完全同SRS隔離開來始終是不現(xiàn)實(shí)的。安全和保密方面的周密考慮可能增加一些直接反映設(shè)計(jì)約束的需求。例如：
a. 在一些分散的模塊中保持某些功能；
b. 允許在程序的某些區(qū)域之間進(jìn)行有限的通訊；
c. 計(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)?，若要得到好的設(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è)軟件產(chǎn)品，而不是描述生產(chǎn)軟件產(chǎn)品的過程。
項(xiàng)目要求表達(dá)客戶和開發(fā)者之間對(duì)于軟件生產(chǎn)方面合同性事宜的理解（因此不應(yīng)當(dāng)包括在SRS中）例如：
a. 成本；
b. 交貨進(jìn)度；
c. 報(bào)表處理；
d. 軟件開發(fā)方法；
e. 質(zhì)量保證；
f. 確認(rèn)和驗(yàn)證的標(biāo)準(zhǔn)；
g. 驗(yàn)收過程。
項(xiàng)目需求在另外的文件中描述。在SRS中提供的只是關(guān)于軟件產(chǎn)品本身的需求。
6 SRS大綱
本章著重討論SRS的每一個(gè)基本部分，可以作為一個(gè)SRS的大綱。表1給出該大綱目錄，表2至表5給出大綱中第3章的具體需求內(nèi)容。各開發(fā)者和客戶應(yīng)當(dāng)根據(jù)所描述的實(shí)際情況，按本指南有關(guān)規(guī)定編寫自己的SRS。
1 前言
1.1 目的
1.2 范圍
1.3 定義、縮寫詞、略語
1.4 參考資料
2 項(xiàng)目概述
2.1 產(chǎn)品描述
2.2 產(chǎn)品功能
2.3 用戶特點(diǎn)
2.4 一般約束
2.5 假設(shè)和依據(jù)
3 具體需求
（參閱本指南6.3.2 條中具體需求的組織形式）
附錄
索引
6.1 前言（SRS第1章）
本章提供整個(gè)SRS綜述。
6.1.1 目的（SRS的1.1條）
在這一條包括下列內(nèi)容：
a. 描述實(shí)際SRS的目的；
b. 說明SRS所預(yù)期的讀者。
6.1.2 范圍（SRS的1.2條）
a. 用一個(gè)名字標(biāo)識(shí)被生產(chǎn)的軟件產(chǎn)品。比如：×××數(shù)據(jù)庫(kù)系統(tǒng)，報(bào)表生成程序等等；
b. 說明軟件產(chǎn)品將干什么，如果需要的話，還要說明軟件產(chǎn)品不干什么；
c. 描述所說明的軟件的應(yīng)用。應(yīng)當(dāng)：
（1）盡可能精確地描述所有相關(guān)的利閃、目的、以及最終目標(biāo)。
（2）如果有一個(gè)較高層次的說明存在，則應(yīng)該使其和高層次說明中的類似的陳述相一致（例如，系統(tǒng)的需求規(guī)格說明）。
6.1.3 定義、縮寫詞、略語（SRS的1.3條）
本條中必須提供全部需求的術(shù)語、縮寫詞及略語的定義，以便對(duì)SRS進(jìn)行適當(dāng)?shù)慕忉?。這些信息可以由SRS的附錄提供。也可以參考其他的文件。
6.1.4 參考資料（SRS的1.4條）
本條應(yīng)包括：
a. 在SRS中各處參照的文件的全部清單，如經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書，上級(jí)機(jī)關(guān)批文、合同等；
b. 列出其他參考資料，如屬本項(xiàng)目的其他已發(fā)表的文件和主要文獻(xiàn)等。每一個(gè)文件、文獻(xiàn)要有標(biāo)題，索引號(hào)或文件號(hào)，發(fā)布或發(fā)表日期以及出版單位；
c. 詳細(xì)說明可以得到該參考文件的來源。這個(gè)信息可以通過引用附錄或其他文件提供。
6.2 項(xiàng)目概述（SRS第2章）
本章應(yīng)描述影響產(chǎn)品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易于理解。
6.2.1 產(chǎn)品描述（SRS的2.1條）
這一條是把一個(gè)產(chǎn)品用其他有關(guān)的產(chǎn)品或項(xiàng)目來描述。
a. 如果這個(gè)產(chǎn)品是獨(dú)立的，而且全部?jī)?nèi)容自含，應(yīng)在此說明；
b. 如果SRS定義的產(chǎn)品是一個(gè)較大的系統(tǒng)或項(xiàng)目中的一個(gè)組成部分，那么本條應(yīng)包括如下內(nèi)容：
（1）要概述這個(gè)較大的系統(tǒng)或項(xiàng)目的每一個(gè)組成部分的功能，并說明其接口；
（2）指出該軟件產(chǎn)品主要的外部接口。在這里，不要求對(duì)接口詳細(xì)地描述，詳細(xì)描述放在SRS其他章條中；
（3）描述所使用的計(jì)算機(jī)硬件、外圍設(shè)備。這里僅僅是一個(gè)綜述性描述。
在本條的描述中，用一個(gè)方框圖來表達(dá)一個(gè)較大的系統(tǒng)或項(xiàng)目的主要組成部分、相互聯(lián)系和外部接口是非常有幫助的。
本條既不用來強(qiáng)迫進(jìn)行設(shè)計(jì)方案的描述，也不是描述在解決問題時(shí)的設(shè)計(jì)約束。本條應(yīng)對(duì)在以后具體需求一章中說明的設(shè)計(jì)約束提供理由。
6.2.2 產(chǎn)品功能（SRS的2.2條）
本條是為將要完成的軟件功能提供一個(gè)摘要。例如，對(duì)于一個(gè)記帳程序來說，SRS可以用這部分來描述：客戶帳目維護(hù)、客戶財(cái)務(wù)報(bào)表和發(fā)票制作，而不必把功能所要求的大量的細(xì)節(jié)描寫出來。
有時(shí)，如果存在較高層次的規(guī)格說明時(shí)，則功能摘要可直接從中取得，這個(gè)較高層次的規(guī)格說明為軟件產(chǎn)品分配了特殊的功能，為了清晰起見，請(qǐng)注意：
a. 編制功能的一種方法是制作功能表，以便客戶或者第一次讀這個(gè)文件的人都可以理解；
b. 用方框圖來表達(dá)不同的功能和它們的關(guān)系也是有幫助的。但要牢記，這樣的圖不是產(chǎn)品設(shè)計(jì)時(shí)所需求的，而只是一種有效的解釋性的工具。
這一條不用作陳述具體需求，只是對(duì)后來SRS中具體需求一章中為什么要描述的某些需求提供理由。
6.2.3 用戶特點(diǎn)（SRS的2.3條）
本條要描述影響具體需求的產(chǎn)品的最終用戶的一般特點(diǎn)。
許多人在軟件生存周期的操作和維護(hù)階段與系統(tǒng)相關(guān)。而這些人中有用戶、操作員、維護(hù)人員和系統(tǒng)工作人員。這些人的某些特點(diǎn)，象教育水平、經(jīng)驗(yàn)、技術(shù)、專長(zhǎng)等，都是施加于系統(tǒng)操作環(huán)境的重要約束。
如果系統(tǒng)的大多數(shù)用戶是一些臨時(shí)用戶，那么就要求系統(tǒng)包含如何完成基本功能的提示，而不是假設(shè)用戶已經(jīng)從過去的會(huì)議或從閱讀用戶指南中了解到這些細(xì)節(jié)。
這一條的內(nèi)容不能用來陳述具體需求或強(qiáng)加若干特殊的設(shè)計(jì)約束，本條應(yīng)對(duì)在SRS的具體需求一章之中的某些具體需求或設(shè)計(jì)約束的描述提供理由。
6.2.4 一般約束（SRS的2.4條）
本條對(duì)設(shè)計(jì)系統(tǒng)陽限制開發(fā)者選擇的其他一些項(xiàng)作一般性描述。而這些項(xiàng)將限定開發(fā)者在設(shè)計(jì)系統(tǒng)時(shí)的任選項(xiàng)。這些包括：
a. 管理方針；
b. 硬件的限制；
c. 與其他應(yīng)用間的接口；
d. 并行操作；
e. 審查功能；
f. 控制功能；
g. 所需的高級(jí)語言；
h. 通信協(xié)議；
i. 應(yīng)用的臨界點(diǎn)；
j. 安全和保密方面的考慮。
本條不陳述具體需求或具體設(shè)計(jì)約束：而對(duì)SRS的具體需求一章中為 什么要確定某些具體需求和設(shè)計(jì)約束提供理由。
6.2.5 假設(shè)和依據(jù)（SRS的2.5條）
本條列出影響SRS中陳述的需求的每一個(gè)因素。這些因素不是軟件的設(shè)計(jì)約束，但是它們的改變可能影響到SRS中的需求。例如：假定一個(gè)特定的操作系統(tǒng)是在被軟件產(chǎn)品指定的硬件上使用的，然而，事實(shí)上這個(gè)操作系統(tǒng)是不可能使用的，于是，SRS就要進(jìn)行相應(yīng)的改變。
6.3 具體需求（SRS的第3章）
本章應(yīng)包括軟件開發(fā)者在建立設(shè)計(jì)時(shí)需要的全部細(xì)節(jié)。這是SRS中篇幅最大和最重要的部分。
a. 根據(jù)本指南第4章所規(guī)定的準(zhǔn)則（如可驗(yàn)證性、無歧義性等），對(duì)每一個(gè)需求細(xì)節(jié)作具體描述；
b. 在SRS的前言、項(xiàng)目概述、附錄部分的有關(guān)討論中，要提供對(duì)任何一個(gè)具體需求交叉引用的背景；
c. 具體需求分類的方法如下：
（1）功能需求；
（2）性能需求；
（3）設(shè)計(jì)約束；
（4）屬性；
（5）外部接口需求。
本章中要注意的二點(diǎn)是：
a. 按符合邏輯的和可讀的方式組織；
b. 詳細(xì)描述每一個(gè)需求，使得該需求應(yīng)達(dá)到目標(biāo)能夠用指定的方法進(jìn)行客觀的驗(yàn)證。
6.3.1 具體需求的內(nèi)容
6.3.1.1 功能需求
本條描述軟件產(chǎn)品的輸入怎樣變換成輸出。即軟件必須完成的基本動(dòng)作。
對(duì)于每一類功能或者有時(shí)對(duì)于每一個(gè)功能，需要具體描述其輸入、加工和輸出的需求。這通常由四個(gè)部頒組成：
a. 引言
這部分描述的是功能要達(dá)到的目標(biāo)、所采用的方法和技術(shù)，還應(yīng)清楚說明功能意圖的由來和背景。
b. 輸入
這部分應(yīng)包括：
（1）詳細(xì)描述該功能的所有輸入數(shù)據(jù)，如：
輸入源、數(shù)量、度量單位、時(shí)間設(shè)定、有效輸入范圍（包括精度和公差）；
（2）操作員控制細(xì)節(jié)的需求。其中有名字、操作員活動(dòng)的描述、控制臺(tái)或操作員的位置。例如：當(dāng)打印檢查時(shí)，要求操作員進(jìn)行格式調(diào)整；
（3）指明引用接口說明或接口控制文件的參考資料。
c. 加工
定義輸入數(shù)據(jù)、中間參數(shù)，以獲得預(yù)期輸出結(jié)果的全部操作。它包括如下的說明：
（1）輸入數(shù)據(jù)的有效性檢查；
（2）操作的順序，包括事件的時(shí)間設(shè)定；
（3）異常情況的響應(yīng)，例如，溢出、通信故障、錯(cuò)誤處理等；
（4）受操作影響的參數(shù)；
（5）降級(jí)運(yùn)行的要求；
（6）用于把系統(tǒng)輸入變換成相應(yīng)輸出的任何方法（方程式、數(shù)學(xué)算法、邏輯操作等）；
（7）輸出數(shù)據(jù)的有效性檢查。
d. 輸出
這部分應(yīng)包括：
（1）詳細(xì)描述該功能所有輸出數(shù)據(jù)，例如：輸出目的地、數(shù)量、度量單位、時(shí)間關(guān)系、有效輸出的范圍（包括精度和公差）、非法值的處理、出錯(cuò)信息；
（2）有關(guān)接口說明或接口控制文件的參考資料。
此外，對(duì)著重于輸入輸出行為的系統(tǒng)來說，SRS應(yīng)指定所有有意義的輸入、輸出對(duì)及其序列。當(dāng)一個(gè)系統(tǒng)要求記憶它的狀態(tài)時(shí)，需要這個(gè)序列，使得它可以根據(jù)本次輸入和以前的狀態(tài)作出響應(yīng)。也就是說，這種情況猶如有限狀態(tài)機(jī)。 6.3.1.3 設(shè)計(jì)約束
設(shè)計(jì)約束受其他標(biāo)準(zhǔn)、硬件限制等方面的影響。
6.3.1.3.1 其他標(biāo)準(zhǔn)的約束
本項(xiàng)將指定由現(xiàn)有的標(biāo)準(zhǔn)或規(guī)則派生的要求。例如：
a. 報(bào)表格式；
b. 數(shù)據(jù)命名；
c. 財(cái)務(wù)處理；
d. 審計(jì)追蹤，等等。
6.3.1.3.2 硬件的限制
本項(xiàng)包括在各種硬件約束下運(yùn)行的軟件要求，例如，應(yīng)該包括：
a. 硬件配置的特點(diǎn)（接口數(shù)，指令系統(tǒng)等）；
b. 內(nèi)存儲(chǔ)器和輔助存儲(chǔ)器的容量。
6.3.1.4 屬性
在軟件的需求之中有若干個(gè)屬性，下面指出其中的幾個(gè)（注意：對(duì)這些決不應(yīng)理解為是一個(gè)完整的清單）。
6.3.1.4.1 可用性
可以指定一些因素，如檢查點(diǎn)、恢復(fù)和再啟動(dòng)等，以保證整個(gè)系統(tǒng)有一個(gè)確定的可用性級(jí)別。
6.3.1.4.2 安全性
這里指的是保護(hù)軟件的要素，以防止各種非法的訪問、使用，修改、破壞或者泄密。這個(gè)領(lǐng)域的具體需求必須包括：
a. 利用可靠的密碼技術(shù)；
b. 掌握特定的記錄或歷史數(shù)據(jù)集；
c. 給不同的模塊分配不同的功能；
d. 限定一個(gè)程序中某些區(qū)域的通信；
e. 計(jì)算臨界值的檢查和。
6.3.1.4.3 可維護(hù)性
這里規(guī)定若干需求以確保軟件是可維護(hù)的。例如：
a. 軟件模塊所需要的特殊的耦合矩陣；
b. 對(duì)微型裝置指定特殊的數(shù)據(jù)/程序分割要求。
6.3.1.4.4 可轉(zhuǎn)移/轉(zhuǎn)換性
這里規(guī)定把軟件從一種環(huán)境移植到另一種環(huán)境所要求的用戶程序，用戶接口兼容方面的約束等等。
6.3.1.4.5 警告
指定所需屬性十分重要，它使得人們能用規(guī)定的方法去進(jìn)行客觀的驗(yàn)證。
6.3.1.5 外部接口要求
6.3.1.5.1 用戶接口
提供用戶使用軟件產(chǎn)品是地的接口需求。例如，如果系統(tǒng)的用戶通過顯示終端進(jìn)行操作，就必須指定如下要求：
a. 對(duì)屏幕格式的要求；
b. 報(bào)表或菜單的頁(yè)面打印格式和內(nèi)容；
c. 輸入輸出的相對(duì)時(shí)間；
d. 程序功能鍵的或用性。
6.3.1.5.2 硬件接口
要指出軟件產(chǎn)品和系統(tǒng)硬部件之間每一個(gè)接口的邏輯特點(diǎn)。還可能包括如下事宜：支撐什么樣的設(shè)備，如何支撐這些設(shè)備，有何約定。
6.3.1.5.3 軟件接口
在這里應(yīng)指定需使用的其他軟件產(chǎn)品（例如，數(shù)據(jù)管理系統(tǒng)，操作系統(tǒng)，或者數(shù)學(xué)軟件包），以及同其他應(yīng)用系統(tǒng)之間的接口。
對(duì)每一個(gè)所需的軟件產(chǎn)品，要提供如下內(nèi)容：
a. 名字；
b. 助記符；
c. 規(guī)格說明號(hào)；
d. 版本號(hào)；
e. 來源。
對(duì)于每一個(gè)接口，這部分應(yīng)說明與軟件產(chǎn)品相關(guān)的接口軟件的目的，并根據(jù)信息的內(nèi)容和格式定義接口，這里不必詳細(xì)描述任何已有完整文件的接口，只要引用定義該接口的文件即可。
6.3.1.5.4 通信接口
這里指定各種通信接口，例如，局部網(wǎng)絡(luò)的協(xié)議等等。
6.3.1.6 其他需求
根據(jù)軟件和用戶組織的特性等，某些需求放在下面各項(xiàng)中描述。
6.3.1.6.1 數(shù)據(jù)庫(kù)
本項(xiàng)對(duì)作為產(chǎn)品的一部分進(jìn)行開發(fā)的數(shù)據(jù)庫(kù)規(guī)定一些需求，它們可能包括：
a. 在6.3.1.1條中標(biāo)識(shí)的信息類別；
b. 使用的頻率；
c. 存取能力；
d. 數(shù)據(jù)元素和文卷描述符；
e. 數(shù)據(jù)元素、記錄和文卷的關(guān)系；
f. 靜態(tài)和動(dòng)態(tài)的組織；
g. 數(shù)據(jù)保存要求。
注：如果使用一個(gè)現(xiàn)有的數(shù)據(jù)庫(kù)包，這個(gè)包應(yīng)在“軟件接口”中命名，并在那里詳細(xì)說明其用法。
6.3.1.6.2 操作
這里說明用戶要求的常規(guī)的和特殊的操作。
a. 在用戶組織之中各種方式的操作。例如，用戶初始化操作；
b. 交互作用操作的同期和無人操作的周期；
c. 數(shù)據(jù)處理支持功能；
d. 后援和恢復(fù)操作。
注：這里的內(nèi)容有時(shí)是用戶接口的一部分。
6.3.1.6.3 場(chǎng)合適應(yīng)性需求
這里包括：
a. 對(duì)給定場(chǎng)合、任務(wù)或操作方式的任何數(shù)據(jù)或初始化順序的需求進(jìn)行定義。例如，柵值，安全界限等等。
b. 指出場(chǎng)合或相關(guān)任務(wù)的特點(diǎn)，這里可以被修改以使軟件適合特殊配制的要求。
6.3.2 具體要求的組織
本條通常是SRS所有部分中最大并且最復(fù)雜的部分。
a. 可以根據(jù)軟件實(shí)現(xiàn)功能的基本類型，將本條分成若干段。例如：考慮一個(gè)大的交互記帳系統(tǒng)，在里層可以分為操作軟件（它支持近乎實(shí)時(shí)的事務(wù)處理）、支撐軟件（聯(lián)機(jī)功能、磁盤備份、裝入磁帶等等）以及診斷軟件（診斷硬件、通信等），外一層是應(yīng)收款帳以及應(yīng)付款帳等等；
b.結(jié)構(gòu)細(xì)分的目的是提高SRS的可讀性，而不是進(jìn)行概要設(shè)計(jì)。
對(duì)于SRS中的第3章的具體需求部分的最好的組織方案取決于所說明的軟件產(chǎn)品的應(yīng)用范圍和性質(zhì)。
表2~表5提供了四種可能的組織方案。
a. 大綱1（表2）中首先說明全部功能需求，然后說明四種類型的接口要求，最后是其他需求；
b. 大綱2（表3）中，把對(duì)應(yīng)每個(gè)特定功能的四種接口需求和該功能需求放在一起描述，然后說明其他需求；
c. 大綱3（表4）中，與功能需求有關(guān)的全部?jī)?nèi)容放在一起首先說明，然后是其他需求的描述。對(duì)每一種外部接口的需求重復(fù)上述過程；
d. 大綱4（表5）中，接口需求和其余的需求作為每一個(gè)功能需求的附屬部分來說明。
SRS的具體需求的組織形式必須選擇可讀性最好的方法來描述。
6.4 支持信息
支持信息是指目錄表，附錄和索引。以便使SRS易于使用。
6.4.1 目錄表和索引很重要，而且應(yīng)按照可以接受的好的文件規(guī)則來編寫。
6.4.2 對(duì)一個(gè)實(shí)際的需求規(guī)格說明來說，若有必要應(yīng)該編寫附錄。附錄中可能包括：
a. 輸入輸出格式樣本，成本分析研究的描述或用戶調(diào)查結(jié)果；
b. 有助于理解SRS的背景信息；
c. 軟件所解決問題的描述；
d. 用戶歷史、背景、經(jīng)歷和操作特點(diǎn)；
e. 交叉訪問表。按先后次序進(jìn)行編排，使一些不完全的軟件需求得以完善（參見4.3.2條和4.3.3條）；
f. 特殊的裝配指令用于編碼和媒體，以滿足安全、輸出、初始裝入或其他要求。
6.4.3 當(dāng)包括附錄時(shí)，SRS必須明確地說明附錄是不是需求要考慮的部分。
表2 SRS第3章大綱1
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 引言
3.1.1.2 輸入
3.1.1.3 加工
3.1.1.4 輸出
3.1.2 功能需求2
……
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用戶接口
3.2.2 硬件接口
3.2.3 軟件接口
3.2.4 通信接口
3.3 性能需求
3.4 設(shè)計(jì)約束
3.4.1 其他標(biāo)準(zhǔn)的約束
3.4.2 硬件的限制
…………
3.5 屬性
3.5.1 安全性
3.5.2 可維護(hù)性
…………
3.6 其他需求
3.6.1 數(shù)據(jù)庫(kù)
3.6.2 操作
3.6.3 場(chǎng)合適應(yīng)性
…………
表3 SRS第3章大綱2
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 規(guī)格說明
3.1.1.1.1 引言
3.1.1.1.2 輸入
3.1.1.1.3 加工
3.1.1.1.4 輸出
3.1.1.2 外部接口
3.1.1.2.1 用戶接口
3.1.1.2.2 硬件接口
3.1.1.2.3 軟件接口
3.1.1.2.4 通信接口
3.1.2 功能需求2
…………
3.1.n 功能需求n
3.2 性能需求
3.3 設(shè)計(jì)約束
3.4 屬性
3.4.1 安全性
3.4.2 可維護(hù)性
…………
3.5 其他需求
3.5.1 數(shù)據(jù)庫(kù)
3.5.2 操作
3.5.3 場(chǎng)合適應(yīng)性
…………
表4 SRS第3章大綱3
3.1 功能需求
3.1.1 功能需求1
3.1.1.1 引言
3.1.1.2 輸入
3.1.1.3 加工
3.1.1.4 輸出
3.1.1.5 性能需求
3.1.1.6 設(shè)計(jì)約束
3.1.1.6.1 其他標(biāo)準(zhǔn)的約束
3.1.1.6.2 硬件的限制
…………
3.1.1.7 屬性
3.1.1.7.2 可維護(hù)性
…………
3.1.1.8 其他需求
3.1.1.8.1 數(shù)據(jù)庫(kù)
3.1.1.8.2 操作
3.1.1.8.3 場(chǎng)合適應(yīng)性
…………
3.1.2 功能需求2
…………
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用戶接口
3.2.1.1 性能需求
3.2.1.2 設(shè)計(jì)約束
3.2.1.2.1 其他標(biāo)準(zhǔn)的約束
3.2.1.2.2 硬件的限制
…………
3.2.1.3 屬性
3.2.1.3.1 安全性
3.2.1.3.2 可維護(hù)性
…………
3.2.1.4 其他需求
3.2.1.4.1 數(shù)據(jù)庫(kù)
3.2.1.4.2 操作
3.2.1.4.3 場(chǎng)合適應(yīng)性
…………
3.2.2 硬件接口
3.2.3 軟件接口
3.2.4 通信接口
表5 SRS第3章大綱4
3.1 功能需求1
3.1.1 引言
3.1.2 輸入
3.1.3 加工
3.1.4 輸出
3.1.5 外部接口
3.1.5.1 用戶接口
3.1.5.2 硬件接口
3.1.5.3 軟件接口
3.1.6 性能需求
3.1.7 設(shè)計(jì)約束
3.1.8 屬性
3.1.8.1 安全性
3.1.8.2 可維護(hù)性
…………
3.1.9 其他需求
3.1.9.1 數(shù)據(jù)庫(kù)
3.1.9.2 操作
3.1.9.3 場(chǎng)合適應(yīng)性
…………
3.2 功能需求2
…………
3.n 功能需求n
聯(lián)系客服
