第06講軟件需求驗證

1、第六章第六章 軟件需求驗證軟件需求驗證課程提綱課程提綱軟件需求基本理論和概念軟件需求基本理論和概念 軟件需求工程過程軟件需求工程過程 軟件需求獲取軟件需求獲取 軟件需求分析軟件需求分析 軟件需求規(guī)格說明軟件需求規(guī)格說明 軟件需求驗證軟件需求驗證 軟件需求管理軟件需求管理 軟件需求實現軟件需求實現 軟件需求工程新進展軟件需求工程新進展 軟件需求開發(fā)與需求管理工具軟件需求開發(fā)與需求管理工具內容提要軟件的質量屬性分析需求質量驗證需求評審需求測試 1. 軟件的質量屬性分析軟件的質量屬性分析 軟件質量屬性軟件質量屬性( (或質量因素或質量因素) )的特性是系統非功能（也叫非的特性是系統非功能（也叫非行為

2、）部分的需求。這些特性包括：行為）部分的需求。這些特性包括：產品的易用程度如何，產品的易用程度如何，執(zhí)行速度如何，執(zhí)行速度如何，可靠性如何，可靠性如何，當發(fā)生異常情況時，系統如何處理等。當發(fā)生異常情況時，系統如何處理等。 質量屬性區(qū)分：質量屬性區(qū)分：一種屬性分類的方法是把在運行時可識別的特性與那一種屬性分類的方法是把在運行時可識別的特性與那些不可識別的特性區(qū)分開；些不可識別的特性區(qū)分開；另一種方法是把對用戶很重要的可見特性與對開發(fā)者另一種方法是把對用戶很重要的可見特性與對開發(fā)者和維護者很重要的不可見特性區(qū)分開。和維護者很重要的不可見特性區(qū)分開。 那些對開發(fā)者具有重要意義的屬性使產品易于更改、那

3、些對開發(fā)者具有重要意義的屬性使產品易于更改、驗證，并易于移植到新的平臺上，從而可以間接地滿足客驗證，并易于移植到新的平臺上，從而可以間接地滿足客戶的需要。戶的需要。軟件質量屬性列表軟件質量屬性列表 對用戶最重要的屬性： 對開發(fā)者最重要的屬性： 可用性（availability） 可維護性( maintainability） 高效性( efficiency) 可移植性( portability ) 靈活性( flexibility ) 可重用性( reusability ) 完整性( integrity) 可測試性( testability ) 互操作性( interoperability )

4、可靠性( reliability ) 健壯性( robustness )Relationships among selected quality attributes 2. 需求質量驗證 需求驗證需求驗證是需求開發(fā)的第四部分（其余三是需求開發(fā)的第四部分（其余三個為獲取、分析和編寫規(guī)格說明），個為獲取、分析和編寫規(guī)格說明），所包所包括的活動是為了確定以下幾方面的內容：括的活動是為了確定以下幾方面的內容： 軟件需求規(guī)格說明正確描述了預期的系統行為軟件需求規(guī)格說明正確描述了預期的系統行為和特征和特征。 從系統需求或其它來源中得到軟件需求。從系統需求或其它來源中得到軟件需求。 需求是完整的和高質量的。

5、需求是完整的和高質量的。 所有對需求的看法是一致的。所有對需求的看法是一致的。 需求為繼續(xù)進行產品設計、構造和測試提供了需求為繼續(xù)進行產品設計、構造和測試提供了足夠的基礎。足夠的基礎。 需求驗證確保了需求符合需求陳述需求驗證確保了需求符合需求陳述（ requirement statement）的良好特征）的良好特征（完整的、正確的、靈活的、必要的、具（完整的、正確的、靈活的、必要的、具有優(yōu)先級的、無二義性及可驗證的）并且有優(yōu)先級的、無二義性及可驗證的）并且符合需求規(guī)格說明的良好特性（完整的、符合需求規(guī)格說明的良好特性（完整的、一致的、易修改的、可跟蹤的）。當然，一致的、易修改的、可跟蹤的）。當

6、然，你只能驗證那些已編寫成文檔的需求，而你只能驗證那些已編寫成文檔的需求，而那些存在于用戶或開發(fā)者思維中的沒有表那些存在于用戶或開發(fā)者思維中的沒有表露的、含蓄的需求則不予驗證。露的、含蓄的需求則不予驗證。需求質量驗證 在收集需求并編寫成需求文檔后，你所進行的在收集需求并編寫成需求文檔后，你所進行的需需求驗證求驗證并不僅僅是一個獨立的階段。一些驗證活并不僅僅是一個獨立的階段。一些驗證活動，例如對漸增型軟件需求規(guī)格說明的反復評審，動，例如對漸增型軟件需求規(guī)格說明的反復評審，將貫穿著反復獲取需求、分析和編寫規(guī)格說明的將貫穿著反復獲取需求、分析和編寫規(guī)格說明的整個過程。其它的驗證步驟，例如軟件需求規(guī)格

7、整個過程。其它的驗證步驟，例如軟件需求規(guī)格說明的正式審查，是在正式確定軟件需求規(guī)格說說明的正式審查，是在正式確定軟件需求規(guī)格說明基線之前對需求分析質量進行的最后一次有用明基線之前對需求分析質量進行的最后一次有用的質量過濾。當你的項目計劃或實際工作中的獨的質量過濾。當你的項目計劃或實際工作中的獨立任務破壞了結構性時，就要結合進行需求驗證立任務破壞了結構性時，就要結合進行需求驗證活動，并且為隨后出現的返工預先安排一段時間，活動，并且為隨后出現的返工預先安排一段時間，這通常會在質量控制活動之后進行。這通常會在質量控制活動之后進行。需求質量驗證 有時，項目的參與者不愿意在評審和測試軟件需有時，項目的參

8、與者不愿意在評審和測試軟件需求規(guī)格說明上花費時間。雖然在計劃安排中插入求規(guī)格說明上花費時間。雖然在計劃安排中插入一段時間來提高需求質量似乎相應地把交付日期一段時間來提高需求質量似乎相應地把交付日期延遲了一段時間，但是這種想法是建立在假設驗延遲了一段時間，但是這種想法是建立在假設驗證需求上的投資將不產生效果的基礎上的。實際證需求上的投資將不產生效果的基礎上的。實際上，這種投資可以減少返工并加快系統測試，從上，這種投資可以減少返工并加快系統測試，從而真正縮短了開發(fā)時間。而真正縮短了開發(fā)時間。需求質量驗證Validation Answer the question “Do I build the r

9、ight thing?” Requirements validation is done either against real-world user needs or high level requirements specificationsVerification Answer the question “Do I build what I was going to build?” Requirements verification is done typically against lower level requirements, design and/or test procedu

10、res需求評審 由一些非軟件開發(fā)人員進行產品檢查以發(fā)由一些非軟件開發(fā)人員進行產品檢查以發(fā)現產品所存在的問題，這就是技術評審。現產品所存在的問題，這就是技術評審。 需求文檔的評審是一項精益求精的技術，需求文檔的評審是一項精益求精的技術，它可以發(fā)現那些二義性的或不確定的需求，它可以發(fā)現那些二義性的或不確定的需求，那些由于定義不清而不能作為設計基礎的那些由于定義不清而不能作為設計基礎的需求，還有那些實際上是設計規(guī)格說明的需求，還有那些實際上是設計規(guī)格說明的所謂的所謂的“需求需求”。 需求評審也為風險承擔者們提供了在特定需求評審也為風險承擔者們提供了在特定問題上達成共識的方法。問題上達成共識的方法。需

11、求評審方法 非正式評審的方法包括把工作產品分發(fā)給許多其非正式評審的方法包括把工作產品分發(fā)給許多其它的開發(fā)人員粗略看一看和走過場似地檢查一遍它的開發(fā)人員粗略看一看和走過場似地檢查一遍（walkthrough）。）。 正式技術評審的最好類型叫作審查正式技術評審的最好類型叫作審查（Inspection）。正式評審內容需要記錄在案，）。正式評審內容需要記錄在案，它包括確定材料、評審員、評審小組對產品是否它包括確定材料、評審員、評審小組對產品是否完整或是否需要進一步工作的判定，以及對所發(fā)完整或是否需要進一步工作的判定，以及對所發(fā)現的錯誤和所提出的問題的總結。正式評審小組現的錯誤和所提出的問題的總結。正式

12、評審小組的成員對評審的質量負責，而開發(fā)者則最終對他的成員對評審的質量負責，而開發(fā)者則最終對他們所開發(fā)的產品的質量負責。們所開發(fā)的產品的質量負責。 如果你對提高軟件的質量持有認真的態(tài)度，那么如果你對提高軟件的質量持有認真的態(tài)度，那么就審查所編寫需求文檔的每一行。就審查所編寫需求文檔的每一行。Software Requirement ReviewInformal review Peer desk check Pass around, such as through email Walk throughFormal reviews Fagan inspection - used by many or

13、ganization as an effective way to improve software qualityPeer Review需求審查過程需求審查過程參與者參與者產品的開發(fā)者及其可能的同組成員產品的開發(fā)者及其可能的同組成員編寫需求文檔編寫需求文檔的分析員提供這方面觀點。的分析員提供這方面觀點。先前產品的開發(fā)者或正在評審的項目的規(guī)格說明編寫先前產品的開發(fā)者或正在評審的項目的規(guī)格說明編寫者。者。要根據正在審查的文檔來開展工作的人們要根據正在審查的文檔來開展工作的人們-對于一個對于一個軟件需求規(guī)格說明，你可能需要包括一個開發(fā)人員、軟件需求規(guī)格說明，你可能需要包括一個開發(fā)人員、一個測試人員

14、、一個項目經理和一個用戶文檔編寫人一個測試人員、一個項目經理和一個用戶文檔編寫人員，他們的工作基礎都是軟件需求規(guī)格說明。這些審員，他們的工作基礎都是軟件需求規(guī)格說明。這些審查人員將會發(fā)現不同類型的問題。查人員將會發(fā)現不同類型的問題。審查組中的審查人員應限制在審查組中的審查人員應限制在7個人左右或者更少。個人左右或者更少。需求審查過程需求審查過程審查中每個成員扮演的角色審查中每個成員扮演的角色作者。作者創(chuàng)建或維護正在被審查的產品。作者。作者創(chuàng)建或維護正在被審查的產品。調解者。調解者（調解者。調解者（moderator）或者審查主）或者審查主持者所做的是：與作者一起為審查制訂計劃，持者所做的是：與

15、作者一起為審查制訂計劃，協調各種活動，并且推進審查會的進行。協調各種活動，并且推進審查會的進行。讀者。讀者的角色由審查員扮演。讀者。讀者的角色由審查員扮演。記錄員。記錄員，或書記員，用標準化的形記錄員。記錄員，或書記員，用標準化的形式記錄在審查會中提出的問題和缺陷。記錄式記錄在審查會中提出的問題和缺陷。記錄員必須仔細審查所寫的材料以確保記錄的正員必須仔細審查所寫的材料以確保記錄的正確性。確性。需求審查過程需求審查過程審查階段審查階段規(guī)劃（規(guī)劃（Planning）。作者和調解者協同對審查進行）。作者和調解者協同對審查進行規(guī)劃，以決定誰該參加審查，審查員在召開審查會之規(guī)劃，以決定誰該參加審查，審查

16、員在召開審查會之前應收到什么材料并且需要召開幾次審查會。前應收到什么材料并且需要召開幾次審查會?？傮w會議（總體會議（overview meeting）。總體會議可以為）?？傮w會議可以為審查員提供了解會議的信息，包括他們要審查的材料審查員提供了解會議的信息，包括他們要審查的材料的背景，作者所作的假設和作者的特定審查目標。的背景，作者所作的假設和作者的特定審查目標。準備（準備（Preparation）。在正式審查的準備階段，每）。在正式審查的準備階段，每個審查員以典型缺陷（個審查員以典型缺陷（defect）清單（在本章的后面）清單（在本章的后面部分介紹）為指導，檢查產品可能出現的錯誤，并提部分介紹

17、）為指導，檢查產品可能出現的錯誤，并提出問題。出問題。需求審查過程需求審查過程審查階段審查階段審查會議（審查會議（Inspection meeting）。在審查會進行過程中，讀）。在審查會進行過程中，讀者通過軟件需求規(guī)格說明指導審查小組，一次解釋一個需求。者通過軟件需求規(guī)格說明指導審查小組，一次解釋一個需求。當審查員提出可能的錯誤或其它問題時，記錄員就記錄這些內當審查員提出可能的錯誤或其它問題時，記錄員就記錄這些內容，其形式可以成為需求作者的工作項列表。會議的目的是盡容，其形式可以成為需求作者的工作項列表。會議的目的是盡可能多地發(fā)現需求規(guī)格說明中的重大缺陷。可能多地發(fā)現需求規(guī)格說明中的重大缺陷

18、。重寫（重寫（rework）。我所觀察到的幾乎每一個質量控制活動都可）。我所觀察到的幾乎每一個質量控制活動都可能發(fā)現一些需求缺陷。因此，作者必須在審查會之后，安排一能發(fā)現一些需求缺陷。因此，作者必須在審查會之后，安排一段時間用于重寫文檔。段時間用于重寫文檔。重審（重審（follow-up）。這是審查工作的最后一步，調解者或指派）。這是審查工作的最后一步，調解者或指派人單獨重審由作者重寫的需求規(guī)格說明。重審確保了所有提出人單獨重審由作者重寫的需求規(guī)格說明。重審確保了所有提出的問題都能得到解決，并且正確修改了需求的錯誤。重審結束的問題都能得到解決，并且正確修改了需求的錯誤。重審結束了審查的全過程并

19、且可以使調解者做出判斷：是否已滿足審查了審查的全過程并且可以使調解者做出判斷：是否已滿足審查的退出標準。的退出標準。需求審查過程需求審查過程進入和退出審查的標準進入和退出審查的標準一些關于需求文檔的進入審查的標準：一些關于需求文檔的進入審查的標準：文檔符合標準模板。文檔符合標準模板。文檔已經做過拼寫檢查和語法檢查。文檔已經做過拼寫檢查和語法檢查。作者已經檢查了文檔在版面安排上所存在的錯誤。作者已經檢查了文檔在版面安排上所存在的錯誤。已經獲得了審查員所需要的先前或參考文檔，例已經獲得了審查員所需要的先前或參考文檔，例如系統需求規(guī)格說明。如系統需求規(guī)格說明。在文檔中打印了行序號以方便在審查中對特定

20、位在文檔中打印了行序號以方便在審查中對特定位置的查閱。置的查閱。所有未解決的問題都被標記為所有未解決的問題都被標記為TBD（待確定）。（待確定）。包括了文檔中使用到的術語詞匯表。包括了文檔中使用到的術語詞匯表。需求審查過程需求審查過程進入和退出審查的標準進入和退出審查的標準一些關于需求文檔的退出標準：一些關于需求文檔的退出標準：已經明確闡述了審查員提出的所有問題。已經明確闡述了審查員提出的所有問題。已經正確修改了文檔。已經正確修改了文檔。修訂過的文檔已經進行了拼寫檢查和語法檢查。修訂過的文檔已經進行了拼寫檢查和語法檢查。所有所有TBD的問題已經全部解決，或者已經記錄下的問題已經全部解決，或者已

21、經記錄下每個待確定問題的解決過程，目標日期和提出問每個待確定問題的解決過程，目標日期和提出問題的人。題的人。文檔已經登記入項目的配置管理系統。文檔已經登記入項目的配置管理系統。檢查是否已將審查過的資料送到有關收集處。檢查是否已將審查過的資料送到有關收集處。需求審查過程需求審查過程需求審查清單需求審查清單為了使審查員警惕他們所審查的產品中的習為了使審查員警惕他們所審查的產品中的習慣性錯誤，對你的公司所創(chuàng)建的每一類型的慣性錯誤，對你的公司所創(chuàng)建的每一類型的需求文檔建立一份清單。需求文檔建立一份清單。這些清單可以提醒審查員以前經常發(fā)生的需這些清單可以提醒審查員以前經常發(fā)生的需求問題。求問題。需求評審

22、的困難需求評審的困難 大型的需求文檔大型的需求文檔 龐大的審查小組龐大的審查小組 確保每個參與者都是為了尋找錯誤，而不是為了解軟確保每個參與者都是為了尋找錯誤，而不是為了解軟件需求規(guī)格說明中的內容或者為了維護行政上的位置。件需求規(guī)格說明中的內容或者為了維護行政上的位置。 理解審查員所代表的觀點（例如客戶、開發(fā)者或測試理解審查員所代表的觀點（例如客戶、開發(fā)者或測試者），并且委婉地拒絕以相同的觀點看待問題的參與者），并且委婉地拒絕以相同的觀點看待問題的參與者。者。 把審查組分成若干小組并行地審查軟件需求規(guī)格說明，把審查組分成若干小組并行地審查軟件需求規(guī)格說明，并把他們發(fā)現的錯誤集中起來，剔除重復的

23、部分。并把他們發(fā)現的錯誤集中起來，剔除重復的部分。 審查員在地域上的分散審查員在地域上的分散需求測試 通過閱讀軟件需求規(guī)格說明，通常很難想像在特定環(huán)境下通過閱讀軟件需求規(guī)格說明，通常很難想像在特定環(huán)境下的系統行為。的系統行為。 以功能需求為基礎或者從使用實例派生出來的測試用例可以功能需求為基礎或者從使用實例派生出來的測試用例可以使項目參與者看清系統的行為。雖然沒有在運行系統上以使項目參與者看清系統的行為。雖然沒有在運行系統上執(zhí)行測試用例，但是設計測試用例的簡單動作可以解釋需執(zhí)行測試用例，但是設計測試用例的簡單動作可以解釋需求的許多問題。求的許多問題。 如果你在部分需求穩(wěn)定時就開始開發(fā)測試用例，

24、那么就可如果你在部分需求穩(wěn)定時就開始開發(fā)測試用例，那么就可以及早發(fā)現問題并以較少的費用解決這些問題。以及早發(fā)現問題并以較少的費用解決這些問題。 編寫關于黑盒子或功能上的測試用例可以明確在特定條件編寫關于黑盒子或功能上的測試用例可以明確在特定條件下系統運行的任務。因為你無法描述可能的系統響應，在下系統運行的任務。因為你無法描述可能的系統響應，在你面前將會出現一些模糊的和二義性的需求。你面前將會出現一些模糊的和二義性的需求。 當分析員、開發(fā)人員和客戶通過測試用例進行研究時，他當分析員、開發(fā)人員和客戶通過測試用例進行研究時，他們將對產品如何運行的問題有更清晰的認識。們將對產品如何運行的問題有更清晰的

25、認識。需求測試 在開發(fā)過程的早期階段，可以從使用實例中獲得概念上的在開發(fā)過程的早期階段，可以從使用實例中獲得概念上的功能測試用例。然后，你就可以利用測試用例來驗證文本功能測試用例。然后，你就可以利用測試用例來驗證文本需求規(guī)格說明和分析模型（例如對話圖）并評價原型。這需求規(guī)格說明和分析模型（例如對話圖）并評價原型。這些基于模仿使用的測試用例可以作為客戶驗收測試的基礎。些基于模仿使用的測試用例可以作為客戶驗收測試的基礎。 在正式的系統測試中，可以把它們詳述成測試用例和過程。在正式的系統測試中，可以把它們詳述成測試用例和過程。 在客戶定義他們驗收的標準時，你詢問客戶的基本問題是：在客戶定義他們驗收的標準時，你詢問客戶的基本問題是：“如果開發(fā)出你們所期望的軟件，你是怎么來判斷開發(fā)出如果開發(fā)出你們所期望的軟件，你是怎么來判斷開發(fā)出的軟件是你真正所需要的？的軟件是你真正所需要的？” 如果他們不能回答關于每如果他們不能回答關于每個特性或使用實例的這種問題，他們就必須澄清需求。個特性或使用實例的這種問題，他們就必須澄清需求。u 需求測試的含義最初對你來說可能看起來比較抽象?？梢杂靡粋€例子把需求測試的含義最初對你來說可能看起來比較抽象?？梢杂靡粋€例子把這個概念描述得更清楚，所以讓我們看一下這個概念描述得更清楚，所以讓