第06講軟件需求驗(yàn)證

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、且可以使調(diào)解者做出判斷：是否已滿足審查了審查的全過(guò)程并且可以使調(diào)解者做出判斷：是否已滿足審查的退出標(biāo)準(zhǔn)。的退出標(biāo)準(zhǔn)。需求審查過(guò)程需求審查過(guò)程進(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)做過(guò)拼寫(xiě)檢查和語(yǔ)法檢查。文檔已經(jīng)做過(guò)拼寫(xiě)檢查和語(yǔ)法檢查。作者已經(jīng)檢查了文檔在版面安排上所存在的錯(cuò)誤。作者已經(jīng)檢查了文檔在版面安排上所存在的錯(cuò)誤。已經(jīng)獲得了審查員所需要的先前或參考文檔，例已經(jīng)獲得了審查員所需要的先前或參考文檔，例如系統(tǒng)需求規(guī)格說(shuō)明。如系統(tǒng)需求規(guī)格說(shuō)明。在文檔中打印了行序號(hào)以方便在審查中對(duì)特定

20、位在文檔中打印了行序號(hào)以方便在審查中對(duì)特定位置的查閱。置的查閱。所有未解決的問(wèn)題都被標(biāo)記為所有未解決的問(wèn)題都被標(biāo)記為T(mén)BD（待確定）。（待確定）。包括了文檔中使用到的術(shù)語(yǔ)詞匯表。包括了文檔中使用到的術(shù)語(yǔ)詞匯表。需求審查過(guò)程需求審查過(guò)程進(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)明確闡述了審查員提出的所有問(wèn)題。已經(jīng)明確闡述了審查員提出的所有問(wèn)題。已經(jīng)正確修改了文檔。已經(jīng)正確修改了文檔。修訂過(guò)的文檔已經(jīng)進(jìn)行了拼寫(xiě)檢查和語(yǔ)法檢查。修訂過(guò)的文檔已經(jīng)進(jìn)行了拼寫(xiě)檢查和語(yǔ)法檢查。所有所有TBD的問(wèn)題已經(jīng)全部解決，或者已經(jīng)記錄下的問(wèn)題已經(jīng)全部解決，或者已

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

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

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

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

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