1、1Software Requirements Engineering軟件需求工程 鄭州大學(xué)軟件學(xué)院 軟件工程專業(yè)必修課程授課對(duì)象:本科3年級(jí)授課教師:徐強(qiáng)22 Requirements Specification需求規(guī)格說(shuō)明 33軟件需求規(guī)格說(shuō)明編寫需求文檔的原則需求示例改進(jìn)前后質(zhì)量屬性軟件需求規(guī)格說(shuō)明模板本章內(nèi)容44SRS Document軟件需求規(guī)格說(shuō)明55可以用三種方法編寫軟件需求規(guī)格說(shuō)明：用好的結(jié)構(gòu)化的自然語(yǔ)言編寫文本型文檔。建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過(guò)程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退鼈兊年P(guān)系。編寫形式化規(guī)格說(shuō)明，這可以通過(guò)使用數(shù)學(xué)上精確的形式化邏輯

2、語(yǔ)言來(lái)定義需求。編寫軟件需求規(guī)格說(shuō)明66雖然結(jié)構(gòu)化的自然語(yǔ)言具有許多缺點(diǎn)，但在大多數(shù)軟件工程中，它仍是編寫需求文檔最現(xiàn)實(shí)的方法。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說(shuō)明已經(jīng)為大多數(shù)項(xiàng)目所接受。圖形化分析模型通過(guò)提供另一種需求視圖，增強(qiáng)了軟件需求規(guī)格說(shuō)明。由于形式化規(guī)格說(shuō)明具有很強(qiáng)的嚴(yán)密性和精確度，因此，所使用的形式化語(yǔ)言只有極少數(shù)軟件開發(fā)人員才熟悉，更不用說(shuō)客戶了。編寫軟件需求規(guī)格說(shuō)明77關(guān)于SRS軟件需求規(guī)格說(shuō)明，也稱為功能規(guī)格說(shuō)明、需求協(xié)議以及系統(tǒng)規(guī)格說(shuō)明。它精確地闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件。軟件需求規(guī)格說(shuō)明不僅是系統(tǒng)測(cè)試和用戶文檔的基礎(chǔ)，也是所

3、有子系列項(xiàng)目規(guī)劃、設(shè)計(jì)和編碼的基礎(chǔ)。它應(yīng)該盡可能完整地描述系統(tǒng)預(yù)期的外部行為和用戶可視化行為。除了設(shè)計(jì)和實(shí)現(xiàn)上的限制，軟件需求規(guī)格說(shuō)明不應(yīng)該包括設(shè)計(jì)、構(gòu)造、測(cè)試或工程管理的細(xì)節(jié)。88關(guān)于SRS軟件需求規(guī)格說(shuō)明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開發(fā)者和客戶不能作任何假設(shè)。如果任何所期望的功能或非功能需求未寫入軟件需求規(guī)格說(shuō)明，那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。毫無(wú)疑問(wèn)，必須在開始設(shè)計(jì)和構(gòu)造之前編寫出整個(gè)產(chǎn)品的軟件需求規(guī)格說(shuō)明。可以反復(fù)地或以漸增方式編寫需求規(guī)格說(shuō)明。99SRS的閱讀者不同人員使用軟件需求規(guī)格說(shuō)明來(lái)達(dá)到不同的目的：客戶和營(yíng)銷部門依賴它來(lái)了解他

4、們所能提供的產(chǎn)品。項(xiàng)目經(jīng)理根據(jù)包含在軟件需求規(guī)格說(shuō)明中描述的產(chǎn)品來(lái)制定規(guī)劃并預(yù)測(cè)進(jìn)度安排、工作量和資源。軟件開發(fā)小組依賴它來(lái)理解他們將要開發(fā)的產(chǎn)品。測(cè)試小組使用軟件需求規(guī)格說(shuō)明中對(duì)產(chǎn)品行為的描述制定測(cè)試計(jì)劃、測(cè)試用例和試過(guò)程。軟件維護(hù)和支持人員根據(jù)SRS了解產(chǎn)品的某部分是做什么的。產(chǎn)品發(fā)布組在SRS和用戶界面設(shè)計(jì)的基礎(chǔ)上編寫客戶文檔，如用戶手冊(cè)和幫助屏幕等。培訓(xùn)人員根據(jù)SRS和用戶文檔編寫培訓(xùn)材料。1010SRS的可讀性可讀性的建議：對(duì)節(jié)、小節(jié)和單個(gè)需求的號(hào)碼編排必須一致。右邊部分留下文本注釋區(qū)。允許不加限制地使用空格。正確使用各種可視化強(qiáng)調(diào)標(biāo)志（例如，黑體、下劃線、斜體和其它不同字體）。創(chuàng)建

5、目錄表和索引表有助于讀者尋找所需的信息。對(duì)所有圖和表指定號(hào)碼和標(biāo)識(shí)號(hào)，并且可按號(hào)碼進(jìn)行查閱。使用字處理程序中交叉引用的功能來(lái)查閱文檔中其它項(xiàng)或位置，而不是通過(guò)頁(yè)碼或節(jié)號(hào)。1111標(biāo)識(shí)需求為了滿足軟件需求規(guī)格說(shuō)明的可跟蹤性和可修改性的質(zhì)量標(biāo)準(zhǔn)，必須唯一確定每個(gè)軟件需求。這可以在變更請(qǐng)求、修改歷史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達(dá)到這一目的，用單一的項(xiàng)目列表是不夠的，因此，描述幾個(gè)不同的需求標(biāo)識(shí)方法，并闡明它們的優(yōu)點(diǎn)與缺點(diǎn)。可以根據(jù)情況選擇最適合的方法。1212Identifying requirements 標(biāo)識(shí)需求1) 序列號(hào) 最簡(jiǎn)單的方法是賦予每個(gè)需求一個(gè)唯一的序列號(hào)

6、，例如UR-2或SRS13。當(dāng)一個(gè)新的需求加入到商業(yè)需求管理工具的數(shù)據(jù)庫(kù)之后，這些管理工具就會(huì)為其分配一個(gè)序列號(hào)（許多這樣的工具也支持層次化編號(hào)）。序列號(hào)的前綴代表了需求類型，例如UR代表“用戶需求”。由于序列號(hào)不能重用，所以把需求從數(shù)據(jù)庫(kù)中刪除時(shí)，并不釋放其所占據(jù)的序列號(hào)，而新的需求只能得到下一個(gè)可用的序列號(hào)。這種簡(jiǎn)單的編號(hào)方法并不能提供任何相關(guān)需求在邏輯上或?qū)哟紊系膮^(qū)別，而且需求的標(biāo)識(shí)不能提供任何有關(guān)每個(gè)需求內(nèi)容的信息。1313Identifying requirements 標(biāo)識(shí)需求2) 層次化編碼 這也許是最常用的方法。如果功能需求出現(xiàn)在軟件需求規(guī)格說(shuō)明中第3.2部分，那么它們將具有諸

7、如這樣的標(biāo)識(shí)號(hào)。標(biāo)識(shí)號(hào)中的數(shù)字越多則表示該需求越詳細(xì)，屬于較低層次上的需求。這種方法簡(jiǎn)單且緊湊，（字處理程序可能可以自動(dòng)編排序號(hào)）。然而，即使在一個(gè)中型的軟件需求規(guī)格說(shuō)明中，這些標(biāo)識(shí)號(hào)也會(huì)擴(kuò)展到許多位數(shù)字，并且這些標(biāo)識(shí)也不提供任何有關(guān)每個(gè)需求目的的信息。如果要插入一個(gè)新的需求，那么該需求所在部分其后所有需求的序號(hào)將要增加。刪除或移去一個(gè)需求，那么該需求所在部分其后所有需求的序號(hào)將要減少。這些變化將破壞系統(tǒng)其它地方需求的引用。1414Identifying requirements 標(biāo)識(shí)需求2) 層次化編碼 （contd.）對(duì)于這種簡(jiǎn)單的層次化編號(hào)的一種改進(jìn)方法是對(duì)需求中主要的部分進(jìn)行層次化編號(hào)

8、，然后對(duì)于每個(gè)部分中的單一功能需求用一個(gè)簡(jiǎn)短文字代碼加上一個(gè)序列號(hào)來(lái)識(shí)別。例如，軟件需求規(guī)格說(shuō)明可能包含“第3.2.5部分編輯功能”，那么這一部分需求的編號(hào)可以寫成ED-1、ED-2等等。這種方法具有層次性和組織性，同時(shí)使標(biāo)識(shí)號(hào)簡(jiǎn)短和具有一定意義并與位置無(wú)關(guān)等特點(diǎn)。如果要在ED-1和ED-2之間插入新的需求ED-9，則不必對(duì)該部分中余下的需求重新編號(hào)。1515Identifying requirements 標(biāo)識(shí)需求 3) 層次化文本標(biāo)簽基于文本的層次化標(biāo)簽方案來(lái)標(biāo)識(shí)單個(gè)需求（Gilb 1988）。考慮這樣一個(gè)需求：“當(dāng)用戶請(qǐng)求打印超過(guò)10個(gè)副本時(shí)，系統(tǒng)必須讓用戶進(jìn)行確認(rèn)判斷。”這一需求可能被

9、標(biāo)識(shí)為“打印.副本.確認(rèn)”，這意味著這個(gè)需求是打印功能的一部分，并且與要打印的副本數(shù)量的設(shè)置問(wèn)題有關(guān)。層次化文本標(biāo)簽是結(jié)構(gòu)化的，具有語(yǔ)義上的含義，并且不受增加、刪除或移動(dòng)其它需求的影響。它們的主要缺點(diǎn)是文本標(biāo)簽比層次化數(shù)字標(biāo)識(shí)碼復(fù)雜。1616處理不完整性有時(shí)會(huì)缺少特定需求的某些信息。在解決這個(gè)不確定性之前，可能必須與客戶商議、檢查與另一個(gè)系統(tǒng)的接口或者定義另一個(gè)需求。使用“待確定”（to be determined, TBD）符號(hào)作為標(biāo)準(zhǔn)指示器來(lái)強(qiáng)調(diào)軟件需求規(guī)格說(shuō)明中這些需求的缺陷（gap）。通過(guò)這種方法，可以在軟件需求規(guī)格說(shuō)明中查找所要澄清需求的部分。記錄誰(shuí)將解決哪個(gè)問(wèn)題、怎樣解決及什么時(shí)候

10、解決。把每個(gè)TBD編號(hào)并創(chuàng)建一個(gè)TBD列表，這有助于方便地跟蹤每個(gè)項(xiàng)目。在繼續(xù)進(jìn)行構(gòu)造需求集合之前，必須解決所有的TBD問(wèn)題，因?yàn)槿魏芜z留下來(lái)的不確定問(wèn)題將會(huì)增加出錯(cuò)的風(fēng)險(xiǎn)和需求返工。當(dāng)開發(fā)人員遇到一個(gè)TBD問(wèn)題或其它模糊之處時(shí)，他可能不會(huì)返回到原始需求來(lái)解決問(wèn)題。多半開發(fā)者對(duì)它進(jìn)行猜測(cè)，但并不總是正確的。如果有TBD問(wèn)題尚未解決，而又要繼續(xù)進(jìn)行開發(fā)工作，那么盡可能推遲實(shí)現(xiàn)這些需求，或者解決這些需求的開放式問(wèn)題，把產(chǎn)品的這部分設(shè)計(jì)得易于更改。1717關(guān)于用戶界面把用戶界面的設(shè)計(jì)編入軟件需求規(guī)格說(shuō)明既有好處也有壞處。Disadvantage 消極方面，屏幕映像和用戶界面機(jī)制是解決方案（設(shè)計(jì)）的描

11、述，而不是需求。如果在完成了用戶界面的設(shè)計(jì)之后才能確定軟件需求規(guī)格說(shuō)明，那么需求開發(fā)的過(guò)程將會(huì)花費(fèi)很長(zhǎng)的時(shí)間。這將會(huì)使那些只關(guān)心需求開發(fā)時(shí)間的經(jīng)理、客戶或開發(fā)人員失去耐心。用戶界面的布局不能替代定義功能需求。不要指望開發(fā)人員可以從屏幕中推斷出潛在的功能和數(shù)據(jù)關(guān)系。把用戶界面的設(shè)計(jì)加入軟件需求規(guī)格說(shuō)明還意味著開發(fā)人員在更改一個(gè)用戶界面的元素時(shí)必須相應(yīng)更改需求的過(guò)程。1818關(guān)于用戶界面Advantage 積極方面，探索潛在的用戶界面有助于精化需求并使 用戶系統(tǒng) 的交互對(duì)用戶和開發(fā)人員更具有實(shí)在性。用戶界面的演示也有助于項(xiàng)目計(jì)劃的制定和預(yù)測(cè)。根據(jù)以往類似開發(fā)活動(dòng)的經(jīng)驗(yàn)，可以數(shù)清圖形用戶界面（GUI

12、）的元素?cái)?shù)目或者計(jì)算與每個(gè)屏幕有關(guān)的功能點(diǎn)數(shù)目，然后估計(jì)實(shí)現(xiàn)這些屏幕功能所需的工作量。1919權(quán)衡點(diǎn)一個(gè)合理的權(quán)衡點(diǎn)是：在軟件需求規(guī)格說(shuō)明中加入所選擇的用戶界面組件的概念映像草圖，而在實(shí)現(xiàn)時(shí)并不一定要精確地遵循這些方法。通過(guò)使用另一種方式來(lái)表示需求，從而增強(qiáng)相互交流的能力，但并不增加對(duì)開發(fā)人員的限制，也不增加變更管理過(guò)程的負(fù)擔(dān)。例如，一個(gè)復(fù)雜對(duì)話框的最初草案將描述支持需求部分的意圖，但是一個(gè)有經(jīng)驗(yàn)的設(shè)計(jì)者可以把它轉(zhuǎn)化為一個(gè)帶有標(biāo)簽組件的對(duì)話框或使用其它方法以提高其可用性。2020需求文檔模板 每個(gè)軟件開發(fā)組織都應(yīng)該在它們的項(xiàng)目中采用一種標(biāo)準(zhǔn)的軟件需求規(guī)格說(shuō)明的模板。許多人使用來(lái)自IEEE標(biāo)準(zhǔn)8

13、30-1998的模板，“IEEE推薦的軟件需求規(guī)格說(shuō)明的方法” （IEEE 1998） 。GB8567-88模板GBT9385-2008計(jì)算機(jī)軟件需求規(guī)格說(shuō)明規(guī)范2121軟件需求規(guī)格說(shuō)明編寫需求文檔的原則需求示例改進(jìn)前后質(zhì)量屬性軟件需求規(guī)格說(shuō)明模板本章內(nèi)容2222Principle of SRS編寫需求文檔的原則2323需求文檔的原則編寫優(yōu)秀的需求文檔沒(méi)有現(xiàn)成固定的方法，最好是根據(jù)經(jīng)驗(yàn)進(jìn)行。從過(guò)去所遇到的問(wèn)題中可使你受益匪淺。在編寫軟件需求文檔時(shí)，應(yīng)牢記以下幾點(diǎn)建議：保持語(yǔ)句和段落的簡(jiǎn)短。采用主動(dòng)語(yǔ)態(tài)的表達(dá)方式。編寫具有正確的語(yǔ)法、拼寫和標(biāo)點(diǎn)的完整句子。使用的術(shù)語(yǔ)與詞匯表中所定義的應(yīng)該一致。2

14、424需求文檔的原則需求陳述應(yīng)該具有一致的樣式，例如“系統(tǒng)必須”或者“用戶必須”，并緊跟一個(gè)行為動(dòng)作和可觀察的結(jié)果。例如，“倉(cāng)庫(kù)管理子系統(tǒng)必須顯示一張所請(qǐng)求的倉(cāng)庫(kù)中有存貨的化學(xué)藥品容器清單。”為了減少不確定性，必須避免模糊的、主觀的術(shù)語(yǔ)，例如，用戶友好、容易、簡(jiǎn)單、迅速、有效、支持、許多、最新技術(shù)、優(yōu)越的、可接受的和健壯的。當(dāng)用客說(shuō)“用戶友好”或者“快”或者“健壯”時(shí)，你應(yīng)該明確它們的真正含義并且在需求中闡明用戶的意圖。避免使用比較性的詞匯，例如：提高、最大化、最小化和最佳化。定量地說(shuō)明所需要提高的程度或者說(shuō)清一些參數(shù)可接受的最大值和最小值。當(dāng)客戶說(shuō)明系統(tǒng)應(yīng)該“處理”、“支持”或“管理”某些事

15、情時(shí)，你應(yīng)該能理解客戶的意圖。含糊的語(yǔ)句表達(dá)將引起需求的不可驗(yàn)證。2525細(xì)節(jié)由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細(xì)分解，直到消除不明確性為止。編寫詳細(xì)的需求文檔，所帶來(lái)的益處是如果需求得到滿足，那么客戶的目的也就達(dá)到了，但是不要讓過(guò)于詳細(xì)的需求影響了設(shè)計(jì)。2626方針文檔的編寫人員必須以相同的詳細(xì)程度編寫每個(gè)需求文檔。文檔的編寫人員不應(yīng)該把多個(gè)需求集中在一個(gè)冗長(zhǎng)的敘述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個(gè)需求。務(wù)必記住，不要在需求說(shuō)明中使用“和/或”，“等等”之類的連詞。文檔的編寫人員在編寫軟件需求規(guī)格說(shuō)明時(shí)不應(yīng)該出現(xiàn)需求冗余。雖然在不

16、同的地方出現(xiàn)相同的需求可能會(huì)使文檔更易讀，但這也造成了維護(hù)上的困難。需求的多個(gè)實(shí)例都需要同時(shí)更新，以免造成需求各實(shí)例之間的不一致。文檔的編寫人員應(yīng)考慮用最有效的方法表達(dá)每個(gè)需求。2727軟件需求規(guī)格說(shuō)明編寫需求文檔的原則需求示例改進(jìn)前后質(zhì)量屬性軟件需求規(guī)格說(shuō)明模板本章內(nèi)容2828需求示例改進(jìn)前后2929Example 1“產(chǎn)品必須在固定的時(shí)間間隔內(nèi)提供狀態(tài)消息，并且每次時(shí)間間隔不得小于60秒”。這個(gè)需求看起來(lái)是不完整的：什么是狀態(tài)消息，并且在什么情況下向用戶提供這些消息？顯示時(shí)間多長(zhǎng)？我們所說(shuō)的是產(chǎn)品的哪一部分？時(shí)間間隔也會(huì)導(dǎo)致混淆。假定顯示狀態(tài)消息之間的時(shí)間間隔只要求不少于60秒，按這樣推理

17、，是否可以每隔一年顯示一次狀態(tài)信息？如果意圖是消息之間的時(shí)間間隔不多于60秒，那么1毫秒會(huì)不會(huì)太短？消息顯示的時(shí)間間隔怎樣才能一致？“每次”這個(gè)詞混淆了這一問(wèn)題。由于這些問(wèn)題的存在，導(dǎo)致了需求是不可驗(yàn)證的。3030Example 1（contd.）這里提出一個(gè)方法使我們能重寫需求文檔來(lái)表述這些缺點(diǎn)（從我們與客戶一致的目標(biāo)出發(fā)作出一些猜測(cè)）即：后臺(tái)任務(wù)管理器（BTM）應(yīng)該在用戶界面的指定區(qū)域顯示狀態(tài)消息。a. 在后臺(tái)任務(wù)進(jìn)程啟動(dòng)之后，消息必須每隔60(10)秒更新一次，并且保持連續(xù)的可見性。b. 如果正在正常處理后臺(tái)任務(wù)進(jìn)程，那么后臺(tái)任務(wù)管理器（BTM）必須顯示后臺(tái)任務(wù)進(jìn)程已完成的百分比。c.

18、當(dāng)完成后臺(tái)任務(wù)時(shí)，后臺(tái)任務(wù)管理器（BTM）必須顯示一個(gè)“已完成”的消息。d. 如果后臺(tái)任務(wù)中止執(zhí)行，那么后臺(tái)任務(wù)管理器（BTM）必須顯示一個(gè)出錯(cuò)消息。3131Example 1（contd.）把原先的需求分割成多個(gè)需求，因?yàn)槊總€(gè)需求都需要獨(dú)立的測(cè)試用例并且使各個(gè)需求都具有可跟蹤性。如果把多個(gè)需求都集中在一個(gè)段落中，那么在構(gòu)造軟件和測(cè)試時(shí)就很容易忽略其中某個(gè)需求。注意，修改之后的需求并沒(méi)有精確地說(shuō)明是怎樣顯示狀態(tài)信息的。這是一個(gè)設(shè)計(jì)問(wèn)題，如果你在這個(gè)地方詳述該問(wèn)題，那么就會(huì)給開發(fā)人員帶來(lái)設(shè)計(jì)上的一些限制。過(guò)早地限制設(shè)計(jì)上的可選方案將會(huì)給編程人員帶來(lái)不利因素，并可導(dǎo)致產(chǎn)品設(shè)計(jì)的失敗。3232Exa

19、mple 2“產(chǎn)品必須在顯示和隱藏非打印字符之間進(jìn)行瞬間切換”。在瞬間這一時(shí)間概念上，計(jì)算機(jī)不能完成任何工作，因此，這個(gè)需求是不可行的。該需求也是不完整的，因?yàn)樗鼪](méi)有說(shuō)清狀態(tài)切換的原因。在特定的條件下，軟件產(chǎn)品是否可以進(jìn)行自動(dòng)切換或者可否由用戶采取某些措施來(lái)激發(fā)這樣轉(zhuǎn)變？還有，在文檔中顯示轉(zhuǎn)變的范圍是什么？是所選的文本、整個(gè)文檔或其它內(nèi)容？這個(gè)需求也存在一個(gè)不確定性問(wèn)題。“非打印”字符是否指隱藏文本、屬性標(biāo)記或者其它的控制字符？由于存在這些問(wèn)題，該需求是不可驗(yàn)證的。3333Example 2（contd.）用如下的語(yǔ)句描述這個(gè)需求可能會(huì)更好一些：“用戶在編輯文檔時(shí)，通過(guò)激活特定的觸發(fā)機(jī)制，可以

20、在顯示和隱藏所有HTML標(biāo)記之間進(jìn)行切換”。現(xiàn)在，指代關(guān)系就清楚了，非打印字符指的是HTML標(biāo)記。修改過(guò)的需求指明了是用戶觸發(fā)了顯示狀態(tài)的轉(zhuǎn)換，但是它并沒(méi)有對(duì)設(shè)計(jì)造成限制，因?yàn)樗](méi)有精確定義所使用的機(jī)制。當(dāng)設(shè)計(jì)人員選擇好一種觸發(fā)機(jī)制（例如熱鍵、菜單命令或語(yǔ)音輸入）時(shí)，你就可以編寫詳細(xì)的測(cè)試用例來(lái)驗(yàn)證這種轉(zhuǎn)換操作是否正確。3434Example 3“分析程序應(yīng)該能生成HTML標(biāo)記出錯(cuò)的報(bào)告，這樣就可以使HTML的初學(xué)者使用它來(lái)迅速排錯(cuò)。”“迅速”這個(gè)詞具有模糊性。缺乏對(duì)出錯(cuò)報(bào)告內(nèi)容的定義表明該需求是不完整的。是如何驗(yàn)證這個(gè)需求的？找一些HTML的初學(xué)者，看他們利用這個(gè)報(bào)告是否可以迅速排錯(cuò)？還有

21、一點(diǎn)不清楚的是：HTML初學(xué)者使用的是分析程序還是出錯(cuò)報(bào)告。并且何時(shí)生成這樣的報(bào)告？3535Example 3（contd.）讓我們使用另一種方式表述這個(gè)需求：a. 在HTML分析程序完全分析完一個(gè)文件后，該分析程序必須生成一個(gè)出錯(cuò)報(bào)告，這個(gè)報(bào)告中包含了在分析文件過(guò)程中所發(fā)現(xiàn)錯(cuò)誤的HTML所在的行號(hào)以及文本內(nèi)容，還包含了對(duì)每個(gè)錯(cuò)誤的描述。b. 如果在分析過(guò)程中未發(fā)現(xiàn)任何錯(cuò)誤，就不必生成出錯(cuò)報(bào)告。現(xiàn)在我們知道了任何生成出錯(cuò)報(bào)告及其所包含的內(nèi)容，但是我們已經(jīng)把該需求提交給設(shè)計(jì)人員，讓他們來(lái)決定報(bào)告的形式。我們還指明了一種例外情況：如果沒(méi)有任何錯(cuò)誤，就不生成出錯(cuò)報(bào)告。3636Example 4“如果

22、可能的話，應(yīng)當(dāng)根據(jù)主貨物編號(hào)列表在線確認(rèn)所輸入的貨物編號(hào)。”“如果可能的話”這句話意味著什么？該需求是否在技術(shù)上可行？是否可以在線訪問(wèn)主貨物編號(hào)列表？如果你不能確信是否可以遞交一個(gè)請(qǐng)求，那么就使用“待確定” ( TBD )來(lái)表示未解決的問(wèn)題。這個(gè)需求是不完整的，因?yàn)樗](méi)有指明如果確認(rèn)通過(guò)或失敗，將會(huì)發(fā)生什么情況。應(yīng)該盡量避免使用不精確的詞匯，例如“應(yīng)當(dāng)”。客戶可能需要這個(gè)功能或者不需要這個(gè)功能。一些需求規(guī)格說(shuō)明利用關(guān)鍵字之間微妙的差別如“應(yīng)當(dāng)”，“必須”和“可能”來(lái)指明重要性。一些人更喜歡使用“必須”或“將要”來(lái)明確說(shuō)明需求的目的并且明確指定其優(yōu)先級(jí)。3737Example 4（contd.

23、）改進(jìn)后的該需求描述如下：“系統(tǒng)必須根據(jù)在線的主貨物編號(hào)列表確認(rèn)所輸入的貨物編號(hào)。如果在主列表中查不到該貨物的編號(hào)，系統(tǒng)必須顯示一個(gè)出錯(cuò)消息并且拒絕訂貨。”第二種相關(guān)需求可能記錄了一種異常情況：當(dāng)進(jìn)行貨物編號(hào)確認(rèn)時(shí)，主貨物編號(hào)列表不可訪問(wèn)。3838Example 5“產(chǎn)品不應(yīng)該提供將帶來(lái)災(zāi)難性后果的查詢和替換選擇。”“災(zāi)難性后果”的含義是解釋的中心詞。在編輯文檔時(shí)，毫無(wú)目的地作出全局性變化而用戶又不能檢測(cè)出錯(cuò)誤或沒(méi)有任何辦法來(lái)糾正它，此時(shí)就可能帶來(lái)災(zāi)難性后果。也要合理地使用反面需求，因?yàn)檫@些需求描述了系統(tǒng)所不能做的事情。潛在的關(guān)注焦點(diǎn)在于當(dāng)發(fā)生意外損壞時(shí)，能保護(hù)文件的內(nèi)容。也許，真正的需求是針

24、對(duì)多級(jí)撤銷( undo )能力、全局變化或其它可導(dǎo)致數(shù)據(jù)丟失行為確定的。3939軟件需求規(guī)格說(shuō)明編寫需求文檔的原則需求示例改進(jìn)前后質(zhì)量屬性軟件需求規(guī)格說(shuō)明模板本章內(nèi)容4040Quality Attribute質(zhì)量屬性4141質(zhì)量屬性（非功能屬性）用戶對(duì)產(chǎn)品如何良好地運(yùn)轉(zhuǎn)抱有許多期望。這些特性包括：產(chǎn)品的易用程度如何，執(zhí)行速度如何，可靠性如何，當(dāng)發(fā)生異常情況時(shí)，系統(tǒng)如何處理。這些被稱為軟件質(zhì)量屬性(或質(zhì)量因素)的特性是系統(tǒng)非功能（也叫非行為）部分的需求。Quality Attribute（質(zhì)量屬性）是很難定義的，并且他們經(jīng)常造成開發(fā)者設(shè)計(jì)的產(chǎn)品和客戶滿意的產(chǎn)品之間的差異。“真正的現(xiàn)實(shí)系統(tǒng)中，在決

25、定系統(tǒng)的成功或失敗的因素中，滿足非功能需求往往比滿足功能需求更為重要”。 -Robert Charette(1990) 4242質(zhì)量屬性雖然有許多產(chǎn)品特性可以稱為質(zhì)量屬性(Quality Attribute)，但是在許多系統(tǒng)中需要認(rèn)真考慮的僅是其中的一小部分。如果開發(fā)者知道哪些特性對(duì)項(xiàng)目的成功至關(guān)重要，那么他們就能選擇軟件工程方法來(lái)達(dá)到特定的質(zhì)量目標(biāo)。 （ Glass 1992; DeGrace and Stahl 1993）。根據(jù)不同的設(shè)計(jì)可以把質(zhì)量屬性分類。 （ Boehm 1976; DeGrace and Stahl 1993）。一種屬性分類的方法是把在運(yùn)行時(shí)可識(shí)別的特性與那些不可識(shí)別

26、的特性區(qū)分開（ Bass, Clements and Kazman 1998）。另一種方法是把對(duì)用戶很重要的可見特性與對(duì)開發(fā)者和維護(hù)者很重要的不可見特性區(qū)分開。那些對(duì)開發(fā)者具有重要意義的屬性使產(chǎn)品易于更改、驗(yàn)證，并易于移植到新的平臺(tái)上，從而可以間接地滿足客戶的需要。4343質(zhì)量屬性ISO/IEC 9126將軟件的質(zhì)量分為六個(gè)特征：4444軟件質(zhì)量屬性4545定義質(zhì)量屬性必須根據(jù)用戶對(duì)系統(tǒng)的期望來(lái)確定質(zhì)量屬性。定量地確定重要屬性提供了對(duì)用戶期望的清晰理解，這將有助于設(shè)計(jì)者提出最合理的解決方案。-Gilb 1988然而，大多數(shù)用戶并不知道如何回答諸如“互操作性對(duì)你的重要性如何？”或者“軟件應(yīng)該具有

27、怎樣的可靠性？”等問(wèn)題。在一個(gè)項(xiàng)目中，分析員想出了對(duì)于不同的用戶類可能很重要的屬性，并根據(jù)每一個(gè)屬性設(shè)計(jì)出許多問(wèn)題。他們利用這些問(wèn)題詢問(wèn)每一個(gè)用戶類的代表，可以把每個(gè)屬性分成一級(jí)（不必多加考慮的屬性）到五級(jí)（極其重要的屬性）。這些問(wèn)題的回答有助于分析員決定哪些質(zhì)量特性用作設(shè)計(jì)標(biāo)準(zhǔn)是最重要的。4646定義質(zhì)量屬性然后，分析員與用戶一起為每一屬性確定特定的、可測(cè)量的和可驗(yàn)證的需求（Robertson 1997）。如果質(zhì)量目標(biāo)不可驗(yàn)證，那么就說(shuō)不清是否達(dá)到這些目標(biāo)。在合適的地方為每一個(gè)屬性或目標(biāo)指定級(jí)別或測(cè)量單位，以及最大和最小值。如果不能定量地確定某些對(duì)你的項(xiàng)目很重要的屬性，那么至少應(yīng)該確定其優(yōu)先

28、級(jí)。IEEE關(guān)于軟件質(zhì)量度量方法的標(biāo)準(zhǔn)提出了一個(gè)在綜合質(zhì)量度量基準(zhǔn)體系下定義軟件質(zhì)量需求的方法（ IEEE 1992）4747定義質(zhì)量屬性另一個(gè)定義屬性的方法是確定任何與質(zhì)量期望相沖突的系統(tǒng)行為（ Voas 1999）。通過(guò)定義不悅?cè)艘庑袨橐环N反向需求可以設(shè)計(jì)出強(qiáng)制系統(tǒng)表現(xiàn)出那些行為的測(cè)試用例。如果不能強(qiáng)制系統(tǒng)，那么可能達(dá)到了屬性目標(biāo)。這種方法最適用于要求安全性能很高的應(yīng)用程序，在這些應(yīng)用程序中，系統(tǒng)的差錯(cuò)可能會(huì)導(dǎo)致生命危險(xiǎn)。4848對(duì)用戶重要的屬性Availability 有效性 有效性指的是在預(yù)定的啟動(dòng)時(shí)間中，系統(tǒng)真正可用并且完全運(yùn)行時(shí)間所占的百分比。更正式地說(shuō)，有效性等于系統(tǒng)的平均故障時(shí)

29、間（MTTF）除以平均故障時(shí)間與故障修復(fù)時(shí)間之和。有些任務(wù)比起其它任務(wù)具有更嚴(yán)格的時(shí)間要求，此時(shí)，當(dāng)用戶要執(zhí)行一個(gè)任務(wù)但系統(tǒng)在那一時(shí)刻不可用時(shí)，用戶會(huì)感到很沮喪。詢問(wèn)用戶需要多高的有效性，并且是否在任何時(shí)間，對(duì)滿足業(yè)務(wù)或安全目標(biāo)有效性都是必須的。一個(gè)有效性需求可能這樣說(shuō)明：“工作日期間，在當(dāng)?shù)貢r(shí)間早上6點(diǎn)到午夜，系統(tǒng)的有效性至少達(dá)到99.5 %，在下午4點(diǎn)到6點(diǎn)，系統(tǒng)的有效性至少可達(dá)到99.95%。4949對(duì)用戶重要的屬性2) Efficiency 效率效率是用來(lái)衡量系統(tǒng)如何優(yōu)化處理器、磁盤空間或通信帶寬的（ Davis 1993）。如果系統(tǒng)用完了所有可用的資源，那么用戶遇到的將是性能的下降，

30、這是效率降低的一個(gè)表現(xiàn)。拙劣的系統(tǒng)性能可激怒等待數(shù)據(jù)庫(kù)查詢結(jié)果的用戶，或者可能對(duì)系統(tǒng)安全性造成威脅，就像一個(gè)實(shí)時(shí)處理系統(tǒng)超負(fù)荷一樣。為了在不可預(yù)料的條件下允許安全緩沖，可以這樣定義：“在預(yù)計(jì)的高峰負(fù)載條件下， 10%處理器能力和15%系統(tǒng)可用內(nèi)存必須留出備用。”在定義性能、能力和效率目標(biāo)時(shí)，考慮硬件的最小配置是很重要的。5050對(duì)用戶重要的屬性3) Flexibility 靈活性就像我們所知道的可擴(kuò)充性、增加性、可延伸性和可擴(kuò)展性一樣，靈活性表明了在產(chǎn)品中增加新功能時(shí)所需工作量的大小。如果開發(fā)者預(yù)料到系統(tǒng)的擴(kuò)展性，那么他們可以選擇合適的方法來(lái)最大限度地增大系統(tǒng)的靈活性。靈活性對(duì)于通過(guò)一系列連續(xù)

31、的發(fā)行版本，并采用漸增型和重復(fù)型方式開發(fā)的產(chǎn)品是很重要的。example：“一個(gè)至少具有6個(gè)月產(chǎn)品支持經(jīng)驗(yàn)的軟件維護(hù)程序員可以在一個(gè)小時(shí)之內(nèi)為系統(tǒng)添加一個(gè)新的可支持硬拷貝的輸出設(shè)備。”5151對(duì)用戶重要的屬性4) Integrity 完整性完整性（或安全性）主要涉及：防止非法訪問(wèn)系統(tǒng)功能、防止數(shù)據(jù)丟失、防止病毒入侵并防止私人數(shù)據(jù)進(jìn)入系統(tǒng)。完整性對(duì)于通過(guò)WWW執(zhí)行的軟件已成為一個(gè)重要的議題。電子商務(wù)系統(tǒng)的用戶關(guān)心的是保護(hù)信用卡信息， Web的瀏覽者不愿意那些私人信息或他們所訪問(wèn)過(guò)的站點(diǎn)記錄被非法使用。完整性的需求不能犯任何錯(cuò)誤，即數(shù)據(jù)和訪問(wèn)必須通過(guò)特定的方法完全保護(hù)起來(lái)。用明確的術(shù)語(yǔ)陳述完整性的

32、需求，如身份驗(yàn)證、用戶特權(quán)級(jí)別、訪問(wèn)約束或者需要保護(hù)的精確數(shù)據(jù)。一個(gè)完整性的需求樣本可以這樣描述：“只有擁有查賬員訪問(wèn)特權(quán)的用戶才可以查看客戶交易歷史。”5252對(duì)用戶重要的屬性5) Interoperability 互操作性互操作性表明了產(chǎn)品與其它系統(tǒng)交換數(shù)據(jù)和服務(wù)的難易程度。為了評(píng)估互操作性是否達(dá)到要求的程度，必須知道用戶使用其它哪一種應(yīng)用程序與產(chǎn)品相連接，還要知道他們要交換什么數(shù)據(jù)。example：“化學(xué)制品跟蹤系統(tǒng)應(yīng)該能夠從ChemiDraw和Chem-Struct工具中導(dǎo)入任何有效化學(xué)制品結(jié)構(gòu)圖。”5353對(duì)用戶重要的屬性6) Reliability 可靠性可靠性是軟件無(wú)故障執(zhí)行一段

33、時(shí)間的概率（Musa, Iannino and Okumoto 1987）。健壯性和有效性有時(shí)可看成是可靠性的一部分。衡量軟件可靠性的方法包括正確執(zhí)行操作所占的比例，在發(fā)現(xiàn)新缺陷之前系統(tǒng)運(yùn)行的時(shí)間長(zhǎng)度和缺陷出現(xiàn)的密度。根據(jù)如果發(fā)生故障對(duì)系統(tǒng)有多大影響和對(duì)于最大的可靠性的費(fèi)用是否合理，來(lái)定量地確定可靠性需求。如果軟件滿足了它的可靠性需求，那么即使該軟件還存在缺陷，也可認(rèn)為達(dá)到其可靠性目標(biāo)。要求高可靠性的系統(tǒng)也是為高可測(cè)試性系統(tǒng)設(shè)計(jì)的。Example:“由于軟件失效引起實(shí)驗(yàn)失敗的概率應(yīng)不超過(guò)5”。5454對(duì)用戶重要的屬性7) Robustness 健壯性健壯性指的是當(dāng)系統(tǒng)或其組成部分遇到非法輸入數(shù)

34、據(jù)、相關(guān)軟件或硬件組成部分的缺陷或異常的操作情況時(shí)，能繼續(xù)正確運(yùn)行功能的程度。健壯的軟件可以從發(fā)生問(wèn)題的環(huán)境中完好地恢復(fù)并且可容忍用戶的錯(cuò)誤。當(dāng)從用戶那里獲取健壯性的目標(biāo)時(shí)，詢問(wèn)系統(tǒng)可能遇到的錯(cuò)誤條件并且要了解用戶想讓系統(tǒng)如何響應(yīng)。“所有的規(guī)劃參數(shù)都要指定一個(gè)缺省值，當(dāng)輸入數(shù)據(jù)丟失或無(wú)效時(shí)，就使用缺省值數(shù)據(jù)。”這個(gè)例子反映了對(duì)一個(gè)“用戶”是另一個(gè)軟件應(yīng)用程序的產(chǎn)品，其健壯性設(shè)計(jì)的方法。5555對(duì)用戶重要的屬性8) Usability 可用性可用性也稱為“易用性”和“人類工程”，它所描述的是許多組成“用戶友好”的因素。可用性衡量準(zhǔn)備輸入、操作和理解產(chǎn)品輸出所花費(fèi)的努力。必須權(quán)衡易用性和學(xué)習(xí)如何操

35、縱產(chǎn)品的簡(jiǎn)易性。對(duì)于可用性的討論可以得出可測(cè)量的目標(biāo)，例如:一個(gè)培訓(xùn)過(guò)的用戶應(yīng)該可以在平均3分鐘或最多5分鐘時(shí)間以內(nèi)，完成從供應(yīng)商目錄表中請(qǐng)求一種化學(xué)制品的操作。可用性還包括對(duì)于新用戶或不常使用產(chǎn)品的用戶在學(xué)習(xí)使用產(chǎn)品時(shí)的簡(jiǎn)易程度。易學(xué)程度的目標(biāo)可以經(jīng)常定量地測(cè)量。例如，“一個(gè)新用戶用不到3 0分鐘時(shí)間適應(yīng)環(huán)境后，就應(yīng)該可以對(duì)一個(gè)化學(xué)制品提出請(qǐng)求”，或者“新的操作員在一天的培訓(xùn)學(xué)習(xí)之后，就應(yīng)該可以正確執(zhí)行他們所要求的任務(wù)的95%”。當(dāng)定義可用性或可學(xué)性的需求時(shí)，應(yīng)考慮到在判斷產(chǎn)品是否達(dá)到需求而對(duì)產(chǎn)品進(jìn)行測(cè)試的費(fèi)用。5656對(duì)開發(fā)者重要的屬性Maintainability 可維護(hù)性可維護(hù)性表明了

36、在軟件中糾正一個(gè)缺陷或做一次更改的簡(jiǎn)易程度。可維護(hù)性取決于理解軟件、更改軟件和測(cè)試軟件的簡(jiǎn)易程度，可維護(hù)性與靈活性密切相關(guān)。高可維護(hù)性對(duì)于那些經(jīng)歷周期性更改的產(chǎn)品或快速開發(fā)的產(chǎn)品很重要。可以根據(jù)修復(fù)（fix）一個(gè)問(wèn)題所花的平均時(shí)間和修復(fù)正確的百分比來(lái)衡量可維護(hù)性。Example:“函數(shù)調(diào)用不能超過(guò)兩層深度“，并且“每一個(gè)軟件模塊中，注釋與源代碼語(yǔ)句的比例至少為12”。5757對(duì)開發(fā)者重要的屬性2) Portability 可移植性可移植性是度量把一個(gè)軟件從一種運(yùn)行環(huán)境轉(zhuǎn)移到另一種運(yùn)行環(huán)境中所花費(fèi)的工作量。軟件可移植的設(shè)計(jì)方法與軟件可重用的設(shè)計(jì)方法相似（ Glass 1992）。可移植性對(duì)于工程

37、的成功是不重要的，對(duì)工程的結(jié)果也無(wú)關(guān)緊要。可以移植的目標(biāo)必須陳述產(chǎn)品中可以移植到其它環(huán)境的那一部分，并確定相應(yīng)的目標(biāo)環(huán)境。于是，開發(fā)者就能選擇設(shè)計(jì)和編碼方法以適當(dāng)提高產(chǎn)品的可移植性。5858對(duì)開發(fā)者重要的屬性3) Reusability 可重用性從軟件開發(fā)的長(zhǎng)遠(yuǎn)目標(biāo)上看，可重用性表明了一個(gè)軟件組件除了在最初開發(fā)的系統(tǒng)中使用之外，還可以在其它應(yīng)用程序中使用的程度。比起創(chuàng)建一個(gè)打算只在一個(gè)應(yīng)用程序中使用的組件，開發(fā)可重用軟件的費(fèi)用會(huì)更大些。可重用軟件必須標(biāo)準(zhǔn)化、資料齊全、不依賴于特定的應(yīng)用程序和運(yùn)行環(huán)境，并具有一般性（ DeGrace and Stahl 1993）。確定新系統(tǒng)中哪些元素需要用方便

38、于代碼重用的方法設(shè)計(jì)，或者規(guī)定作為項(xiàng)目副產(chǎn)品的可重用性組件庫(kù)。5959對(duì)開發(fā)者重要的屬性4) Testability 可測(cè)試性可測(cè)試性指的是測(cè)試軟件組件或集成產(chǎn)品時(shí)查找缺陷的簡(jiǎn)易程度。如果產(chǎn)品中包含復(fù)雜的算法和邏輯，或如果具有復(fù)雜的功能性的相互關(guān)系，那么對(duì)于可測(cè)試性的設(shè)計(jì)就很重要。如果經(jīng)常更改產(chǎn)品，那么可測(cè)試性也是很重要的，因?yàn)閷⒔?jīng)常對(duì)產(chǎn)品進(jìn)行回歸測(cè)試來(lái)判斷更改是否破壞了現(xiàn)有的功能性。example：“一個(gè)模塊的最大循環(huán)復(fù)雜度不能超過(guò)20”。循環(huán)復(fù)雜度度量一個(gè)模塊源代碼中邏輯分支數(shù)目（McCabe 1982）。在一個(gè)模塊中加入過(guò)多的分支和循環(huán)將使該模塊難于測(cè)試、理解和維護(hù)。如果一些模塊的循環(huán)復(fù)

39、雜度大于2 0，這并不會(huì)導(dǎo)致整個(gè)項(xiàng)目的失敗，但指定這樣的設(shè)計(jì)標(biāo)準(zhǔn)有助于開發(fā)者達(dá)到一個(gè)令人滿意的質(zhì)量目標(biāo)。6060屬性的取舍用戶和開發(fā)者必須確定哪些屬性比其它屬性更為重要，并定出優(yōu)先級(jí)。在他們作決策時(shí)，要始終遵照那些優(yōu)先級(jí)。6161選擇的質(zhì)量屬性之間的正負(fù)關(guān)系有效性效率靈活性完整性互操作性可維護(hù)性可移植性可靠性可重用性健壯性可測(cè)試性可用性6262平衡性一個(gè)單元格中的加號(hào)表明單元格所在行的屬性增加了對(duì)其所在列的屬性的積極影響。例如，增強(qiáng)軟件可重用性的設(shè)計(jì)方法也可以使軟件變得靈活、更易于與其它軟件組件相連接、更易于維護(hù)、更易于移植并且更易于測(cè)試。一個(gè)單元格中的減號(hào)表明單元格所在行的屬性增加了對(duì)其所在

40、列的屬性的不利影響。高效性對(duì)其它許多屬性具有消極影響。如果你編寫最緊湊，最快的代碼，并使用一種特殊的預(yù)編譯器和操作系統(tǒng)，那么這將不易移植到其它環(huán)境，而且還難于維護(hù)和改進(jìn)軟件。6363平衡性為了達(dá)到產(chǎn)品特性的最佳平衡，必須在需求獲取階段識(shí)別、確定相關(guān)的質(zhì)量屬性，并且為之確定優(yōu)先級(jí)。當(dāng)為項(xiàng)目定義重要的質(zhì)量屬性時(shí)，利用上圖可以防止發(fā)生與目標(biāo)沖突的行為。在軟件中，其自身不能實(shí)現(xiàn)質(zhì)量特性的合理平衡。在需求獲取的過(guò)程中，加入對(duì)質(zhì)量屬性期望的討論，并把所了解的寫入軟件需求規(guī)格說(shuō)明中。這樣，才有可能提供使所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者滿意的產(chǎn)品。6464軟件需求規(guī)格說(shuō)明編寫需求文檔的原則需求示例改進(jìn)前后質(zhì)量屬性軟件需求規(guī)

41、格說(shuō)明模板本章內(nèi)容軟件需求規(guī)格說(shuō)明模板a. 引言 a.1 目的 a.2 文檔約定 a.3 預(yù)期的讀者和閱讀建議 a.4 產(chǎn)品的范圍 a.5 參考文獻(xiàn)b. 綜合描述 b.1 產(chǎn)品的前景 b.2 產(chǎn)品的功能 b.3 用戶類和特征 b.4 運(yùn)行環(huán)境 b.5 設(shè)計(jì)和實(shí)現(xiàn)上的限制 b.6 假設(shè)和依賴C. 外部接口需求 C.1 用戶界面 C.2 硬件接口 C.3 軟件接口 C.4 通信接口d. 系統(tǒng)特性 d.1 說(shuō)明和優(yōu)先級(jí) d.2 激勵(lì)響應(yīng)序列 d.3 功能需求e. 其它非功能需求 e.1 性能需求 e.2 安全設(shè)施需求 e.3 安全性需求 e.4 軟件質(zhì)量屬性 e.5 業(yè)務(wù)規(guī)則 e.6 用戶文檔f.

42、其它需求附錄A：詞匯表附錄B：分析模型附錄C：待確定問(wèn)題的列表從IEEE 830標(biāo)準(zhǔn)改寫并擴(kuò)充的軟件需求規(guī)格說(shuō)明的模板 需求規(guī)格說(shuō)明模板-引言 a. 引言引言提出了對(duì)軟件需求規(guī)格說(shuō)明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。a.1 目的對(duì)產(chǎn)品進(jìn)行定義，在該文檔中詳盡說(shuō)明了這個(gè)產(chǎn)品的軟件需求，包括修正或發(fā)行版本號(hào)。如果這個(gè)軟件需求規(guī)格說(shuō)明只與整個(gè)系統(tǒng)的一部分有關(guān)系，那么只定義文檔中說(shuō)明的部分或子系統(tǒng)。a.2 文檔約定描述編寫文檔時(shí)所采用的標(biāo)準(zhǔn)或排版約定，包括正文風(fēng)格、提示區(qū)或重要符號(hào)。列如，說(shuō)明了高層需求的優(yōu)先級(jí)是否可以被其所有細(xì)化的需求繼承，或者每個(gè)需求陳述是否都有其自身的優(yōu)先級(jí)

43、。 需求規(guī)格說(shuō)明模板-引言 a.3 預(yù)期的讀者和閱讀建議列舉了軟件需求規(guī)格說(shuō)明所針對(duì)的不同讀者，列如開發(fā)人員、項(xiàng)目經(jīng)理、營(yíng)銷人員、用戶、測(cè)試人員或文檔的編寫人員。描述了文檔中剩余部分的內(nèi)容及其組織結(jié)構(gòu)。提出了最適合于每一類型讀者閱讀文檔的建議。a.4 產(chǎn)品的范圍提供了對(duì)指定的軟件及其目的的簡(jiǎn)短描述，包括利益和目標(biāo)。把軟件與企業(yè)目標(biāo)或業(yè)務(wù)策略相聯(lián)系。可以參考項(xiàng)目視圖和范圍文檔而不是將其內(nèi)容復(fù)制到這里。a.5 參考文獻(xiàn)列舉了編寫軟件需求規(guī)格說(shuō)明時(shí)所參考的資料或其它資源。這可能包括用戶界面風(fēng)格指導(dǎo)、合同、標(biāo)準(zhǔn)、系統(tǒng)需求規(guī)格說(shuō)明、使用實(shí)例文檔，或相關(guān)產(chǎn)品的軟件需求規(guī)格說(shuō)明。在這里應(yīng)該給出詳細(xì)的信息，包括標(biāo)題名稱、作者、版本號(hào)、日期、出版單位或資料來(lái)源，以方便讀者查閱這些文獻(xiàn)。 需求規(guī)格說(shuō)明模板-綜合描述 b.綜合描述這一部分概述了正在定義的產(chǎn)品以及它所運(yùn)行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設(shè)和依賴。b.1 產(chǎn)品的前景描述了軟件需求規(guī)格說(shuō)明中所定義的產(chǎn)品的背景和起源。 b.2 產(chǎn)品的功能概述了產(chǎn)品所具有的主要功能。其詳細(xì)內(nèi)容將在d中描述，所以在此只需要概略地總結(jié)，例如用列表的方法給出。b.3 用戶類和特征確定你覺得可能使用該產(chǎn)品的不同用戶類并描述它們相關(guān)的特征。 需求規(guī)格說(shuō)明模板-綜合描述 b.4 運(yùn)行環(huán)境描述了軟