第06講軟件需求驗證

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

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

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

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

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

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

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

8、與者不愿意在評審和測試軟件需求規(guī)格說明上花費時間。雖然在計劃安排中插入求規(guī)格說明上花費時間。雖然在計劃安排中插入一段時間來提高需求質(zhì)量似乎相應(yīng)地把交付日期一段時間來提高需求質(zhì)量似乎相應(yīng)地把交付日期延遲了一段時間，但是這種想法是建立在假設(shè)驗延遲了一段時間，但是這種想法是建立在假設(shè)驗證需求上的投資將不產(chǎn)生效果的基礎(chǔ)上的。實際證需求上的投資將不產(chǎn)生效果的基礎(chǔ)上的。實際上，這種投資可以減少返工并加快系統(tǒng)測試，從上，這種投資可以減少返工并加快系統(tǒng)測試，從而真正縮短了開發(fā)時間。而真正縮短了開發(fā)時間。需求質(zhì)量驗證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ā)人員進(jìn)行產(chǎn)品檢查以發(fā)由一些非軟件開發(fā)人員進(jìn)行產(chǎn)品檢查以發(fā)現(xiàn)產(chǎn)品所存在的問題，這就是技術(shù)評審?，F(xiàn)產(chǎn)品所存在的問題，這就是技術(shù)評審。 需求文檔的評審是一項精益求精的技術(shù)，需求文檔的評審是一項精益求精的技術(shù)，它可以發(fā)現(xiàn)那些二義性的或不確定的需求，它可以發(fā)現(xiàn)那些二義性的或不確定的需求，那些由于定義不清而不能作為設(shè)計基礎(chǔ)的那些由于定義不清而不能作為設(shè)計基礎(chǔ)的需求，還有那些實際上是設(shè)計規(guī)格說明的需求，還有那些實際上是設(shè)計規(guī)格說明的所謂的所謂的“需求需求”。 需求評審也為風(fēng)險承擔(dān)者們提供了在特定需求評審也為風(fēng)險承擔(dān)者們提供了在特定問題上達(dá)成共識的方法。問題上達(dá)成共識的方法。需

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

12、評審小組的成員對評審的質(zhì)量負(fù)責(zé)，而開發(fā)者則最終對他的成員對評審的質(zhì)量負(fù)責(zé)，而開發(fā)者則最終對他們所開發(fā)的產(chǎn)品的質(zhì)量負(fù)責(zé)。們所開發(fā)的產(chǎn)品的質(zhì)量負(fù)責(zé)。 如果你對提高軟件的質(zhì)量持有認(rèn)真的態(tài)度，那么如果你對提高軟件的質(zhì)量持有認(rèn)真的態(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需求審查過程需求審查過程參與者參與者產(chǎn)品的開發(fā)者及其可能的同組成員產(chǎn)品的開發(fā)者及其可能的同組成員編寫需求文檔編寫需求文檔的分析員提供這方面觀點。的分析員提供這方面觀點。先前產(chǎn)品的開發(fā)者或正在評審的項目的規(guī)格說明編寫先前產(chǎn)品的開發(fā)者或正在評審的項目的規(guī)格說明編寫者。者。要根據(jù)正在審查的文檔來開展工作的人們要根據(jù)正在審查的文檔來開展工作的人們-對于一個對于一個軟件需求規(guī)格說明，你可能需要包括一個開發(fā)人員、軟件需求規(guī)格說明，你可能需要包括一個開發(fā)人員、一個測試人員

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

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

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

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

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

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

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

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

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

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

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

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