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

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

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

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

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

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

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

7、滿意。如果你無法找到一個(gè)客戶 的姓名，那么也許你就不應(yīng)該構(gòu)建該產(chǎn)品。 2.2 顧客是將花錢購買該產(chǎn)品的人也給出姓名和相關(guān)的信息 2.3 其它風(fēng)險(xiǎn)承擔(dān)者其他的一些人或組織的名稱，他們或者受到產(chǎn)品的影響，或影響產(chǎn)品。1) 經(jīng)理或項(xiàng)目負(fù)責(zé)人；2) 業(yè)務(wù)領(lǐng)域?qū)＜遥?) 技術(shù)人員；4) 系統(tǒng)開發(fā)者；5) 市場人員；6) 產(chǎn)品經(jīng)理；7) 測試和質(zhì)量保證人員；8) 審查員，諸如安全審查員或?qū)徲?jì)人員；9) 律師；10) 易用性專家；11) 你所處行業(yè)的專業(yè)人員。3. 產(chǎn)品的用戶3.1 產(chǎn)品的用戶產(chǎn)品的潛在用戶或操作員的列表。針對每種類型的用戶，提供以下信息：1) 用戶分類2) 用戶工作的任務(wù)；3) 主要相關(guān)的

8、經(jīng)驗(yàn)；4) 技術(shù)經(jīng)驗(yàn)；5) 其他用戶特征：包括身體、智力、工作態(tài)度、對技術(shù)的態(tài)度、教育程度、語言 技能、年齡、性別等。用戶是為了完成工作而與產(chǎn)品交互的人，你了解用戶，就越可能提交適合用 戶工作方式的產(chǎn)品。 3.2 對用戶設(shè)的優(yōu)先級(jí) 在每類用戶后面附上一個(gè)優(yōu)先級(jí)，這區(qū)別了用戶的重要性和優(yōu)先地位：1) 關(guān)鍵用戶：對產(chǎn)品的后續(xù)成功至關(guān)重要；2) 次要用戶：他們使用產(chǎn)品，但對產(chǎn)品的長期成功并無影響；3) 不重要的用戶：不常用、未授權(quán)和沒有技能的用戶。 如果認(rèn)為某些用戶對產(chǎn)品或組織更重要，那么應(yīng)該寫明，因?yàn)樗鼤?huì)影響你設(shè) 計(jì)產(chǎn)品的方式。 4. 需求限制條件4.1 解決方案限制條件 此處明確了限制條件， 它

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

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

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

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

13、之間無故障運(yùn)行時(shí)間， 或允許的總失敗率。 12.5 容量需求 本節(jié)明確處理的吞吐量和產(chǎn)品存儲(chǔ)數(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è)備的規(guī)范。13.3 伙伴應(yīng)用程序?qū)Ξa(chǎn)品必須與之交互的其它應(yīng)用程序的描述。14. 可維護(hù)性和可移植性需求14.1 維護(hù)該產(chǎn)品需要多容易 對產(chǎn)品作特定修改所需時(shí)間的量化描述。14.2 是否存在一些特殊情況適用于該產(chǎn)品的維護(hù) 關(guān)于預(yù)期的產(chǎn)品發(fā)布周期和發(fā)布將采取的形式的規(guī)定。14.3 可移植性需求 對產(chǎn)品必須支持的其他平臺(tái)或環(huán)境的描述。15

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

15、 明確該產(chǎn)品的法律需求的描述。 17.2 是否有一些必須符合的標(biāo)準(zhǔn) 明確適用的標(biāo)準(zhǔn)和參考的詳細(xì)標(biāo)準(zhǔn)的描述。18.Opend 問題 對未確定但可能對產(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 是否有一些我們可以復(fù)制的東西 其他相似產(chǎn)品的清單。 20. 新問題20.1 新產(chǎn)品會(huì)在當(dāng)前環(huán)境中帶

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

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

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

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

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

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

22、功能、用戶特征、約束、假設(shè)與依賴關(guān)系、需求 子集等方面的內(nèi)容。 2.1 用例模型在本小節(jié)中， 將列出該軟件需求的用例模型， 該模型處于系統(tǒng)級(jí)， 對系統(tǒng)的特性進(jìn) 行宏觀的描述。在此應(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)該詳細(xì)列出所有的軟件需 求，其詳細(xì)程序應(yīng)使設(shè)計(jì)人員能夠充分理解并且進(jìn)行設(shè)計(jì)的要求， 同時(shí)

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

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

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

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

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

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

29、關(guān)軟件的合同都不能作為 SRS。因?yàn)檫@種文件幾乎不 包括詳盡的需求說明，并且通常不完全的） ；5）便于移植。有了 SRS 就便于移值軟件產(chǎn)品，以適應(yīng)新的用戶或新的機(jī)種?？?戶也易于移植其軟件到其他部門， 而開發(fā)者同樣也易于把軟件移植到新的客戶；6）作為不斷提高的基礎(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

30、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 )：指個(gè)人或單位，他們?yōu)楫a(chǎn)品開發(fā)提供資金，通常(但有時(shí)也不必) 還提出各種需求。文件中的客戶和開發(fā)者也可能是同一個(gè)組織的成員。語言( language )：是具有語法和語義的通信工具，包括一組表達(dá)式、慣例和傳遞信息 的有關(guān)規(guī)則。分割( partitioning )：把一個(gè)整

31、體分成若干部分。開發(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是對要完成一定功能、 性能的軟件產(chǎn)品、 程序或一組程序的說明。 對 SRS的描 述有兩項(xiàng)基本要求：1) 必須描述一定的功能、性能；2) 必須用確定的方法敘述這些功能、性能。4.2 SRS 的環(huán)境必須認(rèn)識(shí)到 SRS 在整個(gè)軟件開發(fā)規(guī)范(見 GB 8566)所規(guī)定的有關(guān)階段都起作用。 正因?yàn)槿绱耍?SRS

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

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

34、? 描述必須干什么事，以刪除這個(gè)“待定” ；2) 包含有“待定”一詞的任何 SRS的項(xiàng)目文件應(yīng)該：? 標(biāo)識(shí)與此特定文件有關(guān)的版本號(hào)或敘述其專門的發(fā)布號(hào)；? 拒絕任何仍標(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)的、完整性的

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

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

37、件所支持的確切的法律或行政文件。當(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ù)階段的需要，包括軟件最終替換。1) 維護(hù)常常是由與原來開發(fā)無聯(lián)系的人來進(jìn)行的。局部的改變(修正)可以 借助于好的代碼注釋來實(shí)現(xiàn)。對于較大范圍的改變。設(shè)計(jì)和需求文件是必 不可少的，這里隱含了兩個(gè)作用：? 如 4.3.5 條指出， SRS必須是可修改的；? SRS 中必須包括一個(gè)記錄，它記錄那些應(yīng)用于各個(gè)成分的所有具體條 文。例如：它們的危急性(如故障可能危及完全或?qū)е?/p>

38、大量財(cái)政方面 和社會(huì)方面的損失) ；它們僅與暫時(shí)的需要相關(guān) (如支持一種可立即恢 復(fù)原狀的顯示) ；它們的來源 (如某功能是由已存在的軟件產(chǎn)品的全部 拷貝復(fù)制而成) 。2) 要求在 SRS中清楚地寫明功能的來源和目的， 因?yàn)閷δ艿膩碓春鸵朐?功能的目的不清楚的話，通常不可能很好地完成軟件的維護(hù)。4.4 SRS 的編制者 軟件開發(fā)的過程是由開發(fā)者和客戶雙方同意開發(fā)什么樣的軟件協(xié)議開始的。 這種協(xié) 議要使用 SRS 的形式，應(yīng)該由雙方聯(lián)合起草。這是因?yàn)椋?) 客戶通常對軟件設(shè)計(jì)和開發(fā)過程了解較少，而不能寫出可用的SRS；2) 開發(fā)者通常對于客戶的問題和意圖了解較少，從而不可能寫出一個(gè)令人滿意的

39、 系統(tǒng)需求。4.5 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)：1) 盡管可以預(yù)見校正版本的開發(fā)以后不可避免，而對需求還必須盡可能完全、清 楚地描述。2) 一旦最初識(shí)別出項(xiàng)目的變化，應(yīng)引入一個(gè)正式的改變規(guī)程來標(biāo)識(shí)、控制、追蹤 和報(bào)告項(xiàng)目的改變。批準(zhǔn)了的需求改變，用如下的方法編入 SRS 之中： ? 提供各種改變后的正確的、完全的審查記錄；? 允許對 SRS當(dāng)前的和被替代部分的審查。4.6 SRS 的編制工具編制 SRS 最顯而易見的

40、方法是用自然語言來描述。 盡管自然語言是豐富多彩的， 但 不易精確，用形式化的方法較好。4.6.1 形式化說明方法在 SRS中是否使用形式化方法要依據(jù)下列因素：1) 程序規(guī)模和復(fù)雜性；2) 客戶合同中是否要求使用；3) SRS 是否是一個(gè)合同工具或僅僅是一個(gè)內(nèi)部文件；4) SRS 文件是否成為設(shè)計(jì)文件的根據(jù)；5) 具有支持這種方法的計(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 中有許多詞匯，特別是

41、許多名詞和動(dòng)詞，專門涉及到系統(tǒng)的實(shí)體和許 多活動(dòng)，所以表達(dá) SRS 需要若干工具。比如：1) 可以驗(yàn)證實(shí)體或活動(dòng)，無論在 SRS中什么地方都是同一名字。2）可以標(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

42、.1 表達(dá)軟件需求的方法 軟件需求可以用若干種方法來表達(dá)：1）通過輸入、輸出說明；2）使用代表性的例子；3）用規(guī)范化的模型。5.1.1 輸入、輸出說明 用輸入輸出序列來描述一個(gè)軟件產(chǎn)品所要求的特性是很有效的。5.1.1.1 途徑 根據(jù)被描述的軟件的性質(zhì)，至少有三種不同的途徑：1） 有些軟件產(chǎn)品（如報(bào)表系統(tǒng)）要求著重說明輸出。一般情況下，致力于輸 出的系統(tǒng)主要是在數(shù)據(jù)文卷上操作。 用戶的輸入通常是致力于提供控制信 息和啟動(dòng)數(shù)據(jù)文卷的處理；2） 有些軟件產(chǎn)品需要著重說明輸入、輸出特性。關(guān)注輸入、輸出的系統(tǒng)主要 是在當(dāng)前的輸入上操作，要求生成與輸入相匹配的輸出（類似于數(shù)據(jù)轉(zhuǎn)換 例行程序或一個(gè)數(shù)學(xué)函數(shù)

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

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

45、 中所討論的典型例子描述如下： （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)行的 操作。對前面用數(shù)學(xué)模型描述的例子。可用圖 1 所示的有限狀態(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í)間限制的模型。這種模型對于表達(dá)軟件特性的形式 和細(xì)節(jié)特別有用。尤其是

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

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

48、隱藏的假設(shè)；2) 幫助開發(fā)者做出正確的設(shè)計(jì)決定，并對軟件產(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í)。5) 必須保證是指軟件必須和這些需求相一致，否則該軟件不可能被接受；6) 期望是指這些需求將提高軟件產(chǎn)品的功能，但如果缺省的話也是可接受；7) 任選是給開發(fā)者一個(gè)機(jī)會(huì)，可以提供某些超出SRS規(guī)定的目標(biāo)。5.2.3 注意事項(xiàng) 在注釋需求之前，必須徹底理解這種注釋的實(shí)質(zhì)性含義。5.3 在

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

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

51、的通訊； ? 計(jì)算臨界值的檢查和。3) 通常應(yīng)考慮到， 若要為軟件選擇高層次的設(shè)計(jì)， 就可能需要大量的資源 (可 能占整個(gè)產(chǎn)品開發(fā)成本的 10%-20%以上)。有兩種選擇： ? 不顧本指南的警告，在 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ì)分析都要完成） ；? 采用本指南中 5.1.3 條中的建議，用模型設(shè)計(jì)描述需求，這種模型設(shè) 計(jì)只用于輔助描述需求，而不使之成為實(shí)際的設(shè)計(jì)。5.3.2 在 SRS中嵌入了一些項(xiàng)目要求 SRS應(yīng)當(dāng)是描寫一個(gè)軟件產(chǎn)

52、品，而不是描述生產(chǎn)軟件產(chǎn)品的過程。 項(xiàng)目要求表達(dá)客戶和開發(fā)者之間對于軟件生產(chǎn)方面合同性事宜的理解（因此 不應(yīng)當(dāng)包括在 SRS中）例如：1）成本；2）交貨進(jìn)度；3）報(bào)表處理；4）軟件開發(fā)方法；5 ） 質(zhì)量保證；6）確認(rèn)和驗(yàn)證的標(biāo)準(zhǔn)；7）驗(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定

53、義、縮寫詞、略語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)容：1）描述實(shí)際 SRS的目的；2）說明 SRS所預(yù)期的讀者。6.1.2 范圍（ SRS的 1.2 條）1）通常應(yīng)考慮到， 若要為軟件選擇高層次的設(shè)計(jì)， 就可能需要大量的資源 （可 能占整個(gè)產(chǎn)品開發(fā)成本的 10%-20%以上）。有兩種選擇：2）用一個(gè)名字標(biāo)識(shí)被生產(chǎn)的軟件產(chǎn)品。比如：×

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

55、文件的全部清單，如經(jīng)核準(zhǔn)的計(jì)劃任務(wù)書，上級(jí)機(jī)關(guān) 批文、合同等；2）列出其他參考資料，如屬本項(xiàng)目的其他已發(fā)表的文件和主要文獻(xiàn)等。每一 個(gè)文件、文獻(xiàn)要有標(biāo)題， 索引號(hào)或文件號(hào)， 發(fā)布或發(fā)表日期以及出版單位；3）詳細(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)目來描述。1） 如果這個(gè)產(chǎn)品是獨(dú)立的，而且全部內(nèi)容自含，應(yīng)在此說明；2） 如果 SRS定義的產(chǎn)品是一個(gè)較大的系統(tǒng)或項(xiàng)目中的一個(gè)組成部分，那么本條應(yīng)包括如下內(nèi)容：? 要概述這個(gè)較大的系統(tǒng)或項(xiàng)目的每個(gè)組成部分的功能， 并說明其接口； ? 指出該軟件產(chǎn)品主要的外部接口。 在這里，不要求對接口詳細(xì)地描述， 詳細(xì)描述放在 SRS其他章條中；? 描述所使用的計(jì)算機(jī)硬件、外圍設(shè)備。這里僅僅是一個(gè)綜述性描述。 在本條的描述中，用一個(gè)方框圖來表達(dá)一個(gè)較大的系統(tǒng)或項(xiàng)目的主要組成部 分、相互聯(lián)系和外部接口是非常有幫助的。本條既不用來強(qiáng)迫進(jìn)行設(shè)計(jì)方案的描述，也不是描述在解決問題時(shí)的設(shè)計(jì)約 束。本條應(yīng)對在以后具體需求一章中說明的設(shè)計(jì)約束提供理由。6.2.2 產(chǎn)品功能（ SRS的 2.2 條