軟件需求工程 課件 第8章 需求驗(yàn)證

第8章需求驗(yàn)證

目錄需求驗(yàn)證的目的和任務(wù)需求驗(yàn)證的內(nèi)容和方法需求評(píng)審需求可視化8-18-28-38-48-58-68-7編制用戶使用手冊(cè)草案解釋需求模型需求測(cè)試8-1需求驗(yàn)證的目的和任務(wù)需求驗(yàn)證包含的活動(dòng)需求驗(yàn)證的目的：確保需求規(guī)格說明具有良好的特性（如完整性，正確性等）。軟件需求規(guī)格證明是否正確描述了目標(biāo)系統(tǒng)的行為和特征；從其它來源中（包括硬件的系統(tǒng)需求規(guī)格說明書）得到軟件需求；需求是完整的和高質(zhì)量的；所有人對(duì)需求的看法是一致的；需求驗(yàn)證的任務(wù)：要求各方人員從不同的技術(shù)角度對(duì)需求規(guī)格說明文檔做出綜合性評(píng)價(jià)。在收集需求并且編寫成需求規(guī)格說明文檔后進(jìn)行需求驗(yàn)證并不僅是一個(gè)獨(dú)立的階段,而且某些驗(yàn)證活動(dòng),如對(duì)漸增式軟件需求規(guī)格說明的評(píng)審工作,將在需求獲取、分析和定義需求規(guī)格說明的整個(gè)過程中反復(fù)進(jìn)行。8-1需求驗(yàn)證的目的和任務(wù)8-2需求驗(yàn)證的內(nèi)容和方法為了確保軟件開發(fā)成功和降低開發(fā)成本,就必須嚴(yán)格驗(yàn)證軟件需求。一般來說,應(yīng)該從下述4個(gè)方面進(jìn)行驗(yàn)證：1.一致性2.完整性3.現(xiàn)實(shí)性4.有效性

一般還可根據(jù)軟件系統(tǒng)的特點(diǎn)和用戶的要求(如嵌入式系統(tǒng)等)增加一些檢驗(yàn)內(nèi)容，如軟件的可信特性，即安全性、可靠性、正確性以及系統(tǒng)的活性等。8-2需求驗(yàn)證的內(nèi)容和方法需求驗(yàn)證的內(nèi)容需求驗(yàn)證的方法目前驗(yàn)證需求的方法除形式化方法外，主要靠人工技術(shù)審查和驗(yàn)證軟件需求規(guī)格說明。8-3需求評(píng)審需求評(píng)審就是技術(shù)評(píng)審，由非軟件開發(fā)人員對(duì)軟件系統(tǒng)的進(jìn)行檢查以發(fā)現(xiàn)該系統(tǒng)所存在的問題。技術(shù)評(píng)審又可根據(jù)評(píng)審的方法劃分為以下兩處：1.非正式評(píng)審：由開發(fā)人員描述產(chǎn)品并征求意見，包括把工作產(chǎn)品分發(fā)給許多其他有關(guān)人員粗略地看一看或走過場(chǎng)地檢查。非正式評(píng)審的好處是能培養(yǎng)其他人對(duì)產(chǎn)品的認(rèn)識(shí)，并可獲得一些非結(jié)構(gòu)化的反饋信息。它的不足之處是不夠系統(tǒng)化和不徹底，或者在實(shí)施過程中不具有一致性，并且該評(píng)審不需要記錄,完全可以根據(jù)個(gè)人愛好進(jìn)行。2.正式評(píng)審：是正式技術(shù)評(píng)審中最好的類型，應(yīng)該包含一個(gè)由不同背景的審查人員組成的小組。這些審查人員首先閱讀需求規(guī)格說明文檔,把其中的問題記錄下來,然后轉(zhuǎn)送給軟件開發(fā)人員。正式評(píng)審有正規(guī)的審查過程，審查人員有嚴(yán)格的分工和職責(zé)。8-3需求評(píng)審需求評(píng)審的定義8-3-1審查人員的確定和分工正式評(píng)審中,應(yīng)由具有不同背景的人組成一個(gè)小組對(duì)需求規(guī)格說明文檔進(jìn)行評(píng)審。為提高審查的有效性，審查人員必須由如下4個(gè)方面的人組成：1.從事軟件系統(tǒng)需求開發(fā)的相關(guān)人員。2.具有編寫需求規(guī)格說明經(jīng)驗(yàn)和知識(shí)的人員，以及具有評(píng)審工作經(jīng)驗(yàn)的領(lǐng)域?qū)＜业取?.客戶或同戶代表，他們可以保證需求規(guī)格說明能正確地和完整的描述他們的需求。4.將依據(jù)需求規(guī)格說明開展工作的軟件開發(fā)人員，如設(shè)計(jì)人員，測(cè)試人員，項(xiàng)目經(jīng)理等。審查人員在審查中所起的作用可分類如下:1.作者，這些人通常為系統(tǒng)分析員。2.調(diào)解員，通常為項(xiàng)目總負(fù)責(zé)人。3.讀者，主要由審查人員扮演。4.記錄員。8-3需求評(píng)審審查過程中每個(gè)步驟的工作內(nèi)容簡(jiǎn)要說明如下。首先,在進(jìn)入籌備階段之前,調(diào)解員可建立一些進(jìn)入審查的標(biāo)準(zhǔn),根據(jù)這些標(biāo)準(zhǔn)判斷能否進(jìn)行正式審查。建立這些標(biāo)準(zhǔn)需根據(jù)項(xiàng)目的實(shí)際情況決定。例如,下面是一些關(guān)于需求規(guī)格說明文檔進(jìn)入審查的參考標(biāo)準(zhǔn)：文檔符合標(biāo)準(zhǔn)模板。文檔已經(jīng)過拼寫檢查和語法檢查。作者已經(jīng)檢查了文檔在版面安排上所存在的錯(cuò)誤。所有未解決的問題都已做出標(biāo)記(待確定)。包括了文檔中使用到的術(shù)語詞匯表。當(dāng)軟件需求規(guī)格說明文檔滿足審查標(biāo)準(zhǔn)時(shí)，就可決定進(jìn)入正式審查的籌備階段。如右圖所示：8-3-2正式的審查過程8-3需求評(píng)審需求評(píng)審的工作：評(píng)審需求規(guī)格說明的內(nèi)容。通常，問題審查清單列舉的問題可考慮如下：1）需求是否完整？即評(píng)審人員是否知道有任何遺漏的需求或在單個(gè)需求措施中有無遺漏的信息。2）需求是否一致？即不同的需求間是否存在沖突，特別是不同層次間的需求如目標(biāo)需求與功能或性能需求是否一致。3）需求是否可理解？即所有文檔的讀者是否理解需求的意思。4）需求是否明確？即該需求是否有不同的解釋。5）需求是否可實(shí)現(xiàn)？即該需求的實(shí)現(xiàn)會(huì)給開發(fā)工作帶來什么樣的技術(shù)風(fēng)險(xiǎn)等。6）需求是否可跟蹤？即一個(gè)需求是否包含或涉及其他相關(guān)需求，以及這些需求為什么會(huì)被包含或被涉及。7）需求是否易于修改？即軟件需求將來需進(jìn)行增加或修改時(shí)，是否會(huì)引起一系列變動(dòng)等。8）需求規(guī)格說明文檔是否完整?即文檔是否符合某一標(biāo)準(zhǔn),如國(guó)家、軍隊(duì)或公司內(nèi)8-3-3審查的內(nèi)容8-3需求評(píng)審需求評(píng)審工作也面臨著許多困難，一些常見的困難說明如下：開發(fā)人員最重要的是后面的開發(fā)工作，從而導(dǎo)致需求評(píng)審成為“走過場(chǎng)”;需求評(píng)審的工作量大,對(duì)于一個(gè)大型的復(fù)雜系統(tǒng)，其需求規(guī)格說明往往有幾百頁，要審查這樣的需求規(guī)格說明是十分可怕的。過大的評(píng)審小組。同一個(gè)用戶界面的設(shè)計(jì)，不同的人就有不同的看法，導(dǎo)致意見不一致。對(duì)于上述這些困難，往往要根據(jù)實(shí)際情況給予解決。例如，可在強(qiáng)調(diào)評(píng)審工作重要性的基礎(chǔ)上，采取解釋與說明的方式，采用多人分段審查的方式，以及采取分組方式等。8-3-4需求評(píng)審面臨的困難8-3需求評(píng)審8-4需求測(cè)試8-4需求測(cè)試為需求設(shè)計(jì)測(cè)試用例可以確認(rèn)需求而不能確認(rèn)系統(tǒng)。即使沒有對(duì)實(shí)際系統(tǒng)使用測(cè)試用例,但通過設(shè)計(jì)測(cè)試用例就可以解釋需求的許多問題,如果在部分需求穩(wěn)定時(shí)就開始設(shè)計(jì)測(cè)試用例,則可以及早發(fā)現(xiàn)問題,并以較少的費(fèi)用解決這些問題。需求測(cè)試可以使用如下方法：1.以功能需求為基礎(chǔ)，視其為黑盒子，編寫關(guān)于該功能或黑盒子的測(cè)試用例。2.這些用例可以明確在特定條件下運(yùn)行的任務(wù)。由于無法描述系統(tǒng)的響應(yīng),故測(cè)試中將會(huì)發(fā)現(xiàn)一些模糊的和二義性的需求。需求測(cè)試的方法

定義測(cè)試用例為了定義測(cè)試用例，可以通過提問的方式，比如：1）什么樣的用例可以用來檢查需求？這定義了測(cè)試用例將從何處來。2）需求本身包含的信息足夠定義一個(gè)測(cè)試用例嗎？如果不是，那么為找到其他的信息還需檢查哪些其他需求;如果是的話,則表明需求間可能存在依賴性。這對(duì)于可跟蹤性來說是重要的。3）可以用一個(gè)測(cè)試用例檢查需求嗎？還是需要若干個(gè)測(cè)試用例？如果需要多個(gè)測(cè)試用例，則意味著一個(gè)需求描述中包含多個(gè)要求。8-4需求測(cè)試8-5編制用戶使用手冊(cè)草案8-5編制用戶使用手冊(cè)草案編制用戶使用手冊(cè)的好處在編制該手冊(cè)的過程中，可強(qiáng)化對(duì)需求的仔細(xì)分析，幫助揭示與系統(tǒng)的實(shí)際使用相關(guān)的問題，即系統(tǒng)的可用性問題未被掩蓋?？梢詭椭U明用戶界面設(shè)計(jì)問題，從而促使軟件開發(fā)人員一開始就站在用戶的角度來設(shè)計(jì)用戶界面，并及早考慮人-機(jī)交互中的接口問題。編制用戶使用手冊(cè)的要求在編制用戶使用手冊(cè)草案時(shí)應(yīng)以最終用戶能理解的方式解釋在需求中描述的系統(tǒng)功能，應(yīng)盡可能采用用戶能理解的術(shù)語書寫要描述的功能，并告訴他們應(yīng)該怎樣使用這些功能。需求文檔上述的需求驗(yàn)證（包括形式化方法）完成后，由開發(fā)人員與用戶（或需求方）雙方共同簽署軟件需求規(guī)格說明文檔，這個(gè)文檔定義了軟件開發(fā)的基準(zhǔn)需求。8-6解釋需求模型8-6解釋需求模型用自然語言解釋需求模型的好處通常需求模型(或分析模型)是用圖形或形式化語言和符號(hào)表示的。用自然語言解釋需求模型的好處：有利于評(píng)審人員理解和評(píng)審需求規(guī)格說明；有助于發(fā)現(xiàn)模型中的一些錯(cuò)誤。在用自然語言解釋解釋者來說，他們不用盡力說明模型或者提供理由，但他們要熟悉被說明系統(tǒng)的類型；應(yīng)避免語言的生硬和呆板,特別是不能把不存在的信息加入需求模型中。8-7需求可視化8-7需求可視化軟件需求驗(yàn)證的問題形式化驗(yàn)證方法的好處是嚴(yán)格和自動(dòng)化,能夠高效地獲得可靠的驗(yàn)證結(jié)果。非形式化方法或人工方法一般直觀性較好而且簡(jiǎn)單,易于被開發(fā)人員掌握和操作,便于用戶參與驗(yàn)證過程。但由于參與者的主觀性,導(dǎo)致驗(yàn)證過程不夠嚴(yán)密且隨意性較大,難以保證驗(yàn)證結(jié)果的正確性和完整性需求可視化的定義需求可視化指使用圖形，圖像或者圖片等技術(shù)，使一些不可見的對(duì)象、表達(dá)或者抽象概念變成可見的符號(hào)。靜態(tài)表示需求模型又可具體歸納為以下幾種方式：列表可視化：使用表格方式來描述需求信息，以輔助需求獲取和需求描述等工作。關(guān)系可視化：使用一組節(jié)點(diǎn)符號(hào)以及關(guān)系連線表示組件或系統(tǒng)之間的關(guān)系。序列可視化:

使用可視化技術(shù)表達(dá)系統(tǒng)之間,或者用戶和系統(tǒng)之間的操作順序,這部分工作和傳統(tǒng)的流程圖、狀態(tài)圖等類似。層次可視化：用于表達(dá)系統(tǒng)、系統(tǒng)部件間的層次分解關(guān)系，典型的方式是基于目標(biāo)的建模方法。定量（quantitative）分析可視化：使用餅狀圖、柱狀圖及不同顏色和形狀等符號(hào)表示需求中的相關(guān)數(shù)據(jù)、程度等。8-7需求可視化靜態(tài)表示需求模型可視化的研究從表達(dá)技術(shù)和表達(dá)內(nèi)容上大致綜合為兩類：一類是利用各種圖形符號(hào)靜態(tài)地表示需求模型,一類是使用動(dòng)態(tài)的需求動(dòng)畫(requirementanimation)動(dòng)態(tài)地表示需求模型。需求動(dòng)畫利用圖形符號(hào)的動(dòng)態(tài)變化來展示需求模型中的動(dòng)態(tài)內(nèi)容,模擬目標(biāo)軟件的執(zhí)行過程，有益于用戶更好地理解和驗(yàn)證需求模型。表達(dá)系統(tǒng)的動(dòng)態(tài)行為，即利用圖形符號(hào)或圖像動(dòng)態(tài)地表示需求模型中的動(dòng)態(tài)行為。很多研究工作嘗試為不同的需求建模方法以及工具提供需求動(dòng)畫功能，這些工具按其自動(dòng)化程度可粗略歸納為如下兩類:一部分工具的動(dòng)畫生產(chǎn)過程自動(dòng)化程度較高。另一部分工具是使用現(xiàn)實(shí)世界的圖形和圖像作為動(dòng)畫執(zhí)行元素，用需求模型來驅(qū)動(dòng)這些動(dòng)畫元素的執(zhí)行。這些工具生成的動(dòng)畫便于非專業(yè)的用戶理解,能夠很好地促進(jìn)用戶和開發(fā)人員的交流。8-7需求可視化動(dòng)態(tài)表示需求模型綜上所述，基于需求動(dòng)畫的需求檢驗(yàn)過程可歸納為圖8-2所示的過程。第1步是從用戶獲取原始需求信息，生成最初的需求文檔（或需求規(guī)格說明)；第2步是基于需求文檔建立需求模型；第3步是形式化驗(yàn)證需求模型的正確性；第4步是基于需求模型建立需求動(dòng)畫；第5步是向用戶演示需求動(dòng)畫，獲取用戶反饋信息。當(dāng)用戶提出修改意見后，重復(fù)第2一5步的過程。8-7需求可視化基于需求動(dòng)畫的需求檢驗(yàn)過程為了較好地發(fā)揮需求動(dòng)畫的作用，通過研究和分析現(xiàn)有的相關(guān)工作,總結(jié)出在實(shí)現(xiàn)需求動(dòng)畫的過程中需要注意如下幾點(diǎn)：1）為了使需求模型能與動(dòng)畫較好地銜接，在選擇需求建模方法和語言的同時(shí)，還需研