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

2、2.1 目標 敘述該系統(tǒng)開發(fā)的意圖、 應用目標、 作用范圍以及其他應向讀者說明的有關(guān)該系統(tǒng) 開發(fā)的背景材料。解釋被開發(fā)系統(tǒng)與其他有關(guān)系統(tǒng)之間的關(guān)系。 2.2 用戶的特點列出本系統(tǒng)的最終用戶的特點， 充分說明操作人員、 維護人員的教育水平和技術(shù)專 長，以及本系統(tǒng)的預期使用頻度。 2.3 假定和約束 列出進行本系統(tǒng)開發(fā)工作的假定和約束。3需求規(guī)定3.1 對功能的規(guī)定用列表的方式， 逐項定量和定性地敘述對系統(tǒng)所提出的功能要求，說明輸入什么量、經(jīng)怎么樣的處理、 得到什么輸出， 說明系統(tǒng)的容量 ,包括系統(tǒng)應支持的終端數(shù)和應支持的 并行操作的用戶數(shù)等指標。 3.2 對性能的規(guī)定3.2.1 精度 說明對該系

3、統(tǒng)的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。3.2.2 時間特性要求 說明對于該系統(tǒng)的時間特性要求。 3.2.3 靈活性 說明對該系統(tǒng)的靈活性的要求，即當需求發(fā)生某些變化時，該系統(tǒng)對這些變 化的適應能力。 3.3 輸入輸出要求 解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。對系統(tǒng)的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例。 3.4 數(shù)據(jù)管理能力要求（針對軟件系統(tǒng)）說明需要管理的文卷和記錄的個數(shù)、 表和文卷的大小規(guī)模， 要按可預見的增長對數(shù) 據(jù)及其分量的存儲要求作出估算。 3.5 故障處理要求列出可能的軟件、硬件故障以及對各項性能而言所產(chǎn)生的后果和對故障處理的

4、要 求。 3.6 其他專門要求如用戶單位對安全保密的要求， 對使用方便的要求， 對可維護性、 可補充性、 易讀 性、可靠性、運行環(huán)境可轉(zhuǎn)換性的特殊要求等。 4運行環(huán)境規(guī)定4.1 設備列出運行該軟件所需要的硬設備。說明其中的新型設備及其專門功能，包括：a. 處理器型號及內(nèi)存容量b. 外存容量、聯(lián)機或脫機、媒體及其存儲格式，設備的型號及數(shù)量c. 輸入及輸出設備的型號和數(shù)量，聯(lián)機或脫機；d. 數(shù)據(jù)通信設備的型號和數(shù)量e. 功能鍵及其他專用硬件 4.2 支持軟件列出支持軟件，包括要用到的操作系統(tǒng)、編譯程序、測試支持軟件等。4.3 接口說明該系統(tǒng)同其他系統(tǒng)之間的接口、數(shù)據(jù)通信協(xié)議等。4.4 控制說明控制

5、該系統(tǒng)的運行的方法和控制信號，并說明這些控制信號的來源。需求規(guī)格說明書 (Volere 版 )編者說明：Atlantic System Guild ( )公司所提供的 Volere 需求過程與軟件需求 規(guī)格說明書模板則充分利用了現(xiàn)代軟件工程思想與技術(shù)，是一個十分實用、完善的 SRS 模 板。其所提供的 Volere 需求記錄卡也十分實用，強烈推薦。注：從 Atlantic System Guild 公司網(wǎng)站 上獲得，并稍做修改1. 產(chǎn)品的目標1.1 該項目工作的用戶問題或背景對引發(fā)開發(fā)任務的工作和情況的描述。 同時也應描述用戶希望用將要交付的軟件來 完成的工作。 該節(jié)內(nèi)容為該項目提供了合法的理

6、由，你應該考慮用戶的問題是否嚴重，是否應 該解決和為什么應該解決。 1.2 產(chǎn)品的目標用一句話或很少的幾句話來說明 “我們希望該產(chǎn)品做什么？” 換言之， 即開發(fā)該產(chǎn) 品的真正原因。項目如果沒有一個表述清晰、易于理解的目標，就會迷失在產(chǎn)品開發(fā)的沙漠中。 產(chǎn)品必須帶來某種優(yōu)勢。 典型的優(yōu)勢是產(chǎn)品會增加組織在市場上的價值， 減少運作成本， 或提供更好的客戶服務。這個優(yōu)勢應該是可度量的，這樣才能夠讓您確定交付的產(chǎn)品是 否達到目標。 2. 客戶、顧客和其它風險承擔者2.1 客戶是為開發(fā)付費的人，并將成為所交付產(chǎn)品的擁有者這一項必須給出客戶的姓名，三個以內(nèi)是合理的。客戶最終將接受該產(chǎn)品，因此必須對交付的產(chǎn)

7、品滿意。如果你無法找到一個客戶 的姓名，那么也許你就不應該構(gòu)建該產(chǎn)品。 2.2 顧客是將花錢購買該產(chǎn)品的人也給出姓名和相關(guān)的信息 2.3 其它風險承擔者其他的一些人或組織的名稱，他們或者受到產(chǎn)品的影響，或影響產(chǎn)品。1) 經(jīng)理或項目負責人；2) 業(yè)務領(lǐng)域?qū)＜遥?) 技術(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) 用戶工作的任務；3) 主要相關(guān)

8、的經(jīng)驗；4) 技術(shù)經(jīng)驗；5) 其他用戶特征：包括身體、智力、工作態(tài)度、對技術(shù)的態(tài)度、教育程度、語言 技能、年齡、性別等。用戶是為了完成工作而與產(chǎn)品交互的人，你了解用戶，就越可能提交適合用 戶工作方式的產(chǎn)品。 3.2 對用戶設的優(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)品或組織更重要，那么應該寫明，因為它會影響你設 計產(chǎn)品的方式。 4. 需求限制條件4.1 解決方案限制條件 此處明確了限制條件，

9、它們規(guī)定了解決問題必須采取的方式。 您可以認為它們是指 令式的解決方案。仔細描述該解決方案，以及測試是否符合的度量標準。如果可能，您 應該解釋使用該解決方案的原因。 換一句話說，就是要求軟件解決方案滿足哪些限制條件！ 4.2 實現(xiàn)環(huán)境 此處描述產(chǎn)品將被實施的技術(shù)環(huán)境和物理環(huán)境。 該環(huán)境也將成為設計解決方案時的限制條件之一。 4.3 伙伴應用 此處描述那些不屬于產(chǎn)品的一部分，但產(chǎn)品卻又必須與其協(xié)作的應用程序。4.4 COTS 此處描述實現(xiàn)產(chǎn)品需求所必須使用的COTS( 商業(yè)組件 )。4.5 預期的工作場地環(huán)境 此處描述用戶工作和使用該產(chǎn)品的工作場地。此處應該描述任何可能對產(chǎn)品設計產(chǎn)生影響的工作場

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

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

12、的主題域相關(guān)的業(yè)務對象、實體、類的說明書。 進行問題域建模，生成相應的類圖。 10. 觀感需求 一些與產(chǎn)品的用戶界面相關(guān)的需求描述。11. 易用性需求11.1 易于使用 描述如何構(gòu)建符合最終用戶期望的產(chǎn)品。11.2 學習的容易程序 學習使用該產(chǎn)品應該多容易的說明。通常是有學習時間來衡量。12. 性能要求12.1 速度需求 明確完成特定任務需要的時間，這常常指響應時間。12.2 安全性的需求 對可能造成人身傷害、財產(chǎn)損失和環(huán)境破壞所考慮到的風險進行量化描述。12.3 精度需求 對產(chǎn)品產(chǎn)生的結(jié)果期望的精度進行量化描述。12.4 可靠性和可用性需求 本節(jié)量化產(chǎn)品所需的可靠性。這常常表述為允許的兩次失

13、敗之間無故障運行時間， 或允許的總失敗率。 12.5 容量需求 本節(jié)明確處理的吞吐量和產(chǎn)品存儲數(shù)據(jù)的容量。13. 操作需求13.1 預期的物理環(huán)境 本節(jié)明確產(chǎn)品將操作的物理環(huán)境，以及這種環(huán)境引起的任何特殊需求。13.2 預期的技術(shù)環(huán)境 硬件和其它組成新產(chǎn)品操作環(huán)境的設備的規(guī)范。13.3 伙伴應用程序?qū)Ξa(chǎn)品必須與之交互的其它應用程序的描述。14. 可維護性和可移植性需求14.1 維護該產(chǎn)品需要多容易 對產(chǎn)品作特定修改所需時間的量化描述。14.2 是否存在一些特殊情況適用于該產(chǎn)品的維護 關(guān)于預期的產(chǎn)品發(fā)布周期和發(fā)布將采取的形式的規(guī)定。14.3 可移植性需求 對產(chǎn)品必須支持的其他平臺或環(huán)境的描述。1

14、5. 安全性需求15.1 該產(chǎn)品是保密的嗎？ 關(guān)于該被授權(quán)使用該產(chǎn)品，以及在什么樣的情況下授權(quán)等方面的描述。15.2 文件完整性需求 關(guān)于需要的數(shù)據(jù)庫和其他文件完整性方面的說明。15.3 審計需求 關(guān)于需要的審計檢查方面的說明。 16. 文件和政策需求 本節(jié)包括針對社會和政策的因素的規(guī)格說明，這些因素會影響產(chǎn)品的可接受性。如果你開發(fā)的產(chǎn)品是針對外國市場的，可能要特別注意這些需求。 問一下是否產(chǎn)品的目標是你所不熟悉的文化環(huán)境，是否其它國家的人或其他類型的組 織的人會使用該產(chǎn)品。人們是否有與你的文化不同的習慣、節(jié)日、迷信、文化上的社會行為 規(guī)范。17. 法律需求17.1 該產(chǎn)品是否受到某些法律的管

15、制 明確該產(chǎn)品的法律需求的描述。 17.2 是否有一些必須符合的標準 明確適用的標準和參考的詳細標準的描述。18.Opend 問題 對未確定但可能對產(chǎn)品產(chǎn)生重要影響的因素的問題描述。按照需求分析的術(shù)語還說， 就是 TBD ( To Be Define )的問題。 19. COTS 解決方案19.1 是否有一些制造好的產(chǎn)品可以購買 應該調(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)境中

16、帶來什么問題 關(guān)于新產(chǎn)品將怎樣影響當前的實現(xiàn)環(huán)境的描述。20.2 新的開發(fā)是否將影響某些已實施的系統(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 預期的實現(xiàn)環(huán)境會存在什么限制新產(chǎn)品的因素 關(guān)于新的自動化技術(shù)、新的組織結(jié)構(gòu)方式的任何潛在問題的描述。20.5 是否新產(chǎn)品會帶來其他問題 確定我們可能不能處理的情況。 21. 任務21.1 為提交該產(chǎn)品已經(jīng)做了哪些事 用來開發(fā)產(chǎn)品的生命周期和方法的細節(jié)。 畫一個高層的過程圖展示各項任務和它們 之間的接口，這可能是溝通這方面信息的最好辦法。 21.2 開

17、發(fā)階段 關(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)換任務清單，同時確定新產(chǎn)品需要轉(zhuǎn)換的數(shù)據(jù)。23. 風險23.1 當你開發(fā)該產(chǎn)品時，要面對什么風險23.2 你制定了怎樣的偶然緊急情況計劃24. 費用 需求的其他費用是你必須投入到產(chǎn)品構(gòu)建中去的錢或工作量。當需求規(guī)格說明書完成 時，你可以使用一種估算方法來評估費用， 然后以構(gòu)建所需的資金或時間的形式表述出來。 25. 用戶文檔用戶文檔的清單，這些文檔將作為產(chǎn)品的一部分交付。26.

18、后續(xù)版本的需求這里記錄下一些希望今后版本中實現(xiàn)的需求。Volere需求記錄卡編者說明： 正如前面所述， Atlantic System Guild 還提供了一個配套的 Volere 需求記錄卡，這個記 錄卡十分實用。建議大家在需求調(diào)查、分析過程中，將需求記錄在一系列的 Volere 需求記 錄卡上，這個卡讓你能夠很好的理清需求之間的關(guān)系， 需求提出的背景， 用戶對需求的期望， 有了這些素材，整理 SRS 時將變得更加簡單。需求#：需求類型：事件/用例 #：描述：理由：來源：驗收標準：顧客滿意度：依賴關(guān)系： 支持材料： 歷史：顧客不滿意度： 沖突：VolereCopyright Atiantic

19、 system Gui注：顧客滿意度是指完成該項功能顧客滿意的程度，而顧客不滿意度則是指未實現(xiàn)該功能顧客不滿意的程度。軟件需求規(guī)格說明書( RUP版)編者說明：如果在需求分析時采用了用例( Use case)技術(shù)，那么該需求規(guī)格說明書將更加符合你 的需要。當然，你也可以結(jié)合 Volere 需求規(guī)格說明書對該模板進行必要的修改。1. 文檔概述 該部分主要是對軟件需求規(guī)格說明書文檔進行基本的描述，包括該文檔的目的、 范圍、術(shù)語定義、參考資料以及概要。 軟件需求規(guī)格說明書用來系統(tǒng)、完整地記錄系統(tǒng)的軟件需求。該軟件需求說明書的基 礎(chǔ)是用例分析技術(shù)。因此該文檔中應包括用例模型、補充規(guī)約等內(nèi)容。 1.1

20、目的在此小節(jié)中， 主要對軟件需求規(guī)格說明書的目的做一概要性說明，通常軟件需求規(guī)格說明書應詳細地說明應用程序、子系統(tǒng)的外部行為，還要說明非功能性需求、設計約 束，以及其它的相關(guān)因素。 1.2 范圍系統(tǒng)是有范圍的， 而不是無限擴展的， 對于無限擴展的需求是無法進行描述的。 因 此，在本小節(jié)應該對該說明書所涉及的項目范圍進行清晰的界定。指定該規(guī)格說明書適 用的軟件應用程序、特性或者其它子系統(tǒng)分組、其相關(guān)的用例模型。當然在此也需要列 出會受到該文檔影響的其它文檔。 1.3 定義、首字母縮寫詞和縮略語與其它文檔一樣， 該文檔也需要將本文檔中所涉及的所有術(shù)語、縮略語進行詳細的定義。還有一種可簡明的做法，就

21、是維護在一個項目詞匯表中，這樣就可以避免在每個 文檔中都重復很多內(nèi)容。 1.4 參考資料在這一小節(jié)中， 應完整地列出該文檔引用的所有文檔。 對于每個引用的文檔都應該 給出標題、標識號、日期以及來源，為閱讀者查找這些文檔提供足夠詳細的信息。 1.5 概述在本小節(jié)中， 主要是說明軟件需求規(guī)格說明書各個部分所包含的主要內(nèi)容，就像一個文章摘要一樣。同時也應該對文檔的組織方式進行解釋。 2. 整體說明 在本節(jié)中，將對整個軟件需求進行總體性的描述，以期讓讀者對整個軟件系統(tǒng)的需求 有一個框架性的認識。 也就是說， 該節(jié)中主要包括影響產(chǎn)品及其需求的一般因素， 而不列舉 具體的需求。主要包括產(chǎn)品總體效果、產(chǎn)品功

22、能、用戶特征、約束、假設與依賴關(guān)系、需求 子集等方面的內(nèi)容。 2.1 用例模型在本小節(jié)中， 將列出該軟件需求的用例模型， 該模型處于系統(tǒng)級， 對系統(tǒng)的特性進 行宏觀的描述。在此應該列出所有的用例和 Actor 的名稱列表，并且對其做出簡要的說 明，以及在圖中的各種關(guān)系。 2.2 假設與依賴關(guān)系在軟件系統(tǒng)的開發(fā)過程中， 存在許多假設和依賴關(guān)系。 在本小節(jié)中應列舉出所有的 重要的技術(shù)可行性假設、子系統(tǒng)或構(gòu)件可用性假設，以及一些可行性的假設。 3. 具體需求 如果說第二章節(jié)是框架，那么本節(jié)就是血肉。在本節(jié)中，應該詳細列出所有的軟件需 求，其詳細程序應使設計人員能夠充分理解并且進行設計的要求， 同時也

23、應該給予測試人員 足夠的信息， 以幫助他們來驗證系統(tǒng)是否滿足了這些需求。 整個需求的組織可以采用用例描 述進行。 3.1 用例描述如果你使用用例建模技術(shù)， 那么你已經(jīng)通過用例定義了系統(tǒng)的大部分功能性需求和 一些非功能性需求。因此，在軟件需求規(guī)格說明書只需將這些具體的用例描述，整理在 一起，全部放在該小節(jié)之中。當然也可以將用例描述做為附件，在此列出引用，只是這 樣做并不利于閱讀。建議在組織形式上采用以“軟件需求”為線索，在每個需求中，填 入對應的 1 個或幾個用例描述。 3.2 補充需求由于用例畢竟主要針對功能性需求， 因此還會有一些其它的補充需求遺漏， 因此在 本小節(jié)中就是將這些東西補充出來。

24、這些補充需求大部分集中在非功能需求之上，包括 以下幾個方面的內(nèi)容： 1）易用性：例如指出普通用戶和高級用戶要高效地執(zhí)行某個特定操作所需的培訓 時間； 指出典型任務的可評測任務次數(shù)； 或者指出需要滿足的可用性標準 （如 IBM 的 CUA 標準、 Microsoft 的 GUI 標準。2）可靠性：包括系統(tǒng)可用性（可用時間百分比、使用小時數(shù)、維護訪問權(quán)、降紙 模式操作等） ；平均故障間隔時間（ MTBF ，通常表示為小時數(shù)，但也可表示 為天數(shù)、月數(shù)或年數(shù)） ；平均修復時間（ MTTR ，系統(tǒng)在發(fā)生故障后可以暫停 運行的時間） ；精確度（指出系統(tǒng)輸出要求具備的精密度、分辨率和精確度） ； 最高錯誤或

25、缺陷率（通常表示為 bugs/KLOC ，即每千行代碼的錯誤數(shù)目或 bugs/function-point ，即每個功能點的錯誤數(shù)目） ；錯誤或缺陷率 （按照小錯誤、 大錯誤和嚴重錯誤來分類：需求中必須對“嚴重”錯誤進行界定，例如：數(shù)據(jù) 完全丟失或完全不能使用系統(tǒng)的某部分功能） 。3）性能：包括對事務的響應時間（平均、最長） ；吞吐量（例如每秒處理的事務 數(shù)）；容量（例如系統(tǒng)可以容納的客戶或事務數(shù)） ；降級模式 （當系統(tǒng)以某種形 式降級時可接受的運行模式） ；資源利用情況：內(nèi)存、磁盤、通信等。4）其它：包括用戶界面要求、聯(lián)機幫助系統(tǒng)要求、法律許可、外購構(gòu)件，以及操 作系統(tǒng)、開發(fā)工具、數(shù)據(jù)庫系統(tǒng)

26、等設計約束。4. 支持信息 支持信息用于使軟件需求規(guī)格說明書更易于使用。它包括：目錄、索引、附錄等。 計算機軟件需求說明編制指南（國標版）編者說明： 軟件需求規(guī)格說明是十分重要的文檔， 因此為開發(fā)團隊提供一份詳細的編制指南是十分 有意義和必要的。 本文檔就是一個編制指南的例子， 你可以根據(jù)該指南， 結(jié)合自己的實際情 況進行修改。1引言1.1 目的和作用 本指南為軟件需求實踐提供了一個規(guī)范化的方法。本指南不提倡把軟件需求說明（ Software Requirements Specifications ，以下簡稱 SRS）劃分成等級，避免把它定義成 更小的需求子集。本指南適用對象：1）軟件客戶（

27、Customers），以便精確地描述他們想獲得什么樣的產(chǎn)品。2）軟件開發(fā)者（ Suppliers ），以便準確地理解客戶需要什么樣的產(chǎn)品。 對于任一要實現(xiàn)下列目標的單位和（或）個人：1）要提出開發(fā)規(guī)范化的 SRS 提綱；2）定義自己需要的具體的格式和內(nèi)容；3）產(chǎn)生附加的局部使用條款，如 SRS 質(zhì)量檢查清單或者 SRS 作者手冊等。SRS 將完成下列目標：1）在軟件產(chǎn)品完成目標方面為客戶和開發(fā)者之間建立共同協(xié)議創(chuàng)立一個基礎(chǔ)。對要實現(xiàn)的軟件功能做全面描述， 幫助客戶判斷所規(guī)定的軟件是否符合他們的要 求，或者怎樣修改這種軟件才能適合他們的要求；2）提高開發(fā)效率。編制 SRS 的過程將使客戶在設計開

28、始之前周密地思考全部需 求，從而減少事后重新設計、重新編碼和重新測試的返工活動。在 SRS 中對 各種需求仔細地進行復查， 還可以在開發(fā)早期發(fā)現(xiàn)若干遺漏、 錯誤的理解和不 一致性，以便及時加以糾正；3）為成本計價和編制計劃進度提供基礎(chǔ)。 SRS 提供的對被開發(fā)軟件產(chǎn)品的描述， 是計算機軟件產(chǎn)品成本核算的基礎(chǔ)，并且可以為各方的要價和付費提供依據(jù)。 SRS 對軟件的清晰描述，有助于估計所必須的資源，并用作編制進度的依據(jù)；4）為確認和驗證提供一個基準。 任何組織將更有效地編制他們的確認和驗證計劃。 作為開發(fā)合同的一部分， SRS 還可以提供一個可以度量和遵循的基準（然而， 反之則不成立， 即任一有關(guān)

29、軟件的合同都不能作為 SRS。因為這種文件幾乎不 包括詳盡的需求說明，并且通常不完全的） ；5）便于移植。有了 SRS 就便于移值軟件產(chǎn)品，以適應新的用戶或新的機種。客 戶也易于移植其軟件到其他部門， 而開發(fā)者同樣也易于把軟件移植到新的客戶；6）作為不斷提高的基礎(chǔ)。由于 SRS 所討論的是軟件產(chǎn)品，而不是開發(fā)這個產(chǎn)品 的設計。因此 SRS 是軟件產(chǎn)品繼續(xù)提高的基礎(chǔ)。雖然 SRS 也可能要改變，但 是原來的 SRS 還是軟件產(chǎn)品改進的可靠基礎(chǔ)。1.2 范圍 本指南適用于編寫軟件需求規(guī)格說明， 它描述了一個 SRS 所必須的內(nèi)容和質(zhì)量， 并 且在第 6 章中提供了 SRS 大綱。2引用標準GB 8

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

31、分成若干部分。開發(fā)者( supplier )：指為客戶生產(chǎn)某種軟件產(chǎn)品的個人或集團。在本指南中，客戶和 開發(fā)者可能是同一個組織的成員。用戶( user )：指運行系統(tǒng)或者直接與系統(tǒng)發(fā)生交互作用的個人或集團。用戶和客戶通 常不是同一些人。4編寫 SRS的背景信息4.1 SRS 的基本要求 SRS是對要完成一定功能、 性能的軟件產(chǎn)品、 程序或一組程序的說明。 對 SRS的描 述有兩項基本要求：1) 必須描述一定的功能、性能；2) 必須用確定的方法敘述這些功能、性能。4.2 SRS 的環(huán)境必須認識到 SRS 在整個軟件開發(fā)規(guī)范(見 GB 8566)所規(guī)定的有關(guān)階段都起作用。 正因為如此， SRS 的

32、起草者必須特別注意不要超出這種作用的范圍。這意味著要滿足下 列要求：1) SRS 必須正確地定義所有的軟件需求；2) 除設計上的特殊限制之外， SRS 中一般不描述任何設計、 驗證或項目管理細節(jié)。4.3 SRS 的特點4.3.1 無歧義性 當且僅當它對每一個需求只有一種解釋時， SRS 者是無歧義的。1) 要求最終產(chǎn)品的每一個特性用某一術(shù)語描述；2) 若某一術(shù)語在某一特殊的行文中使用時具有多種歧義，那么對該術(shù)語的每種含義作出解釋并指出其適用場合。需求通常是用自然語言編寫的，使用自然語言的 SRS 起草者必須特別注意消 除其需求的歧義性。提倡使用形式化需求說明語言。4.3.2 完整性如果一個 S

33、RS 能滿足下列要求，則該 SRS 就是完整的：1) 包括全部有意義的要求，無論是關(guān)系到功能的、性能的、設計約束的，還 是關(guān)系到屬性或外部接口方面的需求；2) 對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應予以定義，要對合法和非合法的輸入值的響應做出規(guī)定；3) 要符合 SRS 要求。如果個別章節(jié)不適用，則在 SRS中要保留章節(jié)號；4) 填寫 SRS 中的全部插圖、 表、圖示標記和參照， 并且定義全部術(shù)語和度量 單位。4.3.2.1 關(guān)于使用“待定”一詞的規(guī)定 任何一個使用“待定”的 SRS 都是不完全的。1) 若萬一遇到使用“待定”一詞時，作如下處理： 對產(chǎn)生“待定”一詞的條件進行描述，使得問題能被解決； 描

34、述必須干什么事，以刪除這個“待定” ；2) 包含有“待定”一詞的任何 SRS的項目文件應該： 標識與此特定文件有關(guān)的版本號或敘述其專門的發(fā)布號； 拒絕任何仍標識為“待定”一詞的 SRS章節(jié)的許諾。4.3.3 可驗證性當且僅當 SRS 中描述的每一個需求都是可以驗證的， 該 SRS才是可以驗證的； 當且僅當在某一性能價格比可取的有限處理過程，人或機器能通過該過程檢查軟 件產(chǎn)品能否滿足需求時，才稱這個需求是可以驗證的。4.3.4 一致性當且僅當 SRS 中各個需求的描述是不矛盾時 SRS才是一致的。4.3.5 可修改性如果一個 SRS 的結(jié)構(gòu)和風格在需求有必要改變時是易于實現(xiàn)的、完整性的、 一致的

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

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

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

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

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

40、言是豐富多彩的， 但 不易精確，用形式化的方法較好。4.6.1 形式化說明方法在 SRS中是否使用形式化方法要依據(jù)下列因素：1) 程序規(guī)模和復雜性；2) 客戶合同中是否要求使用；3) SRS 是否是一個合同工具或僅僅是一個內(nèi)部文件；4) SRS 文件是否成為設計文件的根據(jù)；5) 具有支持這種方法的計算機設備。4.6.2 生產(chǎn)工具 軟件產(chǎn)品生產(chǎn)中有多種生產(chǎn)工具。比如，計算機的字處理器就是非常有用的 生產(chǎn)輔助工具。一個 SRS 通常有若干作者。可能經(jīng)歷若干版本，并且要進行多次 重新組織內(nèi)容。故生產(chǎn)工具是必要的。4.6.3 表達工具在 SRS 中有許多詞匯，特別是許多名詞和動詞，專門涉及到系統(tǒng)的實體

41、和許 多活動，所以表達 SRS 需要若干工具。比如：1) 可以驗證實體或活動，無論在 SRS中什么地方都是同一名字。2）可以標識一個特殊的實體或動作在規(guī)格說明中的描述位置。 此外，可以使用若干種形式化方法，以便允許自動處理 SRS 內(nèi)容，只要作某 些限制就可以做到：用一些表格或圖示法來顯示需求。 用詳細分層體系自動檢查 SRS 的需求，這里每一個分層自身是完全的，但是 也可以擴展為下一層，或是上一層的一個組成成分。自動檢查 SRS 具有在 4.3 條描述的部分或全部特點。5 軟件需求 SRS中每一個軟件需求是要求開發(fā)軟件產(chǎn)品的某些基本功能和性能的一個陳述。5.1 表達軟件需求的方法 軟件需求可

42、以用若干種方法來表達：1）通過輸入、輸出說明；2）使用代表性的例子；3）用規(guī)范化的模型。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)品需要著重說明輸入、輸出特性。關(guān)注輸入、輸出的系統(tǒng)主要 是在當前的輸入上操作，要求生成與輸入相匹配的輸出（類似于數(shù)據(jù)轉(zhuǎn)換 例行程序或一個數(shù)學函數(shù)包） ；3）還有一些系統(tǒng)（如過程控制

43、系統(tǒng)）要求記憶它們的狀態(tài)。可以根據(jù)本次輸 入和上一次輸入進行應答。也就是說，它的行為如同一個有限狀態(tài)機。在 此種情況下，既要關(guān)注輸入 /輸出對，又要關(guān)注這些輸入 /輸出對的次序。5.1.1.2 困難 多數(shù)軟件產(chǎn)品可能接收無限的序列作為輸入，于是，為了通過輸入輸出序列 完整地說明產(chǎn)品的特性，就要求 SRS 包括一個無限長的輸入和所需的輸出充列。 然而，用這樣的途徑不可能完整地描述軟件所要求的一切特性。5.1.2 典型例子 一種選擇是用典型例子來說明要求的特性。 例如，假設一個系統(tǒng)中當接收 “ 0” 時用“ 1”來回答。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型 的序列可以十分清楚地理

44、解系統(tǒng)的特性。下面是一組四種對話的典型的例子，用 它描述系統(tǒng)特性。0101 01010101010101 010101 這些對話僅提供了要求的輸入和輸出之間的關(guān)系，但是不能完全描述系統(tǒng)的 特性。5.1.3 模型 另一種表達需求的方法是模型的方式， 這是表達復雜需求的精確和有效方法。至少可以提出三種可供使用的通用模型：數(shù)學型、功能型、計時型。應注意區(qū)別 各種模型的應用場合，參考 5.1.3.5。5.1.3.1 數(shù)學模型 數(shù)學模型是使用數(shù)學關(guān)系描述軟件特性的模型。數(shù)學模型對某些特殊應用領(lǐng) 域是特別有用的。例如，導航、線性規(guī)劃、計量經(jīng)濟、信號處理和氣象分析等。用數(shù)學模型能夠?qū)?5.1.2 中所討論的

45、典型例子描述如下： （01）*。這里，“ *”號表示括號內(nèi)的字符串可以重復一次或多次。5.1.3.2 功能模型 功能模型是提供從略語以輸出映象的模型。象有限狀態(tài)機或 Petri 網(wǎng)，這些 功能模型可以有助于標識和定義軟件的各種特點，或者可以表示系統(tǒng)所要進行的 操作。對前面用數(shù)學模型描述的例子。可用圖 1 所示的有限狀態(tài)機形式的功能模型 來描述。圖中進入的箭頭表示啟動狀態(tài)。雙線的方框表示接收狀態(tài)。在各線記號 x/y 的含義是： x 代表接受的輸入，而 y 是產(chǎn)生的輸出。5.1.3.3 計時模型 計時模型是一種增加了時間限制的模型。這種模型對于表達軟件特性的形式 和細節(jié)特別有用。尤其是實時系統(tǒng)或考

46、慮人為因素的系統(tǒng)。計時模型可以把下列限制加到圖 1 的模型中去：1）激活因素 0 將在進入 S1狀態(tài) 30S之內(nèi)出現(xiàn)；2）響應 1 將在進入 S2 狀態(tài) 2S 之內(nèi)出現(xiàn)。5.1.3.4 其他模型 除了上面提及的模型外。 對一些特殊的應用還有一些特別有用的模型。 例如， 編譯程序的說明可以使用屬性文法，工資單系統(tǒng)可以使用表格。要注意的是，對 SRS使用形式需求語言，通常含有使用特殊模型的意思。5.1.3.5 警告無論使用哪一類型的模型，都要在SRS中或在 SRS涉及到的一個文件中對它嚴格定義。這個定義應該規(guī)定：1）模型中的參數(shù)所要求的范圍；2）使用時的限定值；3）結(jié)果的精確度；4）負載的能力；5

47、）要求的執(zhí)行時間；6）缺省或失敗時的響應。 必須注意，在需求的定義域內(nèi)要保持一個模型定義。每當一個SRS使用一個模型時：1）它意味著此模型提供一個十分有效和精確的方法說明需求； 2）并不意味著軟件產(chǎn)品的實現(xiàn)必須基于這個模型。一個模型用于解釋文件所寫的需求是有效的，但是對于實際軟件的實現(xiàn)可能 并不是最適宜的。5.2 軟件需求的注釋有關(guān)軟件產(chǎn)品的所有需求，并不是同等重要的。某些需求可能是基本的，例如是對于生命攸關(guān)的應用。而另一些可能并不那么重要。SRS中每一個需求必須進行注釋，以便區(qū)別其重要的程度。有這種方法注釋需求，可以：1) 幫助客戶對每個需求給予更周密的考慮，通常可以在需求中澄清隱藏的假設；

48、2) 幫助開發(fā)者做出正確的設計決定，并對軟件產(chǎn)品不同部分作出相應的努力。5.2.1 穩(wěn)定性注釋需求的一種方法是使用穩(wěn)定性量綱。當一個需求在軟件預期的生存期間 內(nèi)描述不改變的話，可以認為該需求是穩(wěn)定的，否則可以認為是易變的。5.2.2 必要性等級注釋的另一種方法是把需求分成必須保證級、期望級和任選級。5) 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受；6) 期望是指這些需求將提高軟件產(chǎn)品的功能，但如果缺省的話也是可接受；7) 任選是給開發(fā)者一個機會，可以提供某些超出SRS規(guī)定的目標。5.2.3 注意事項在注釋需求之前，必須徹底理解這種注釋的實質(zhì)性含義。5.3 在表達需求時遇到的共

49、同弊病 SRS的基本點是它必須說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果的手段。編寫 需求的人必須描述的基本問題是：1) 功能所設計的軟件要做什么；2) 性能是指軟件功能在執(zhí)行過程中的速度、可使用性、 響應時間、 各種軟件功能的恢復時間、吞吐能力、精度、頻率等等；3) 強加于實現(xiàn)的設計限制在效果、實現(xiàn)的語言、數(shù)據(jù)庫完整性、資源限制、 操作環(huán)境等等方面所要求的標準；4) 屬性可移植性、正確性、可維護性及安全性等方面的考慮因素；5) 外部接口與人、硬件、其他軟件和其他硬件的相互關(guān)系。編寫需求的人應當避免把設計或項目需求寫入 SRS 之中，應當對說明需求設計約束 與規(guī)劃設計兩者有清晰的區(qū)別。5.3.1

50、 在 SRS中嵌入了設計在 SRS 中嵌入設計說明，會過多地約束軟件設計，并且人為地把具有潛在危 險的需求放入 SRS中。1) SRS必須描述在干什么數(shù)據(jù)上、為誰完成什么功能、在什么地方、產(chǎn)生什 么結(jié)果。 SRS應把注意力集中在要完成的服務目標上。通常不指定如下的 設計項目：把軟件劃分成若干模塊；給每一個模塊分配功能； 描述模塊間的信息流程或者控制流程； 選擇數(shù)據(jù)結(jié)構(gòu)。2) 把設計完全同 SRS隔離開來始終是不現(xiàn)實的。 安全和保密方面的周密考慮 可能增加一些直接反映設計約束的需求。例如： 在一些分散的模塊中保持某些功能； 允許在程序的某些區(qū)域之間進行有限的通訊； 計算臨界值的檢查和。3) 通常

51、應考慮到， 若要為軟件選擇高層次的設計， 就可能需要大量的資源 (可 能占整個產(chǎn)品開發(fā)成本的 10%-20%以上)。有兩種選擇： 不顧本指南的警告，在 SRS中描述了設計。這意味著，或者將一個潛 在不適當?shù)脑O計作為一個需求進行描述(因為，若要得到好的設計，所花費的時間是不夠的） ，或者在需求階段花費了過多的時間 （因為在SRS完成之前整個設計分析都要完成） ；采用本指南中 5.1.3 條中的建議，用模型設計描述需求，這種模型設 計只用于輔助描述需求，而不使之成為實際的設計。5.3.2 在 SRS中嵌入了一些項目要求 SRS應當是描寫一個軟件產(chǎn)品，而不是描述生產(chǎn)軟件產(chǎn)品的過程。 項目要求表達客戶

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

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

54、需要的話，還要說明軟件產(chǎn)品不干什么；4）描述所說明的軟件的應用。應當： 盡可能精確地描述所有相關(guān)的利閃、目的、以及最終目標。 如果有一個較高層次的說明存在，則應該使其和高層次說明中的類似 的陳述相一致（例如，系統(tǒng)的需求規(guī)格說明） 。6.1.3 定義、縮寫詞、略語（ SRS的 1.3 條）本條中必須提供全部需求的術(shù)語、縮寫詞及略語的定義，以便對SRS進行適當?shù)慕忉尅＿@些信息可以由 SRS的附錄提供。也可以參考其他的文件。6.1.4 參考資料（ SRS的 1.4 條）本條應包括：1）在 SRS中各處參照的文件的全部清單，如經(jīng)核準的計劃任務書，上級機關(guān) 批文、合同等；2）列出其他參考資料，如屬本項目

55、的其他已發(fā)表的文件和主要文獻等。每一 個文件、文獻要有標題， 索引號或文件號， 發(fā)布或發(fā)表日期以及出版單位；3）詳細說明可以得到該參考文件的來源。 這個信息可以通過引用附錄或其他 文件提供。6.2 項目概述（ SRS第 2 章） 本章應描述影響產(chǎn)品和其需求的一般因素，本章不說明具體的需求，而僅使需求更 易于理解。6.2.1 產(chǎn)品描述（ SRS的 2.1 條）這一條是把一個產(chǎn)品用其他有關(guān)的產(chǎn)品或項目來描述。1） 如果這個產(chǎn)品是獨立的，而且全部內(nèi)容自含，應在此說明；2） 如果 SRS定義的產(chǎn)品是一個較大的系統(tǒng)或項目中的一個組成部分，那么本條應包括如下內(nèi)容：要概述這個較大的系統(tǒng)或項目的每個組成部分的功能， 并說明其接口； 指出該軟件產(chǎn)品主要的外部接口。 在這里，不要求對接口詳細地描述， 詳細描述放在 SRS其他章條中； 描述所使用的計算機硬件、外圍設備。這里僅僅是一個綜述性描述。在本條的描述中，用一個方框圖來表達一個較大的系統(tǒng)或項目的主要組成部 分、相互聯(lián)系和外部接口是非常有幫助的。本條既不用來強迫進行設計方案的描述，也不是描述在解決問題時的設計約 束。本條應對在以后具體需求一章中說明的設計約束提供理由。6.2.2 產(chǎn)品功能（ SRS的 2.2 條）本條是為將要完成的軟件功能提供一個摘要。 例如，