需求規(guī)格說明書 (標準版)

《需求規(guī)格說明書 (標準版)》由會員分享，可在線閱讀，更多相關(guān)《需求規(guī)格說明書 (標準版)（25頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、...wd... 需求規(guī)格說明書(ISO標準版) 編者說明： 當需求調(diào)查、分析工作告一段落時，你就需要將這些需求進展規(guī)格化描述，整理成文，即軟件需求規(guī)格說明書，也就是SRS。這是在軟件工程過程中最有價值的一個文檔。ISO所提供的標準雖然已經(jīng)時間長遠，但還是頗具參考價值的。 1．引言 1.1編寫的目的 [說明編寫這份需求說明書的目的,指出預(yù)期的讀者。] 1.2背景 a. 待開發(fā)的系統(tǒng)的名稱; b. 本工程的任務(wù)提出者、開發(fā)者、用戶； c. 該系統(tǒng)同其他系統(tǒng)或其他機構(gòu)的 基本的相互來往關(guān)系。 1.3定義 [列出本文件中用到的專門術(shù)語的定義和外文首字母組詞的

2、原詞組。] 1.4參考資料 [列出用得著的參考資料。] 2．任務(wù)概述 2.1目標 [表達該系統(tǒng)開發(fā)的意圖、應(yīng)用目標、作用范圍以及其他應(yīng)向讀者說明的有關(guān)該系統(tǒng)開發(fā)的背景材料。解釋被開發(fā)系統(tǒng)與其他有關(guān)系統(tǒng)之間的關(guān)系。] 2.2用戶的特點 [列出本系統(tǒng)的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術(shù)專長，以及本系統(tǒng)的預(yù)期使用頻度。] 2.3假定和約束 [列出進展本系統(tǒng)開發(fā)工作的假定和約束。] 3．需求規(guī)定 3.1對功能的規(guī)定 [用列表的方式，逐項定量和定性地表達對系統(tǒng)所提出的功能要求，說明輸入什么量、經(jīng)怎么樣的處理、得到什么輸出，說明系統(tǒng)的容量,

3、包括系統(tǒng)應(yīng)支持的終端數(shù)和應(yīng)支持的并行操作的用戶數(shù)等指標。] 3.2 對性能的規(guī)定 3.2.1精度 [說明對該系統(tǒng)的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。] 3.2.2時間特性要求 [說明對于該系統(tǒng)的時間特性要求。] 3.2.3靈活性 [說明對該系統(tǒng)的靈活性的要求，即當需求發(fā)生某些變化時，該系統(tǒng)對這些變化的適應(yīng)能力。] 3.3輸入輸出要求 [解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。對系統(tǒng)的數(shù)據(jù)輸出及必須標明的控制輸出量進展解釋并舉例。] 3.4數(shù)據(jù)管理能力要求〔針對軟件系統(tǒng)〕 [說明需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按

4、可預(yù)見的增長對數(shù)據(jù)及其分量的存儲要求作出估算。] 3.5故障處理要求 [列出可能的軟件、硬件故障以及對各項性能而言所產(chǎn)生的后果和對故障處理的要求。] 3.6其他專門要求 [如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環(huán)境可轉(zhuǎn)換性的特殊要求等。] 4．運行環(huán)境規(guī)定 4.1設(shè)備 [列出運行該軟件所需要的硬設(shè)備。說明其中的新型設(shè)備及其專門功能，包括： a. 處理器型號及內(nèi)存容量 b. 外存容量、聯(lián)機或脫機、媒體及其存儲格式，設(shè)備的型號及數(shù)量 c. 輸入及輸出設(shè)備的型號和數(shù)量，聯(lián)機或脫機； d. 數(shù)據(jù)通信設(shè)備的型號和數(shù)量 e.

5、 功能鍵及其他專用硬件] 4.2支持軟件 [列出支持軟件，包括要用到的操作系統(tǒng)、編譯程序、測試支持軟件等。] 4.3接口 [說明該系統(tǒng)同其他系統(tǒng)之間的接口、數(shù)據(jù)通信協(xié)議等。] 4.4控制 [說明控制該系統(tǒng)的運行的方法和控制信號，并說明這些控制信號的來源。] 需求規(guī)格說明書(Volere版) 編者說明： Atlantic System Guild〔 atlsysguild 〕公司所提供的Volere需求過程與軟件需求規(guī)格說明書模板那么充分利用了現(xiàn)代軟件工程思想與技術(shù)，是一個十分實用、完善的SRS模板。其所提供的Volere需求記錄卡也十分實用

6、，強烈推薦。 注：從Atlantic System Guild公司網(wǎng)站 atlsysguild 上獲得，并稍做修改 1.產(chǎn)品的目標 1.1 該工程工作的用戶問題或背景 [對引發(fā)開發(fā)任務(wù)的工作和情況的描述。同時也應(yīng)描述用戶希望用將要交付的軟件來完成的工作。] [該節(jié)內(nèi)容為該工程提供了合法的理由，你應(yīng)該考慮用戶的問題是否嚴重，是否應(yīng)該解決和為什么應(yīng)該解決。] 1.2 產(chǎn)品的目標 [用一句話或很少的幾句話來說明“我們希望該產(chǎn)品做什么〞換言之，即開發(fā)該產(chǎn)品的真正原因。 [工程如果沒有一個表述清晰、易于理解的目標，就會迷失在產(chǎn)品開發(fā)的沙漠中。產(chǎn)品必須帶來某種優(yōu)勢。典型的優(yōu)勢是

7、產(chǎn)品會增加組織在市場上的價值，減少運作成本，或提供更好的客戶服務(wù)。這個優(yōu)勢應(yīng)該是可度量的，這樣才能夠讓您確定交付的產(chǎn)品是否到達目標。] 2.客戶、顧客和其它風險承擔者 2.1 客戶是為開發(fā)付費的人，并將成為所交付產(chǎn)品的擁有者 [這一項必須給出客戶的姓名，三個以內(nèi)是合理的。] [客戶最終將承受該產(chǎn)品，因此必須對交付的產(chǎn)品滿意。如果你無法找到一個客戶的姓名，那么也許你就不應(yīng)該構(gòu)建該產(chǎn)品。] 2.2 顧客是將花錢購置該產(chǎn)品的人 [也給出姓名和相關(guān)的信息] 2.3 其它風險承擔者 [其他的一些人或組織的名稱，他們或者受到產(chǎn)品的影響，或影響產(chǎn)品。] 1） 經(jīng)理或

8、工程負責人； 2） 業(yè)務(wù)領(lǐng)域?qū)＜遥? 3） 技術(shù)人員； 4） 系統(tǒng)開發(fā)者； 5） 市場人員； 6） 產(chǎn)品經(jīng)理； 7） 測試和質(zhì)量保證人員； 8） 審查員，諸如安全審查員或?qū)徲嬋藛T； 9） 律師； 10〕易用性專家； 11〕你所處行業(yè)的專業(yè)人員。 3.產(chǎn)品的用戶 3.1 產(chǎn)品的用戶 [產(chǎn)品的潛在用戶或操作員的列表。針對每種類型的用戶，提供以下信息：] 1） 用戶分類 2） 用戶工作的任務(wù)； 3） 主要相關(guān)的經(jīng)歷； 4） 技術(shù)經(jīng)歷； 5） 其他用戶特征：包括身體、智力、工作態(tài)度、對技術(shù)的態(tài)度、教育程度、語言技能、年齡、性別等。 [用戶是為了完成工作而與產(chǎn)

9、品交互的人，你了解用戶，就越可能提交適合用戶工作方式的產(chǎn)品。] 3.2 對用戶設(shè)的優(yōu)先級 [在每類用戶后面附上一個優(yōu)先級，這區(qū)別了用戶的重要性和優(yōu)先地位：] 1） 關(guān)鍵用戶：對產(chǎn)品的后續(xù)成功至關(guān)重要； 2） 次要用戶：他們使用產(chǎn)品，但對產(chǎn)品的長期成功并無影響； 3） 不重要的用戶：不常用、未授權(quán)和沒有技能的用戶。 [如果認為某些用戶對產(chǎn)品或組織更重要，那么應(yīng)該寫明，因為它會影響你設(shè)計產(chǎn)品的方式。] 4.需求限制條件 4.1 解決方案限制條件 [此處明確了限制條件，它們規(guī)定了解決問題必須采取的方式。您可以認為它們是指令式的解決方案。仔細描述該解決方案，以及測試是否符合的

10、度量標準。如果可能，您應(yīng)該解釋使用該解決方案的原因。] [換一句話說，就是要求軟件解決方案滿足哪些限制條件！] 4.2 實現(xiàn)環(huán)境 [此處描述產(chǎn)品將被實施的技術(shù)環(huán)境和物理環(huán)境。] [該環(huán)境也將成為設(shè)計解決方案時的限制條件之一。] 4.3 伙伴應(yīng)用 [此處描述那些不屬于產(chǎn)品的一局部，但產(chǎn)品卻又必須與其協(xié)作的應(yīng)用程序。] 4.4 COTS [此處描述實現(xiàn)產(chǎn)品需求所必須使用的COTS(商業(yè)組件)。] 4.5 預(yù)期的工作場地環(huán)境 [此處描述用戶工作和使用該產(chǎn)品的工作場地。此處應(yīng)該描述任何可能對產(chǎn)品設(shè)計產(chǎn)生影響的工作場地特征。] 4.6 開發(fā)者構(gòu)建該產(chǎn)品需要多

11、少時間 [任何的最后期限，或商業(yè)時機的時限，應(yīng)在此處說明。] 4.7 該產(chǎn)品的財務(wù)預(yù)算是多少 [該產(chǎn)品的預(yù)算，以金錢的形式或可得資源的形式說明。] 5.命名標準和定義 [定義工程中使用到的所有術(shù)語，包括同義詞。這里的內(nèi)容就是一個字典，包括在需求規(guī)格說明書中使用的所有名稱的含義。這個字典應(yīng)該使用你的組織或行業(yè)使用的標準名稱。這些名稱也應(yīng)該反映出在工作領(lǐng)域中當前使用的術(shù)語。該字典包括工程中用到的所有名稱。請仔細地選擇名稱，以防止傳達不同的、不期望的含義。為每個名字寫下簡明扼要的定義，這些定義必須經(jīng)過相應(yīng)的風險承擔者同意。] 6.相關(guān)事實 [可能對產(chǎn)品產(chǎn)生影響的外部因素

12、，但不是命令式的需求限制條件。] 7.假定 [列出開發(fā)者所做的假設(shè)。] [將所有的假設(shè)列在此的目的是讓每一個工程成員都意識到這個假設(shè)。] 8.產(chǎn)品的范圍 8.1 工作的上下文范圍 [上下文范圍圖用來表示將要開發(fā)的系統(tǒng)、產(chǎn)品與其它系統(tǒng)之間的關(guān)系，以確定系統(tǒng)邊界。] 8.2 工作切分 [一個事件清單，確定系統(tǒng)要響應(yīng)的所有業(yè)務(wù)事件。清單包括：] 1） 事件名稱 2） 輸入和輸出 8.3 產(chǎn)品邊界 [你可以使用用例圖(use-case)來確定了用戶與產(chǎn)品之間的邊界。] 9.功能性需求與數(shù)據(jù)需求 9.1 功能性需求 [對產(chǎn)品必須執(zhí)行的動作的描述。]

13、 [每個功能性需求必須有一個驗收標準。] 9.2 數(shù)據(jù)需求 [與產(chǎn)品/系統(tǒng)有密切關(guān)系的主題域相關(guān)的業(yè)務(wù)對象、實體、類的說明書。] [進展問題域建模，生成相應(yīng)的類圖。] 10.觀感需求 [一些與產(chǎn)品的用戶界面相關(guān)的需求描述。] 11.易用性需求 11.1 易于使用 [描述如何構(gòu)建符合最終用戶期望的產(chǎn)品。] 11.2 學習的容易程序 [學習使用該產(chǎn)品應(yīng)該多容易的說明。通常是有學習時間來衡量。] 12.性能要求 12.1 速度需求 [明確完成特定任務(wù)需要的時間，這常常指響應(yīng)時間。] 12.2 安全性的需求 [對可能造成人身

14、傷害、財產(chǎn)損失和環(huán)境破壞所考慮到的風險進展量化描述。] 12.3 精度需求 [對產(chǎn)品產(chǎn)生的結(jié)果期望的精度進展量化描述。] 12.4 可靠性和可用性需求 [本節(jié)量化產(chǎn)品所需的可靠性。這常常表述為允許的兩次失敗之間無故障運行時間，或允許的總失敗率。] 12.5 容量需求 [本節(jié)明確處理的吞吐量和產(chǎn)品存儲數(shù)據(jù)的容量。] 13.操作需求 13.1 預(yù)期的物理環(huán)境 [本節(jié)明確產(chǎn)品將操作的物理環(huán)境，以及這種環(huán)境引起的任何特殊需求。] 13.2 預(yù)期的技術(shù)環(huán)境 [硬件和其它組成新產(chǎn)品操作環(huán)境的設(shè)備的標準。] 13.3 伙伴應(yīng)用程序 [對產(chǎn)品必

15、須與之交互的其它應(yīng)用程序的描述。] 14.可維護性和可移植性需求 14.1 維護該產(chǎn)品需要多容易 [對產(chǎn)品作特定修改所需時間的量化描述。] 14.2 是否存在一些特殊情況適用于該產(chǎn)品的維護 [關(guān)于預(yù)期的產(chǎn)品發(fā)布周期和發(fā)布將采取的形式的規(guī)定。] 14.3 可移植性需求 [對產(chǎn)品必須支持的其他平臺或環(huán)境的描述。] 15.安全性需求 15.1 該產(chǎn)品是保密的嗎 [關(guān)于該被授權(quán)使用該產(chǎn)品，以及在什么樣的情況下授權(quán)等方面的描述。] 15.2 文件完整性需求 [關(guān)于需要的數(shù)據(jù)庫和其他文件完整性方面的說明。] 15.3 審計需求 [

16、關(guān)于需要的審計檢查方面的說明。] 16.文件和政策需求 [本節(jié)包括針對社會和政策的因素的規(guī)格說明，這些因素會影響產(chǎn)品的可承受性。如果你開發(fā)的產(chǎn)品是針對外國市場的，可能要特別注意這些需求。] [問一下是否產(chǎn)品的目標是你所不熟悉的文化環(huán)境，是否其它國家的人或其他類型的組織的人會使用該產(chǎn)品。人們是否有與你的文化不同的習慣、節(jié)日、迷信、文化上的社會行為標準。] 17.法律需求 17.1 該產(chǎn)品是否受到某些法律的管制 [明確該產(chǎn)品的法律需求的描述。] 17.2 是否有一些必須符合的標準 [明確適用的標準和參考的詳細標準的描述。] 18.Opend問題 [對未確定但可能

17、對產(chǎn)品產(chǎn)生重要影響的因素的問題描述。按照需求分析的術(shù)語還說，就是TBD〔To Be Define〕的問題。] 19.COTS解決方案 19.1 是否有一些制造好的產(chǎn)品可以購置 [應(yīng)該調(diào)查現(xiàn)存產(chǎn)品清單，這些產(chǎn)品可以作為潛在的解決方案。] 19.2 該產(chǎn)品是否可使用制造好的組件 [描述可能用于該產(chǎn)品的候選組件，包括采購的和公司自己的產(chǎn)品。列出來源。] 19.3 是否有一些我們可以復制的東西 [其他相似產(chǎn)品的清單。] 20.新問題 20.1 新產(chǎn)品會在當前環(huán)境中帶來什么問題 [關(guān)于新產(chǎn)品將怎樣影響當前的實現(xiàn)環(huán)境的描述。] 20.2 新的開發(fā)是否將

18、影響某些已實施的系統(tǒng) [關(guān)于新產(chǎn)品將怎樣與現(xiàn)存系統(tǒng)協(xié)同工作的描述。] 20.3 是否我們現(xiàn)有的用戶會受到新開發(fā)的敵對性影響 [關(guān)于現(xiàn)有用戶可能產(chǎn)生的敵對性反響的細節(jié)。] 20.4 預(yù)期的實現(xiàn)環(huán)境會存在什么限制新產(chǎn)品的因素 [關(guān)于新的自動化技術(shù)、新的組織構(gòu)造方式的任何潛在問題的描述。] 20.5 是否新產(chǎn)品會帶來其他問題 [確定我們可能不能處理的情況。] 21.任務(wù) 21.1 為提交該產(chǎn)品已經(jīng)做了哪些事 [用來開發(fā)產(chǎn)品的生命周期和方法的細節(jié)。畫一個高層的過程圖展示各項任務(wù)和它們之間的接口，這可能是溝通這方面信息的最好方法。] 21.2 開發(fā)階

19、段 [關(guān)于每個開發(fā)階段和操作環(huán)境中的組件的規(guī)格說明。] 22.移交 22.1 我們要讓已有數(shù)據(jù)和過程配合新產(chǎn)品，有什么特殊要求 [一個移交活動的列表，一個實現(xiàn)的時間表。] 22.2 為了新產(chǎn)品，哪些數(shù)據(jù)必須修改/轉(zhuǎn)換 [數(shù)據(jù)轉(zhuǎn)換任務(wù)清單，同時確定新產(chǎn)品需要轉(zhuǎn)換的數(shù)據(jù)。] 23. 風險 23.1 當你開發(fā)該產(chǎn)品時，要面對什么風險 23.2 你制定了怎樣的偶然緊急情況方案 24.費用 [需求的其他費用是你必須投入到產(chǎn)品構(gòu)建中去的錢或工作量。當需求規(guī)格說明書完成時，你可以使用一種估算方法來評估費用，然后以構(gòu)建所需的資金或時間的形式表述出來。]

20、25.用戶文檔 [用戶文檔的清單，這些文檔將作為產(chǎn)品的一局部交付。] 26.后續(xù)版本的需求 [這里記錄下一些希望今后版本中實現(xiàn)的需求。] Volere需求記錄卡 編者說明： 正如前面所述，Atlantic System Guild還提供了一個配套的Volere需求記錄卡，這個記錄卡十分實用。建議大家在需求調(diào)查、分析過程中，將需求記錄在一系列的Volere需求記錄卡上，這個卡讓你能夠很好的理清需求之間的關(guān)系，需求提出的背景，用戶對需求的期望，有了這些素材，整理SRS時將變得更加簡單。 需求#： 需求類型： 事件

21、/用例#： 描述： 理由： 來源： 驗收標準： 顧客滿意度： 顧客不滿意度： 依賴關(guān)系： 沖突： 支持材料： 歷史： Copyright @ Atiantic system Guild Volere 注：顧客滿意度是指完成該項功能顧客滿意的程度，而顧客不滿意度那么是指未實現(xiàn)該功能顧客不滿意的程度。 軟件需求規(guī)格說明書頁：7 注，以RUP?軟件需求規(guī)約?進展修改。 〔RUP版〕 編者

22、說明： 如果在需求分析時采用了用例〔Use case〕技術(shù)，那么該需求規(guī)格說明書將更加符合你的需要。當然，你也可以結(jié)合Volere需求規(guī)格說明書對該模板進展必要的修改。 1.文檔概述 [該局部主要是對軟件需求規(guī)格說明書文檔進展 基本的描述，包括該文檔的目的、范圍、術(shù)語定義、參考資料以及概要。] [軟件需求規(guī)格說明書用來系統(tǒng)、完整地記錄系統(tǒng)的軟件需求。該軟件需求說明書的根基是用例分析技術(shù)。因此該文檔中應(yīng)包括用例模型、補充規(guī)約等內(nèi)容。] 1.1目的 [在此小節(jié)中，主要對軟件需求規(guī)格說明書的目的做一概要性說明，通常軟件需求規(guī)格說明書應(yīng)詳細地說明應(yīng)用程序、子系統(tǒng)的外部行為，還要說明非功能

23、性需求、設(shè)計約束，以及其它的相關(guān)因素。] 1.2范圍 [系統(tǒng)是有范圍的，而不是無限擴展的，對于無限擴展的需求是無法進展描述的。因此，在本小節(jié)應(yīng)該對該說明書所涉及的工程范圍進展清晰的界定。指定該規(guī)格說明書適用的軟件應(yīng)用程序、特性或者其它子系統(tǒng)分組、其相關(guān)的用例模型。當然在此也需要列出會受到該文檔影響的其它文檔。] 1.3 定義、首字母縮寫詞和縮略語 [與其它文檔一樣，該文檔也需要將本文檔中所涉及的所有術(shù)語、縮略語進展詳細的定義。還有一種可簡明的做法，就是維護在一個工程詞匯表中，這樣就可以防止在每個文檔中都重復很多內(nèi)容。] 1.4參考資料 [在這一小節(jié)中，應(yīng)完整地列出該文檔引用的所有文

24、檔。對于每個引用的文檔都應(yīng)該給出標題、標識號、日期以及來源，為閱讀者查找這些文檔提供足夠詳細的信息。] 1.5概述 [在本小節(jié)中，主要是說明軟件需求規(guī)格說明書各個局部所包含的主要內(nèi)容，就像一個文章摘要一樣。同時也應(yīng)該對文檔的組織方式進展解釋。] 2. 整體說明 [在本節(jié)中，將對整個軟件需求進展總體性的描述，以期讓讀者對整個軟件系統(tǒng)的需求有一個框架性的認識。也就是說，該節(jié)中主要包括影響產(chǎn)品及其需求的一般因素，而不列舉 具體的需求。主要包括產(chǎn)品總體效果、產(chǎn)品功能、用戶特征、約束、假設(shè)與依賴關(guān)系、需求子集等方面的內(nèi)容。] 2.1用例模型 [在本小節(jié)中，將列出該軟件需求的用例模型，該模型處

25、于系統(tǒng)級，對系統(tǒng)的特性進展宏觀的描述。在此應(yīng)該列出所有的用例和Actor的名稱列表，并且對其做出簡要的說明，以及在圖中的各種關(guān)系。] 2.2假設(shè)與依賴關(guān)系 [在軟件系統(tǒng)的開發(fā)過程中，存在許多假設(shè)和依賴關(guān)系。在本小節(jié)中應(yīng)列舉出所有的重要的技術(shù)可行性假設(shè)、子系統(tǒng)或構(gòu)件可用性假設(shè)，以及一些可行性的假設(shè)。] 3.具體需求 [如果說第二章節(jié)是框架，那么本節(jié)就是血肉。在本節(jié)中，應(yīng)該詳細列出所有的軟件需求，其詳細程序應(yīng)使設(shè)計人員能夠充分理解并且進展設(shè)計的要求，同時也應(yīng)該給予測試人員足夠的信息，以幫助他們來驗證系統(tǒng)是否滿足了這些需求。整個需求的組織可以采用用例描述進展。] 3.1用例描述 [如果你

26、使用用例建模技術(shù)，那么你已經(jīng)通過用例定義了系統(tǒng)的大局部功能性需求和一些非功能性需求。因此，在軟件需求規(guī)格說明書只需將這些具體的用例描述，整理在一起，全部放在該小節(jié)之中。當然也可以將用例描述做為附件，在此列出引用，只是這樣做并不利于閱讀。建議在組織形式上采用以“軟件需求〞為線索，在每個需求中，填入對應(yīng)的1個或幾個用例描述。] 3.2補充需求 [由于用例畢竟主要針對功能性需求，因此還會有一些其它的補充需求遺漏，因此在本小節(jié)中就是將這些東西補充出來。這些補充需求大局部集中在非功能需求之上，包括以下幾個方面的內(nèi)容：] 1） 易用性：例如指出普通用戶和高級用戶要高效地執(zhí)行某個特定操作所需的培訓時間

27、；指出典型任務(wù)的可評測任務(wù)次數(shù)；或者指出需要滿足的可用性標準〔如IBM的CUA標準、Microsoft的GUI標準。 2） 可靠性：包括系統(tǒng)可用性〔可用時間百分比、使用小時數(shù)、維護訪問權(quán)、降紙模式操作等〕；平均故障間隔時間〔MTBF，通常表示為小時數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)〕；平均修復時間〔MTTR，系統(tǒng)在發(fā)生故障后可以暫停運行的時間〕；準確度〔指出系統(tǒng)輸出要求具備的精細度、分辨率和準確度〕；最高錯誤或缺陷率〔通常表示為bugs/KLOC，即每千行代碼的錯誤數(shù)目或 bugs/function-point，即每個功能點的錯誤數(shù)目〕；錯誤或缺陷率〔按照小錯誤、大錯誤和嚴重錯誤來分類：需求中

28、必須對“嚴重〞錯誤進展界定，例如：數(shù)據(jù)完全喪失或完全不能使用系統(tǒng)的某局部功能〕。 3） 性能：包括對事務(wù)的響應(yīng)時間〔平均、最長〕；吞吐量〔例如每秒處理的事務(wù)數(shù)〕；容量〔例如系統(tǒng)可以容納的客戶或事務(wù)數(shù)〕；降級模式〔當系統(tǒng)以某種形式降級時可承受的運行模式〕；資源利用情況：內(nèi)存、磁盤、通信等。 4） 其它：包括用戶界面要求、聯(lián)機幫助系統(tǒng)要求、法律許可、外購構(gòu)件，以及操作系統(tǒng)、開發(fā)工具、數(shù)據(jù)庫系統(tǒng)等設(shè)計約束。 4.支持信息 [支持信息用于使軟件需求規(guī)格說明書更易于使用。它包括：目錄、索引、附錄等。] 計算機軟件需求說明編制指南〔國標版〕 編者說明： 軟件需求規(guī)格說明是十分重要的文

29、檔，因此為開發(fā)團隊提供一份詳細的編制指南是十分有意義和必要的。本文檔就是一個編制指南的例子，你可以根據(jù)該指南，結(jié)合自己的實際情況進展修改。 1．引言 1.1 目的和作用 本指南為軟件需求實踐提供了一個標準化的方法。本指南不提倡把軟件需求說明〔Software Requirements Specifications，以下簡稱SRS〕劃分成等級，防止把它定義成更小的需求子集。 本指南適用對象： 1〕軟件客戶〔Customers〕，以便準確地描述他們想獲得什么樣的產(chǎn)品。 2〕軟件開發(fā)者〔Suppliers〕，以便準確地理解客戶需要什么樣的產(chǎn)品。 對于任一要實現(xiàn)以下目標的單位

30、和〔或〕個人： 1〕要提出開發(fā)標準化的SRS提綱； 2〕定義自己需要的具體的格式和內(nèi)容； 3〕產(chǎn)生附加的局部使用條款，如SRS質(zhì)量檢查清單或者SRS作者手冊等。 SRS將完成以下目標： 1） 在軟件產(chǎn)品完成目標方面為客戶和開發(fā)者之間建設(shè)共同協(xié)議創(chuàng)立一個根基。對要實現(xiàn)的軟件功能做全面描述，幫助客戶判斷所規(guī)定的軟件是否符合他們的要求，或者怎樣修改這種軟件才能適合他們的要求； 2） 提高開發(fā)效率。編制SRS的過程將使客戶在設(shè)計開場之前周密地思考全部需求，從而減少事后重新設(shè)計、重新編碼和重新測試的返工活動。在SRS中對各種需求仔細地進展復查，還可以在開發(fā)早期發(fā)現(xiàn)假設(shè)干遺漏、錯誤

31、的理解和不一致性，以便及時加以糾正； 3） 為成本計價和編制方案進度提供根基。SRS提供的對被開發(fā)軟件產(chǎn)品的描述，是計算機軟件產(chǎn)品成本核算的根基，并且可以為各方的要價和付費提供依據(jù)。SRS對軟件的清晰描述，有助于估計所必須的資源，并用作編制進度的依據(jù)； 4） 為確認和驗證提供一個基準。任何組織將更有效地編制他們確實認和驗證方案。作為開發(fā)合同的一局部，SRS還可以提供一個可以度量和遵循的基準〔然而，反之那么不成立，即任一有關(guān)軟件的合同都不能作為SRS。因為這種文件幾乎不包括詳盡的需求說明，并且通常不完全的〕； 5） 便于移植。有了SRS就便于移值軟件產(chǎn)品，以適應(yīng)新的用戶或新的機種?？?/p>

32、戶也易于移植其軟件到其他部門，而開發(fā)者同樣也易于把軟件移植到新的客戶； 6） 作為不斷提高的根基。由于SRS所討論的是軟件產(chǎn)品，而不是開發(fā)這個產(chǎn)品的設(shè)計。因此SRS是軟件產(chǎn)品繼續(xù)提高的根基。雖然SRS也可能要改變，但是原來的SRS還是軟件產(chǎn)品改進的可靠根基。 1.2 范圍 本指南適用于編寫軟件需求規(guī)格說明，它描述了一個SRS所必須的內(nèi)容和質(zhì)量，并且在第6章中提供了SRS大綱。 2．引用標準 GB 8566 計算機軟件開發(fā)標準 GB 8567 計算機軟件產(chǎn)品開發(fā)文件編制指南 GB/T 11457 軟件工程術(shù)語 3．定義 GB/T 11457所列術(shù)語和以下定義適

33、用于本指南。 合同〔contract〕：是由客戶和開發(fā)者共同簽署的具有法律約束力的文件。其中包括產(chǎn)品的技術(shù)、組織、成本和進度方案要求等內(nèi)容。 客戶〔customer〕：指個人或單位，他們?yōu)楫a(chǎn)品開發(fā)提供資金，通?！驳袝r也不必〕還提出各種需求。文件中的客戶和開發(fā)者也可能是同一個組織的成員。 語言〔language〕：是具有語法和語義的通信工具，包括一組表達式、慣例和傳遞信息的有關(guān)規(guī)那么。 分割〔partitioning〕：把一個整體分成假設(shè)干局部。 開發(fā)者〔supplier〕：指為客戶生產(chǎn)某種軟件產(chǎn)品的個人或集團。在本指南中，客戶和開發(fā)者可能是同一個組織的成員。 用戶〔u

34、ser〕：指運行系統(tǒng)或者直接與系統(tǒng)發(fā)生交互作用的個人或集團。用戶和客戶通常不是同一些人。 4．編寫SRS的背景信息 4.1 SRS的 基本要求 SRS是對要完成一定功能、性能的軟件產(chǎn)品、程序或一組程序的說明。對SRS的描述有兩項 基本要求： 1〕必須描述一定的功能、性能； 2〕必須用確定的方法表達這些功能、性能。 4.2 SRS的環(huán)境 必須認識到SRS在整個軟件開發(fā)標準〔見GB 8566〕所規(guī)定的有關(guān)階段都起作用。正因為如此，SRS的起草者必須特別注意不要超出這種作用的范圍。這意味著要滿足以下要求： 1） SRS必須正確地定義所有的軟件需求； 2） 除設(shè)

35、計上的特殊限制之外，SRS中一般不描述任何設(shè)計、驗證或工程管理細節(jié)。 4.3 SRS的特點 4.3.1 無歧義性 當且僅當它對每一個需求只有一種解釋時，SRS者是無歧義的。 1） 要求最終產(chǎn)品的每一個特性用某一術(shù)語描述； 2） 假設(shè)某一術(shù)語在某一特殊的行文中使用時具有多種歧義，那么對該術(shù)語的每種含義作出解釋并指出其適用場合。 需求通常是用自然語言編寫的，使用自然語言的SRS起草者必須特別注意消除其需求的歧義性。提倡使用形式化需求說明語言。 4.3.2 完整性 如果一個SRS能滿足以下要求，那么該SRS就是完整的： 1） 包括全部有意義的要求，無論是關(guān)系到功能

36、的、性能的、設(shè)計約束的，還是關(guān)系到屬性或外部接口方面的需求； 2） 對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應(yīng)予以定義，要對合法和非合法的輸入值的響應(yīng)做出規(guī)定； 3） 要符合SRS要求。如果個別章節(jié)不適用，那么在SRS中要保存章節(jié)號； 4） 填寫SRS中的全部插圖、表、圖示標記和參照，并且定義全部術(shù)語和度量單位。 4.3.2.1 關(guān)于使用“待定〞一詞的規(guī)定 任何一個使用“待定〞的SRS都是不完全的。 1） 假設(shè)萬一遇到使用“待定〞一詞時，作如下處理： ? 對產(chǎn)生“待定〞一詞的條件進展描述，使得問題能被解決； ? 描述必須干什么事，以刪除這個“待定〞； 2） 包含有“待定〞一

37、詞的任何SRS的工程文件應(yīng)該： ? 標識與此特定文件有關(guān)的版本號或表達其專門的發(fā)布號； ? 拒絕任何仍標識為“待定〞一詞的SRS章節(jié)的許諾。 4.3.3 可驗證性 當且僅當SRS中描述的每一個需求都是可以驗證的，該SRS才是可以驗證的；當且僅當在某一性能價格比可取的有限處理過程，人或機器能通過該過程檢查軟件產(chǎn)品能否滿足需求時，才稱這個需求是可以驗證的。 4.3.4 一致性 當且僅當SRS中各個需求的描述是不矛盾時SRS才是一致的。 4.3.5 可修改性 如果一個SRS的構(gòu)造和風格在需求有必要改變時是易于實現(xiàn)的、完整性的、一致的，那么這個SRS就是可以修改的?？尚?/p>

38、改性要求SRS具備以下條件： 1） 具有一個有條不紊的易于使用的內(nèi)容組織，具有目錄表，索引和明確的穿插引用表； 2） 沒有冗余。即同一需求不能在SRS中出現(xiàn)屢次。 ? 冗余本身不是錯誤，但是容易發(fā)生錯誤。冗余可增加SRS的可讀性，但是在一個冗余文件被更新時容易出現(xiàn)問題。例如：假設(shè)一個明確的需求在兩個地方詳細列出，后來發(fā)現(xiàn)這個需求需要改變，假設(shè)只修改一個地方，于是SRS就變得不一致了。 ? 不管冗余是否必須，SRS一定要包含一個詳細的穿插引用表，以便SRS具備可修改性。 4.3.6 可追蹤性 如果每一個需求的源流是清晰的，在進一步產(chǎn)生和改變文件編制時，可以方便地引證每一個

39、需求，那么該SRS就是可追蹤的。建議采用如下兩種類型的追蹤： 1） 向后追蹤〔即向已開發(fā)過的前一階段追蹤〕。根據(jù)先前文件或本文件前面的每一個需求進展追蹤。 2） 向前追蹤〔即是向由SRS派生的所有文件追蹤〕。根據(jù)SRS中具有唯一的名字和參照號的每一個需求進展追蹤。 當SRS中的一個需求表達另一個需求的一種指派或者是派生的，向前、向后的追蹤都要提供。例如： 1） 從總的用戶響應(yīng)時間需求中分配給數(shù)據(jù)庫操作響應(yīng)時間； 2） 識別帶有一定功能和用戶接口的需求的報告格式； 3） 支持法律或行政上需要的某個軟件產(chǎn)品〔例如，計算稅收〕。在這種情況下，要指出軟件所支持確實切的法律或行政

40、文件。 當軟件產(chǎn)品進入運行和維護階段時，SRS的向前可追蹤性顯得特別重要。當編碼和設(shè)計文件作修改時，重要的是要查清這些修改所影響的全部需求。 4.3.7 運行和維護階段的可使用性 SRS必須滿足運行和維護階段的需要，包括軟件最終替換。 1） 維護常常是由與原來開發(fā)無聯(lián)系的人來進展的。局部的改變〔修正〕可以借助于好的代碼注釋來實現(xiàn)。對于較大范圍的改變。設(shè)計和需求文件是必不可少的，這里隱含了兩個作用： ? 如4.3.5 條指出，SRS必須是可修改的； ? SRS中必須包括一個記錄，它記錄那些應(yīng)用于各個成分的所有具體條文。例如：它們的危急性〔如故障可能危及完全或?qū)е麓罅控斦?/p>

41、面和社會方面的損失〕；它們僅與暫時的需要相關(guān)〔如支持一種可立即恢復原狀的顯示〕；它們的來源〔如某功能是由已存在的軟件產(chǎn)品的全部拷貝復制而成〕。 2） 要求在SRS中清楚地寫明功能的來源和目的，因為對功能的來源和引入該功能的目的不清楚的話，通常不可能很好地完成軟件的維護。 4.4 SRS的編制者 軟件開發(fā)的過程是由開發(fā)者和客戶雙方同意開發(fā)什么樣的軟件協(xié)議開場的。這種協(xié)議要使用SRS的形式，應(yīng)該由雙方聯(lián)合起草。這是因為： 1） 客戶通常對軟件設(shè)計和開發(fā)過程了解較少，而不能寫出可用的SRS； 2） 開發(fā)者通常對于客戶的問題和意圖了解較少，從而不可能寫出一個令人滿意的系統(tǒng)需求。

42、 4.5 SRS的改進 軟件產(chǎn)品的開發(fā)過程中，在工程的開場階段不可能詳細說明某些細節(jié)，在開發(fā)過程中可能發(fā)現(xiàn)SRS的缺陷、缺點和錯誤之類的問題，所以可能要對SRS進展改進。 在SRS的改進中，應(yīng)注意如下事項： 1） 盡管可以預(yù)見校正版本的開發(fā)以后不可防止，而對需求還必須盡可能完全、清楚地描述。 2） 一旦最初識別出工程的變化，應(yīng)引入一個正式的改變規(guī)程來標識、控制、追蹤和報告工程的改變。批準了的需求改變，用如下的方法編入SRS之中： ? 提供各種改變后的正確的、完全的審查記錄； ? 允許對SRS當前的和被替代局部的審查。 4.6 SRS的編制工具 編制SRS最顯而易

43、見的方法是用自然語言來描述。盡管自然語言是豐富多彩的，但不易準確，用形式化的方法較好。 4.6.1 形式化說明方法 在SRS中是否使用形式化方法要依據(jù)以下因素： 1) 程序規(guī)模和復雜性； 2) 客戶合同中是否要求使用； 3) SRS是否是一個合同工具或僅僅是一個內(nèi)部文件； 4) SRS文件是否成為設(shè)計文件的根據(jù)； 5) 具有支持這種方法的計算機設(shè)備。 4.6.2 生產(chǎn)工具 軟件產(chǎn)品生產(chǎn)中有多種生產(chǎn)工具。比方，計算機的字處理器就是非常有用的生產(chǎn)輔助工具。一個SRS通常有假設(shè)干作者。可能經(jīng)歷假設(shè)干版本，并且要進展屢次重新組織內(nèi)容。故生產(chǎn)工具是必要的。 4.6

44、.3 表達工具 在SRS中有許多詞匯，特別是許多名詞和動詞，專門涉及到系統(tǒng)的實體和許多活動，所以表達SRS需要假設(shè)干工具。比方： 1) 可以驗證實體或活動，無論在SRS中什么地方都是同一名字。 2) 可以標識一個特殊的實體或動作在規(guī)格說明中的描述位置。 此外，可以使用假設(shè)干種形式化方法，以便允許自動處理SRS內(nèi)容，只要作某些限制就可以做到： 用一些表格或圖示法來顯示需求。 用詳細分層體系自動檢查SRS的需求，這里每一個分層自身是完全的，但是也可以擴展為下一層，或是上一層的一個組成成分。 自動檢查SRS具有在4.3條描述的局部或全部特點。 5 軟件需求 SRS中每一

45、個軟件需求是要求開發(fā)軟件產(chǎn)品的某些 基本功能和性能的一個陳述。 5.1 表達軟件需求的方法 軟件需求可以用假設(shè)干種方法來表達： 1〕通過輸入、輸出說明； 2〕使用代表性的例子； 3〕用標準化的模型。 5.1.1 輸入、輸出說明 用輸入輸出序列來描述一個軟件產(chǎn)品所要求的特性是很有效的。 5.1.1.1 途徑 根據(jù)被描述的軟件的性質(zhì)，至少有三種不同的途徑： 1） 有些軟件產(chǎn)品〔如報表系統(tǒng)〕要求著重說明輸出。一般情況下，致力于輸出的系統(tǒng)主要是在數(shù)據(jù)文卷上操作。用戶的輸入通常是致力于提供控制信息和啟動數(shù)據(jù)文卷的處理； 2） 有些軟件產(chǎn)品需要著重說明輸入、輸

46、出特性。關(guān)注輸入、輸出的系統(tǒng)主要是在當前的輸入上操作，要求生成與輸入相匹配的輸出〔類似于數(shù)據(jù)轉(zhuǎn)換例行程序或一個數(shù)學函數(shù)包〕； 3） 還有一些系統(tǒng)〔如過程控制系統(tǒng)〕要求記憶它們的狀態(tài)。可以根據(jù)本次輸入和上一次輸入進展應(yīng)答。也就是說，它的行為如同一個有限狀態(tài)機。在此種情況下，既要關(guān)注輸入/輸出對，又要關(guān)注這些輸入/輸出對的次序。 5.1.1.2 困難 多數(shù)軟件產(chǎn)品可能接收無限的序列作為輸入，于是，為了通過輸入輸出序列完整地說明產(chǎn)品的特性，就要求SRS包括一個無限長的輸入和所需的輸出充列。然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。 5.1.2 典型例子 一種選擇是用

47、典型例子來說明要求的特性。例如，假設(shè)一個系統(tǒng)中當接收“0〞時用“1〞來答復。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型的序列可以十分清楚地理解系統(tǒng)的特性。下面是一組四種對話的典型的例子，用它描述系統(tǒng)特性。 0101 010101010101 01 010101 這些對話僅提供了要求的輸入和輸出之間的關(guān)系，但是不能完全描述系統(tǒng)的特性。 5.1.3 模型 另一種表達需求的方法是模型的方式，這是表達復雜需求的準確和有效方法。 至少可以提出三種可供使用的通用模型：數(shù)學型、功能型、計時型。應(yīng)注意區(qū)別各種模型的應(yīng)用場合，參考5.1.3.5。 5.1.3.1 數(shù)學

48、模型 數(shù)學模型是使用數(shù)學關(guān)系描述軟件特性的模型。數(shù)學模型對某些特殊應(yīng)用領(lǐng)域是特別有用的。例如，導航、線性規(guī)劃、計量經(jīng)濟、信號處理和氣象分析等。 用數(shù)學模型能夠?qū)?.1.2中所討論的典型例子描述如下： 〔01〕*。 這里，“*〞號表示括號內(nèi)的字符串可以重復一次或?qū)掖巍? 5.1.3.2 功能模型 功能模型是提供從略語以輸出映象的模型。象有限狀態(tài)機或Petri網(wǎng)，這些功能模型可以有助于標識和定義軟件的各種特點，或者可以表示系統(tǒng)所要進展的操作。 對前面用數(shù)學模型描述的例子?？捎脠D1所示的有限狀態(tài)機形式的功能模型來描述。圖中進入的箭頭表示啟動狀態(tài)。雙線的方框表示接收狀態(tài)。在各

49、線記號x/y的含義是：x代表承受的輸入，而y是產(chǎn)生的輸出。 5.1.3.3 計時模型 計時模型是一種增加了時間限制的模型。這種模型對于表達軟件特性的形式和細節(jié)特別有用。尤其是實時系統(tǒng)或考慮人為因素的系統(tǒng)。 計時模型可以把以下限制加到圖1的模型中去： 1〕激活因素0將在進入S1狀態(tài)30S之內(nèi)出現(xiàn)； 2〕響應(yīng)1將在進入S2狀態(tài)2S之內(nèi)出現(xiàn)。 5.1.3.4 其他模型 除了上面提及的模型外。對一些特殊的應(yīng)用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統(tǒng)可以使用表格。要注意的是，對SRS使用形式需求語言，通常含有使用特殊模型的意思。 5.1.3

50、.5 警告 無論使用哪一類型的模型，都要在SRS中或在SRS涉及到的一個文件中對它嚴格定義。這個定義應(yīng)該規(guī)定： 1〕模型中的參數(shù)所要求的范圍； 2〕使用時的限定值； 3〕結(jié)果的準確度； 4〕負載的能力； 5〕要求的執(zhí)行時間； 6〕缺省或失敗時的響應(yīng)。 必須注意，在需求的定義域內(nèi)要保持一個模型定義。每當一個SRS使用一個模型時： 1〕它意味著此模型提供一個十分有效和準確的方法說明需求； 2〕并不意味著軟件產(chǎn)品的實現(xiàn)必須基于這個模型。 一個模型用于解釋文件所寫的需求是有效的，但是對于實際軟件的實現(xiàn)可能并不是最適宜的。 5.2 軟件需求的注釋 有關(guān)

51、軟件產(chǎn)品的所有需求，并不是同等重要的。某些需求可能是 基本的，例如是對于生命攸關(guān)的應(yīng)用。而另一些可能并不那么重要。 SRS中每一個需求必須進展注釋，以便區(qū)別其重要的程度。 有這種方法注釋需求，可以： 1） 幫助客戶對每個需求給予更周密的考慮，通常可以在需求中澄清隱藏的假設(shè)； 2） 幫助開發(fā)者做出正確的設(shè)計決定，并對軟件產(chǎn)品不同局部作出相應(yīng)的努力。 5.2.1 穩(wěn)定性 注釋需求的一種方法是使用穩(wěn)定性量綱。當一個需求在軟件預(yù)期的生存期間內(nèi)描述不改變的話，可以認為該需求是穩(wěn)定的，否那么可以認為是易變的。 5.2.2 必要性等級 注釋的另一種方法是把需求分成必須保證級

52、、期望級和任選級。 5） 必須保證是指軟件必須和這些需求相一致，否那么該軟件不可能被承受； 6） 期望是指這些需求將提高軟件產(chǎn)品的功能，但如果缺省的話也是可承受； 7） 任選是給開發(fā)者一個時機，可以提供某些超出SRS規(guī)定的目標。 5.2.3 本卷須知 在注釋需求之前，必須徹底理解這種注釋的實質(zhì)性含義。 5.3 在表達需求時遇到的共同弊病 SRS的 基本點是它必須說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果的手段。編寫需求的人必須描述的 基本問題是： 1） 功能——所設(shè)計的軟件要做什么； 2） 性能——是指軟件功能在執(zhí)行過程中的速度、可使用性、響應(yīng)時間、各種軟件

53、功能的恢復時間、吞吐能力、精度、頻率等等； 3） 強加于實現(xiàn)的設(shè)計限制——在效果、實現(xiàn)的語言、數(shù)據(jù)庫完整性、資源限制、操作環(huán)境等等方面所要求的標準； 4） 屬性——可移植性、正確性、可維護性及安全性等方面的考慮因素； 5） 外部接口——與人、硬件、其他軟件和其他硬件的相互關(guān)系。 編寫需求的人應(yīng)當防止把設(shè)計或工程需求寫入SRS之中，應(yīng)當對說明需求設(shè)計約束與規(guī)劃設(shè)計兩者有清晰的區(qū)別。 5.3.1 在SRS中嵌入了設(shè)計 在SRS中嵌入設(shè)計說明，會過多地約束軟件設(shè)計，并且人為地把具有潛在不安全的需求放入SRS中。 1） SRS必須描述在干什么數(shù)據(jù)上、為誰完成什么功能、在什么

54、地方、產(chǎn)生什么結(jié)果。SRS應(yīng)把注意力集中在要完成的服務(wù)目標上。通常不指定如下的設(shè)計工程： ? 把軟件劃分成假設(shè)干模塊； ? 給每一個模塊分配功能； ? 描述模塊間的信息流程或者控制流程； ? 選擇數(shù)據(jù)構(gòu)造。 2） 把設(shè)計完全同SRS隔離開來始終是不現(xiàn)實的。安全和保密方面的周密考慮可能增加一些直接反映設(shè)計約束的需求。例如： ? 在一些分散的模塊中保持某些功能； ? 允許在程序的某些區(qū)域之間進展有限的通訊； ? 計算臨界值的檢查和。 3） 通常應(yīng)考慮到，假設(shè)要為軟件選擇高層次的設(shè)計，就可能需要大量的資源〔可能占整個產(chǎn)品開發(fā)成本的10%-20%以上〕。有兩種選擇：

55、 ? 不顧本指南的警告，在SRS中描述了設(shè)計。這意味著，或者將一個潛在不適當?shù)脑O(shè)計作為一個需求進展描述〔因為，假設(shè)要得到好的設(shè)計，所花費的時間是不夠的〕，或者在需求階段花費了過多的時間〔因為在SRS完成之前整個設(shè)計分析都要完成〕； ? 采用本指南中5.1.3條中的建議，用模型設(shè)計描述需求，這種模型設(shè)計只用于輔助描述需求，而不使之成為實際的設(shè)計。 5.3.2 在SRS中嵌入了一些工程要求 SRS應(yīng)當是描寫一個軟件產(chǎn)品，而不是描述生產(chǎn)軟件產(chǎn)品的過程。 工程要求表達客戶和開發(fā)者之間對于軟件生產(chǎn)方面合同性事宜的理解〔因此不應(yīng)當包括在SRS中〕例如： 1） 成本； 2） 交貨

56、進度； 3） 報表處理； 4） 軟件開發(fā)方法； 5） 質(zhì)量保證； 6） 確認和驗證的標準； 7） 驗收過程。 工程需求在另外文件中描述。在SRS中提供的只是關(guān)于軟件產(chǎn)品本身的需求。 6 SRS大綱 本章著重討論SRS的每一個 基本局部，可以作為一個SRS的大綱。表1給出該大綱目錄，表2至表5給出大綱中第3章的具體需求內(nèi)容。各開發(fā)者和客戶應(yīng)當根據(jù)所描述的實際情況，按本指南有關(guān)規(guī)定編寫自己的SRS。 1 前言 1.1 目的 1.2 范圍 1.3 定義、縮寫詞、略語 1.4 參考資料 2 工程概述 2.1 產(chǎn)品描述 2.2 產(chǎn)品功能

57、2.3 用戶特點 2.4 一般約束 2.5 假設(shè)和依據(jù) 3 具體需求 〔參閱本指南6.3.2 條中具體需求的組織形式〕 附錄 索引 6.1 前言〔SRS第1章〕 本章提供整個SRS綜述。 6.1.1 目的〔SRS的1.1條〕 在這一條包括以下內(nèi)容： 1〕描述實際SRS的目的； 2〕說明SRS所預(yù)期的讀者。 6.1.2 范圍〔SRS的1.2條〕 1） 通常應(yīng)考慮到，假設(shè)要為軟件選擇高層次的設(shè)計，就可能需要大量的資源〔可能占整個產(chǎn)品開發(fā)成本的10%-20%以上〕。有兩種選擇： 2） 用一個名字標識被生產(chǎn)的軟件產(chǎn)品。比方：×××數(shù)據(jù)庫系

58、統(tǒng)，報表生成程序等等； 3） 說明軟件產(chǎn)品將干什么，如果需要的話，還要說明軟件產(chǎn)品不干什么； 4） 描述所說明的軟件的應(yīng)用。應(yīng)當： ? 盡可能準確地描述所有相關(guān)的利閃、目的、以及最終目標。 ? 如果有一個較高層次的說明存在，那么應(yīng)該使其和高層次說明中的類似的陳述相一致〔例如，系統(tǒng)的需求規(guī)格說明〕。 6.1.3 定義、縮寫詞、略語〔SRS的1.3條〕 本條中必須提供全部需求的術(shù)語、縮寫詞及略語的定義，以便對SRS進展適當?shù)慕忉?。這些信息可以由SRS的附錄提供。也可以參考其他的文件。 6.1.4 參考資料〔SRS的1.4條〕 本條應(yīng)包括： 1） 在SRS中各處參

59、照的文件的全部清單，如經(jīng)核準的方案任務(wù)書，上級機關(guān)批文、合同等； 2） 列出其他參考資料，如屬本工程的其他已發(fā)表的文件和主要文獻等。每一個文件、文獻要有標題，索引號或文件號，發(fā)布或發(fā)表日期以及出版單位； 3） 詳細說明可以得到該參考文件的來源。這個信息可以通過引用附錄或其他文件提供。 6.2 工程概述〔SRS第2章〕 本章應(yīng)描述影響產(chǎn)品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易于理解。 6.2.1 產(chǎn)品描述〔SRS的2.1條〕 這一條是把一個產(chǎn)品用其他有關(guān)的產(chǎn)品或工程來描述。 1） 如果這個產(chǎn)品是獨立的，而且全部內(nèi)容自含，應(yīng)在此說明； 2） 如果SR

60、S定義的產(chǎn)品是一個較大的系統(tǒng)或工程中的一個組成局部，那么本條應(yīng)包括如下內(nèi)容： ? 要概述這個較大的系統(tǒng)或工程的每個組成局部的功能，并說明其接口； ? 指出該軟件產(chǎn)品主要的外部接口。在這里，不要求對接口詳細地描述，詳細描述放在SRS其他章條中； ? 描述所使用的計算機硬件、外圍設(shè)備。這里僅僅是一個綜述性描述。 在本條的描述中，用一個方框圖來表達一個較大的系統(tǒng)或工程的主要組成局部、相互聯(lián)系和外部接口是非常有幫助的。 本條既不用來強迫進展設(shè)計方案的描述，也不是描述在解決問題時的設(shè)計約束。本條應(yīng)對在以后具體需求一章中說明的設(shè)計約束提供理由。 6.2.2 產(chǎn)品功能〔SRS的2.2

61、條〕 本條是為將要完成的軟件功能提供一個摘要。例如，對于一個記帳程序來說，SRS可以用這局部來描述：客戶帳目維護、客戶財務(wù)報表和發(fā)票制作，而不必把功能所要求的大量的細節(jié)描寫出來。 有時，如果存在較高層次的規(guī)格說明時，那么功能摘要可直接從中取得，這個較高層次的規(guī)格說明為軟件產(chǎn)品分配了特殊的功能，為了清晰起見，請注意： 1） 編制功能的一種方法是制作功能表，以便客戶或者第一次讀這個文件的人都可以理解； 2） 用方框圖來表達不同的功能和它們的關(guān)系也是有幫助的。但要牢記，這樣的圖不是產(chǎn)品設(shè)計時所需求的，而只是一種有效的解釋性的工具。 這一條不用作陳述具體需求，只是對后來SRS中具體需

62、求一章中為什么要描述的某些需求提供理由。 6.2.3 用戶特點〔SRS的2.3條〕 本條要描述影響具體需求的產(chǎn)品的最終用戶的一般特點。 許多人在軟件生存周期的操作和維護階段與系統(tǒng)相關(guān)。而這些人中有用戶、操作員、維護人員和系統(tǒng)工作人員。這些人的某些特點，象教育水平、經(jīng)歷、技術(shù)、專長等，都是施加于系統(tǒng)操作環(huán)境的重要約束。 如果系統(tǒng)的大多數(shù)用戶是一些臨時用戶，那么就要求系統(tǒng)包含如何完成 基本功能的提示，而不是假設(shè)用戶已經(jīng)從過去的會議或從閱讀用戶指南中了解到這些細節(jié)。 這一條的內(nèi)容不能用來陳述具體需求或強加假設(shè)干特殊的設(shè)計約束，本條應(yīng)對在SRS的具體需求一章之中的某些具體需求或設(shè)

63、計約束的描述提供理由。 6.2.4 一般約束〔SRS的2.4條〕 本條對設(shè)計系統(tǒng)陽限制開發(fā)者選擇的其他一些項作一般性描述。而這些項將限定開發(fā)者在設(shè)計系統(tǒng)時的任選項。這些包括： 1） 管理方針； 2） 硬件的限制； 3） 與其他應(yīng)用間的接口； 4） 并行操作； 5） 審查功能； 6） 控制功能； 7） 所需的高級語言； 8） 通信協(xié)議； 9） 應(yīng)用的臨界點； 10〕安全和保密方面的考慮。 本條不陳述具體需求或具體設(shè)計約束：而對SRS的具體需求一章中為什么要確定某些具體需求和設(shè)計約束提供理由。 6.2.5 假設(shè)和依據(jù)〔SRS的2.5條〕 本

64、條列出影響SRS中陳述的需求的每一個因素。這些因素不是軟件的設(shè)計約束，但是它們的改變可能影響到SRS中的需求。例如：假定一個特定的操作系統(tǒng)是在被軟件產(chǎn)品指定的硬件上使用的，然而，事實上這個操作系統(tǒng)是不可能使用的，于是，SRS就要進展相應(yīng)的改變。 6.3 具體需求〔SRS的第3章〕 本章應(yīng)包括軟件開發(fā)者在建設(shè)設(shè)計時需要的全部細節(jié)。這是SRS中篇幅最大和最重要的局部。 1） 根據(jù)本指南第4章所規(guī)定的準那么〔如可驗證性、無歧義性等〕，對每一個需求細節(jié)作具體描述； 2） 在SRS的前言、工程概述、附錄局部的有關(guān)討論中，要提供對任何一個具體需求穿插引用的背景； 3） 具體需求分類的方

65、法如下： ? 功能需求； ? 性能需求； ? 設(shè)計約束； ? 屬性； ? 外部接口需求。 本章中要注意的二點是： 1） 符合邏輯的和可讀的方式組織； 2） 詳細描述每個需求，使該需求應(yīng)到達目標能夠用指定的方法進展客觀的驗證。 6.3.1 具體需求的內(nèi)容 6.3.1.1 功能需求 本條描述軟件產(chǎn)品的輸入怎樣變換成輸出。即軟件必須完成的 基本動作。 對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。這通常由四個部頒組成： 1） 引言 這局部描述的是功能要到達的目標、所采用的方法和技術(shù)，還應(yīng)清楚說明功能意圖的由來和背景。

66、 2） 輸入 這局部應(yīng)包括： ? 詳細描述該功能的所有輸入數(shù)據(jù)，如：輸入源、數(shù)量、度量單位、時間設(shè)定、有效輸入范圍〔包括精度和公差〕； ? 操作員控制細節(jié)的需求。其中有名字、操作員活動的描述、控制臺或操作員的位置。例如：當打印檢查時，要求操作員進展格式調(diào)整； ? 指明引用接口說明或接口控制文件的參考資料。 3） 加工 定義輸入數(shù)據(jù)、中間參數(shù)，以獲得預(yù)期輸出結(jié)果的全部操作。它包括如下的說明： ? 輸入數(shù)據(jù)的有效性檢查； ? 操作的順序，包括事件的時間設(shè)定； ? 異常情況的響應(yīng)，例如，溢出、通信故障、錯誤處理等； ? 受操作影響的參數(shù)； ? 降級運行的要求； ? 用于把系統(tǒng)輸入變換成相應(yīng)輸出的任何方法〔方程式、數(shù)學算法、邏輯操作等〕； ? 輸出數(shù)據(jù)的有效性檢查。 4） 輸出 這局部應(yīng)包括： ? 詳細描述該功能所有輸出數(shù)據(jù)，例如：輸出目的地、數(shù)量、度量單位、時間關(guān)系、有效輸出的范圍〔包括精度和公差〕、非法值的處理、出錯信息； ? 有關(guān)接口說明或接口控制文件的參考資料。 此外，對著重于輸入輸出行為的系統(tǒng)來說，SRS應(yīng)指定