鄭州大學(xué)需求規(guī)格說明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22、可能的話，應(yīng)當(dāng)根據(jù)主貨物編號列表在線確認(rèn)所輸入的貨物編號?！薄叭绻赡艿脑挕边@句話意味著什么？該需求是否在技術(shù)上可行？是否可以在線訪問主貨物編號列表？如果你不能確信是否可以遞交一個請求，那么就使用“待確定” ( TBD )來表示未解決的問題。這個需求是不完整的，因為它并沒有指明如果確認(rèn)通過或失敗，將會發(fā)生什么情況。應(yīng)該盡量避免使用不精確的詞匯，例如“應(yīng)當(dāng)”?？蛻艨赡苄枰@個功能或者不需要這個功能。一些需求規(guī)格說明利用關(guān)鍵字之間微妙的差別如“應(yīng)當(dāng)”，“必須”和“可能”來指明重要性。一些人更喜歡使用“必須”或“將要”來明確說明需求的目的并且明確指定其優(yōu)先級。3737Example 4（contd.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

41、格說明模板本章內(nèi)容軟件需求規(guī)格說明模板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 運行環(huán)境 b.5 設(shè)計和實現(xiàn)上的限制 b.6 假設(shè)和依賴C. 外部接口需求 C.1 用戶界面 C.2 硬件接口 C.3 軟件接口 C.4 通信接口d. 系統(tǒng)特性 d.1 說明和優(yōu)先級 d.2 激勵響應(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：待確定問題的列表從IEEE 830標(biāo)準(zhǔn)改寫并擴(kuò)充的軟件需求規(guī)格說明的模板 需求規(guī)格說明模板-引言 a. 引言引言提出了對軟件需求規(guī)格說明的縱覽，這有助于讀者理解文檔如何編寫并且如何閱讀和解釋。a.1 目的對產(chǎn)品進(jìn)行定義，在該文檔中詳盡說明了這個產(chǎn)品的軟件需求，包括修正或發(fā)行版本號。如果這個軟件需求規(guī)格說明只與整個系統(tǒng)的一部分有關(guān)系，那么只定義文檔中說明的部分或子系統(tǒng)。a.2 文檔約定描述編寫文檔時所采用的標(biāo)準(zhǔn)或排版約定，包括正文風(fēng)格、提示區(qū)或重要符號。列如，說明了高層需求的優(yōu)先級是否可以被其所有細(xì)化的需求繼承，或者每個需求陳述是否都有其自身的優(yōu)先級

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