需求驗(yàn)證的方法及特點(diǎn)課件

1、 第五章需 求 驗(yàn) 證金陵科技學(xué)院 軟件工程學(xué)院 目 錄5.1 需求的驗(yàn)證及過程5.2 需求驗(yàn)證的方法及特點(diǎn)5.2 需求驗(yàn)證的方法及特點(diǎn) 5.2.1 需求評(píng)審1.正式與非正式技術(shù)評(píng)審2.需求審查過程3.進(jìn)入和退出審查的標(biāo)準(zhǔn)4.需求審查清單5.需求評(píng)審的困難5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審1.正式與非正式技術(shù)評(píng)審非正式評(píng)審的方法包括把工作產(chǎn)品分發(fā)給許多其它的開發(fā)人員粗略看一看，走過場(chǎng)似地檢查一遍。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審1.正式與非正式技術(shù)評(píng)審正式技術(shù)評(píng)審，叫作審查（inspection）（Ebenau and Strauss 1994; Gilb andGraham

2、 1993）。正式評(píng)審內(nèi)容需要。正式評(píng)審小組的成員對(duì)評(píng)審的質(zhì)量負(fù)責(zé)，而開發(fā)者則最終對(duì)他們所開發(fā)的產(chǎn)品的質(zhì)量負(fù)責(zé)。如果認(rèn)為沒有時(shí)間詳細(xì)審查每個(gè)方面，那么可以使用簡(jiǎn)單的風(fēng)險(xiǎn)分析模型，來區(qū)分需求文檔哪些部分是需要詳細(xì)審查的，哪些不重要部分只要用非正式評(píng)審就能滿足質(zhì)量要求。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審2.需求審查過程參與評(píng)審的人員參與評(píng)審的人員，包括產(chǎn)品的開發(fā)者，以及可能的同組成員，包括先前產(chǎn)品的開發(fā)者或正在評(píng)審的項(xiàng)目的規(guī)格說明編寫者，包括要根據(jù)正在審查的文檔來開展工作的人們。很可能參與評(píng)審的人員包括一個(gè)開發(fā)人員、一個(gè)測(cè)試人員、一個(gè)項(xiàng)目經(jīng)理和一個(gè)用戶文檔編寫人員。他們的工作基礎(chǔ)都是軟件需

3、求規(guī)格說明。這些審查人員將會(huì)發(fā)現(xiàn)不同類型的問題。審查組中的審查人員應(yīng)限制在7個(gè)人左右或者更少。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審2.需求審查過程審查每個(gè)成員扮演的角色 作者：作者創(chuàng)建或維護(hù)正在被審查的產(chǎn)品。 調(diào)解者：調(diào)解者（moderator）或者審查主持者所做的是與作者一起為審查制訂計(jì)劃協(xié)調(diào)各種活動(dòng)，并且推進(jìn)審查會(huì)的進(jìn)行。 讀者：讀者的角色由審查員扮演。 記錄員：記錄員或書記員用標(biāo)準(zhǔn)化的形式記錄在審查會(huì)中提出的問題和缺陷。記錄員必須仔細(xì)審查所寫的材料以確保記錄的正確性。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審2.需求審查過程評(píng)審過程 規(guī)劃（Planning）：作者和調(diào)解者協(xié)同對(duì)審查

4、進(jìn)行規(guī)劃，以決定誰該參加審查，審查員在召開審查會(huì)之前應(yīng)收到什么材料并且需要召開幾次審查會(huì)。 總體會(huì)議（overview meeting）：總體會(huì)議可以為審查員提供了解會(huì)議的信息，包括他們要審查的材料的背景，作者所作的假設(shè)和作者的特定審查目標(biāo)。 5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審2.需求審查過程評(píng)審過程 準(zhǔn)備（Preparation）：在正式審查的準(zhǔn)備階段，每個(gè)審查員以典型缺陷為清單，檢查產(chǎn)品可能出現(xiàn)的錯(cuò)誤并提出問題。審查會(huì)議（Inspection meeting）：在審查會(huì)進(jìn)行過程中，讀者通過軟件需求規(guī)格說明指導(dǎo)審查小組一次解釋一個(gè)需求。當(dāng)審查員提出可能的錯(cuò)誤或其它問題時(shí)記錄員就記錄這

5、些內(nèi)容，其形式可以成為需求作者的工作項(xiàng)列表。會(huì)議的目的是盡可能多地發(fā)現(xiàn)需求規(guī)格說明中的重大缺陷。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審2.需求審查過程 重寫(rework):幾乎每一個(gè)質(zhì)量控制活動(dòng)都可能發(fā)現(xiàn)一些需求缺陷。因此作者必須在審查會(huì)之后安排一段時(shí)間重寫文檔。 重審(follow-up):這是審查工作的最后一步調(diào)解者或指派人單獨(dú)重審由作者重寫的需求規(guī)格說明。重審確保了所有提出的問題都能得到解決，并且正確修改了需求的錯(cuò)誤。重審結(jié)束了審查的全過程，并且可以使調(diào)解者做出判斷是否已滿足審查的退出標(biāo)準(zhǔn)。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審3.進(jìn)入和退出審查的標(biāo)準(zhǔn)一般，需求文檔進(jìn)入審查的標(biāo)

6、準(zhǔn)有：文檔符合標(biāo)準(zhǔn)模板，文檔已經(jīng)做過拼寫檢查和語法檢查，作者已經(jīng)檢查了文檔在版面安排上所存在的錯(cuò)誤，已經(jīng)獲得了審查員所需要的先前或參考文檔，例如系統(tǒng)需求規(guī)格說明，在文檔中打印了行序號(hào)以方便在審查中對(duì)特定位置的查閱，所有未解決的問題都被標(biāo)記為TBD待確定，包括文檔中使用到的術(shù)語詞匯表。一般，需求文檔退出審查的標(biāo)準(zhǔn)有：已經(jīng)明確闡述了審查員提出的所有問題，已經(jīng)正確修改了文檔，修訂過的文檔已經(jīng)進(jìn)行了拼寫檢查和語法檢查，所有TBD的問題已經(jīng)全部解決或者已經(jīng)記錄下每個(gè)待確定問題的解決過程、目標(biāo)、日期和提出問題的人，文檔已經(jīng)登記入項(xiàng)目的配置管理系統(tǒng)，已將審查過的資料送到有關(guān)收集處5.2 需求驗(yàn)證的方法5.2

7、.1 需求評(píng)審4.需求審查清單（對(duì)應(yīng)圖片模糊化處理，不用看到上面具體內(nèi)容） 為了使審查員警惕審查的產(chǎn)品中的習(xí)慣性錯(cuò)誤，需對(duì)所創(chuàng)建的每一類型的需求文檔建立一份清單。清單可以提醒審查員以前經(jīng)常發(fā)生的需求問題。5.2 需求驗(yàn)證的方法5.2.1 需求評(píng)審5.需求評(píng)審的困難需求評(píng)審可能存在各種困難。大型的需求文檔，需要龐大的審查小組，需要確保每個(gè)參與者都是為了尋找錯(cuò)誤，而不是為了解軟件需求規(guī)格說明中的內(nèi)容，或者為了維護(hù)行政上的位置。需要理解審查員如客戶、開發(fā)者或測(cè)試者所代表的觀點(diǎn)，并且委婉地拒絕以相同的觀點(diǎn)看待問題的參與者。需要把審查組分成若干小組并行地審查軟件需求規(guī)格說明，并把發(fā)現(xiàn)的錯(cuò)誤集中起來，剔除

8、重復(fù)的部分。有時(shí)審查員在地域上的分散，也造成需求評(píng)審的困難。5.2 需求驗(yàn)證的方法5.2.2 原型法首先，確定合適原型，準(zhǔn)備需求驗(yàn)證。接著，將需求驗(yàn)證涉及的復(fù)雜過程或場(chǎng)景定義出來，以輔助需求驗(yàn)證過程的開展。最后，根據(jù)已定義過程和場(chǎng)景，按照原型執(zhí)行過程，發(fā)現(xiàn)需求的缺陷、問題并記錄，以待后續(xù)修正。5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例：“Android點(diǎn)餐系統(tǒng)”的開發(fā)組是如何使用用戶場(chǎng)景分析法，把“點(diǎn)餐下單”功能的需求規(guī)格說明、分析模型和早期創(chuàng)建的測(cè)試用例結(jié)合在一起的5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例：“Android點(diǎn)餐系統(tǒng)”的開發(fā)組是如何使用

9、用戶場(chǎng)景分析法，把“點(diǎn)餐下單”功能的需求規(guī)格說明、分析模型和早期創(chuàng)建的測(cè)試用例結(jié)合在一起的。1）需求規(guī)格說明文檔中這樣描述：用戶打開Android點(diǎn)餐系統(tǒng)客戶端，登錄帳號(hào)后進(jìn)行網(wǎng)上點(diǎn)餐，選擇菜品、座位，確定后提交訂單，下單完成。5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)2）分析模型：例如，建模用戶點(diǎn)餐下單順序圖，如圖5.2.1：5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例3）用戶場(chǎng)景描述：第一步:確定基本流和備選流基本流:用戶打開客戶端登錄帳號(hào)選擇菜品選擇座位選擇菜品數(shù)量下單生成訂單備選流1：賬戶不存在；備選流2：賬戶密碼錯(cuò)誤；備選流3：座位已滿； 備選流4：菜品數(shù)量不足

10、； 備選流5：菜品已賣完；5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例3）用戶場(chǎng)景描述：第二步:根據(jù)基本流和備選流確定場(chǎng)景場(chǎng)景1 成功下單：基本流；場(chǎng)景2 帳號(hào)不存在：基本流，備選流1；場(chǎng)景3 帳號(hào)密碼錯(cuò)誤：基本流，備選流2； 場(chǎng)景4座位已滿：基本流，備選流3；場(chǎng)景5菜品數(shù)量不足：基本流，備選流4；場(chǎng)景6菜品已賣完：基本流，備選流5； 5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例3）用戶場(chǎng)景描述：第三步：對(duì)每個(gè)場(chǎng)景生成相應(yīng)的測(cè)試用例對(duì)于這6個(gè)場(chǎng)景中的每一個(gè)場(chǎng)景都需要確定測(cè)試用例?？梢圆捎镁仃嚮驔Q策表來確定和管理測(cè)試用例。下面是一種通用格式，其中各行代表各個(gè)測(cè)

11、試用例，各列代表測(cè)試用例的信息。本示例中，對(duì)于每個(gè)測(cè)試用例，存在一個(gè)測(cè)試用例ID、條件（或說明）、測(cè)試用例中涉及的所有數(shù)據(jù)元素（作為輸入或已經(jīng)存在于數(shù)據(jù)庫(kù)中）以及預(yù)期結(jié)果，如表5.2.1所示。 5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例3）用戶場(chǎng)景描述：第三步：對(duì)每個(gè)場(chǎng)景生成相應(yīng)的測(cè)試用例測(cè)試用例ID場(chǎng)景/條件帳號(hào)密碼座位可選數(shù)量菜品數(shù)量預(yù)期結(jié)果1場(chǎng)景1：成功下單VVVV下單成功2場(chǎng)景2：帳號(hào)不存在1n/an/an/a提示帳號(hào)不存在3場(chǎng)景3：帳號(hào)密碼錯(cuò)誤（帳號(hào)正確，密碼錯(cuò)誤）V1n/an/a提示帳號(hào)密碼錯(cuò)誤，返回基本流步驟24場(chǎng)景4：座位已滿vv1n/a提示座位已滿5場(chǎng)景5

12、：菜品數(shù)量不足vv1n/a提示菜品數(shù)量不足，顯示剩余量6場(chǎng)景6： 菜品已賣完vvv1提示菜品已賣完，請(qǐng)選擇其他菜品5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例3）用戶場(chǎng)景描述：第四步：設(shè)計(jì)測(cè)試數(shù)據(jù)一旦確定了所有的測(cè)試用例，則應(yīng)對(duì)這些用例進(jìn)行復(fù)審和驗(yàn)證以確保其準(zhǔn)確且適度，并取消多余或等效的測(cè)試用例。測(cè)試用例一經(jīng)認(rèn)可，就可以確定實(shí)際數(shù)據(jù)值（在測(cè)試用例實(shí)施矩陣中）并且設(shè)定測(cè)試數(shù)據(jù)，如表5.2.2所示 5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)1.需求測(cè)試舉例3）用戶場(chǎng)景描述：第四步：設(shè)計(jì)測(cè)試數(shù)據(jù)測(cè)試用例ID場(chǎng)景/條件帳號(hào)密碼座位可選數(shù)量菜品數(shù)量預(yù)期結(jié)果實(shí)際結(jié)果XD1場(chǎng)景1：成功

13、下單Test001111112010下單成功，座位可選減少一位，菜品可點(diǎn)數(shù)量減少3份下單成功，座位可選減少一位，菜品可點(diǎn)數(shù)量減少3份XD2場(chǎng)景2：帳號(hào)不存在Testn/an/an/a提示帳號(hào)不存在提示帳號(hào)不存在XD3場(chǎng)景3：帳號(hào)密碼錯(cuò)誤（帳號(hào)正確，密碼錯(cuò)誤）Test00123456n/an/a提示帳號(hào)密碼錯(cuò)誤，返回基本流步驟2提示帳號(hào)密碼錯(cuò)誤，返回基本流步驟2XD4場(chǎng)景4：座位已滿Test001111110n/a提示座位已滿座位不可選XD5場(chǎng)景5：菜品數(shù)量不足Test00111111101提示菜品數(shù)量不足，顯示剩余量顯示菜品數(shù)量，不能輸入大于菜品剩余量的數(shù)字XD6場(chǎng)景6： 菜品已賣完Test0

14、0111111100提示菜品已賣完，請(qǐng)選擇其他菜品顯示菜品數(shù)量為0，不能輸入菜品數(shù)量5.2 需求驗(yàn)證的方法5.2.3 測(cè)試用例開發(fā)通過測(cè)試用例，可以驗(yàn)證需求，并發(fā)現(xiàn)需求的缺陷和問題。 5.2 需求驗(yàn)證的方法5.2.4 編制用戶手冊(cè)一般情況下，用戶手冊(cè)是在系統(tǒng)實(shí)現(xiàn)完成準(zhǔn)備交付用戶使用前編寫，是為了幫助用戶更好地使用系統(tǒng)，解決可能由于系統(tǒng)環(huán)境、配置、安裝、功能操作不熟悉等原因帶來的問題。但是，如果采用編制用戶手冊(cè)的方法來驗(yàn)證需求，則用戶手冊(cè)編制的工作可以在需求工程階段就開始。5.2 需求驗(yàn)證的方法5.2.5 需求跟蹤需求的發(fā)展是有前后聯(lián)系的，需求之間具有可跟蹤關(guān)系。如果根據(jù)系統(tǒng)需求，不能找到前項(xiàng)用

15、戶需求和前項(xiàng)業(yè)務(wù)需求，那么，跟蹤關(guān)系不存在，也就說明了該系統(tǒng)需求屬于非必要需求，或者也可能發(fā)現(xiàn)該系統(tǒng)需求根本沒存在的必要。同理，如果業(yè)務(wù)需求不能發(fā)現(xiàn)后項(xiàng)用戶需求或后項(xiàng)系統(tǒng)需求的跟蹤關(guān)系，那么說明該業(yè)務(wù)需求在需求逐步細(xì)化的過程中丟失了，也就發(fā)現(xiàn)了軟件需求規(guī)格說明書的不完整性。5.2 需求驗(yàn)證的方法5.2.6 自動(dòng)化分析自動(dòng)化分析方法，一般采用形式化語言檢查軟件需求規(guī)格說明書存在的問題。但是由于形式化語言本身對(duì)客戶具有難理解的特性，所以使用較少，到目前為止，還沒有自動(dòng)化需求驗(yàn)證方法，也沒有成熟的、識(shí)別并診斷與需求不符的錯(cuò)誤數(shù)據(jù)的方法。如果軟件需求規(guī)格說明書的問題、缺陷、漏洞、不完整性、不統(tǒng)一性等諸

16、多問題，可以被自動(dòng)分析后發(fā)現(xiàn)，對(duì)于人類在需求工程期間的任務(wù)將是一個(gè)巨大的進(jìn)步。目前有研究者在這方面努力，以期取得較好的效果。例如已經(jīng)有一些自動(dòng)化工具和系統(tǒng)化方法能部分支持需求定義內(nèi)在的一致性和完備性檢查 , 使得軟件需求的質(zhì)量在一定程度上得到了保證, 但需求定義是否準(zhǔn)確地反映用戶需求的驗(yàn)證在目前還主要依賴于文檔評(píng)審和原型示范等技術(shù), 缺乏行之有效的系統(tǒng)化方法。5.2 需求驗(yàn)證的方法5.2.7其他方法目前研究需求驗(yàn)證的其他方法也有一些。有博士論文研究網(wǎng)絡(luò)式軟件需求驗(yàn)證的形式化方法，能有效的刻畫用戶需求的功能屬性和非功能屬性，有利于提高需求分析階段的正確性和完整性，降低軟件中因?yàn)橛脩粜枨蟮牟徽_而帶來的錯(cuò)誤以及資源的損失，提高軟件開發(fā)的效率。有論文提出一個(gè)支持需求驗(yàn)證的過程模型(RVPM), 進(jìn)行形式化描述, 并論述了需求驗(yàn)證過程的幾個(gè)關(guān)鍵過程和策略。有基于有向