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

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

目錄需求驗(yàn)證的目的和任務(wù)需求驗(yàn)證的內(nèi)容和方法需求評(píng)審需求可視化8-18-28-38-48-58-68-7編制用戶使用手冊(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)人員粗略地看一看或走過場地檢查。非正式評(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ì)人員，測試人員，項(xiàng)目經(jīng)理等。審查人員在審查中所起的作用可分類如下:1.作者，這些人通常為系統(tǒng)分析員。2.調(diào)解員，通常為項(xiàng)目總負(fù)責(zé)人。3.讀者，主要由審查人員扮演。4.記錄員。8-3需求評(píng)審審查過程中每個(gè)步驟的工作內(nèi)容簡要說明如下。首先,在進(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),如國家、軍隊(duì)或公司內(nèi)8-3-3審查的內(nèi)容8-3需求評(píng)審需求評(píng)審工作也面臨著許多困難，一些常見的困難說明如下：開發(fā)人員最重要的是后面的開發(fā)工作，從而導(dǎo)致需求評(pí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需求測試8-4需求測試為需求設(shè)計(jì)測試用例可以確認(rèn)需求而不能確認(rèn)系統(tǒng)。即使沒有對(duì)實(shí)際系統(tǒng)使用測試用例,但通過設(shè)計(jì)測試用例就可以解釋需求的許多問題,如果在部分需求穩(wěn)定時(shí)就開始設(shè)計(jì)測試用例,則可以及早發(fā)現(xiàn)問題,并以較少的費(fèi)用解決這些問題。需求測試可以使用如下方法：1.以功能需求為基礎(chǔ)，視其為黑盒子，編寫關(guān)于該功能或黑盒子的測試用例。2.這些用例可以明確在特定條件下運(yùn)行的任務(wù)。由于無法描述系統(tǒng)的響應(yīng),故測試中將會(huì)發(fā)現(xiàn)一些模糊的和二義性的需求。需求測試的方法

定義測試用例為了定義測試用例，可以通過提問的方式，比如：1）什么樣的用例可以用來檢查需求？這定義了測試用例將從何處來。2）需求本身包含的信息足夠定義一個(gè)測試用例嗎？如果不是，那么為找到其他的信息還需檢查哪些其他需求;如果是的話,則表明需求間可能存在依賴性。這對(duì)于可跟蹤性來說是重要的。3）可以用一個(gè)測試用例檢查需求嗎？還是需要若干個(gè)測試用例？如果需要多個(gè)測試用例，則意味著一個(gè)需求描述中包含多個(gè)要求。8-4需求測試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é)果。非形式化方法或人工方法一般直觀性較好而且簡單,易于被開發(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í)，還需研究需求動(dòng)畫的特點(diǎn),使得該建模方法和語言既能獨(dú)立用于建模,又能用于描述動(dòng)畫執(zhí)行所需要的關(guān)鍵信息，增強(qiáng)需求模型和動(dòng)畫描述模型（用于控制動(dòng)畫實(shí)際運(yùn)行的模型)的同構(gòu)性。2）需求動(dòng)畫的自動(dòng)化程度是決定需求動(dòng)畫方法應(yīng)用推廣的關(guān)鍵因素，可能需要建立一套從需求模型到動(dòng)畫描述模型的轉(zhuǎn)換規(guī)則，提高轉(zhuǎn)換過程的自動(dòng)化程度，同時(shí)保證模型轉(zhuǎn)換的正確性。3）需求動(dòng)畫的目的：以直觀的方式向不同知識(shí)背景的用戶準(zhǔn)確地表達(dá)需求中的復(fù)雜行為。8-7需求可視化實(shí)現(xiàn)需求動(dòng)畫的關(guān)鍵點(diǎn)第9章需求管理需求管理的定義管理內(nèi)容所謂需求管理就是為有效地控制和管理需求更改等所進(jìn)行的一系列活動(dòng)。主要任務(wù)：開發(fā)人員在與提出更改的請(qǐng)求者（用戶）協(xié)商的基礎(chǔ)上，評(píng)估需求變更帶來的潛在影響及可能的成本及費(fèi)用；然后實(shí)施更改，以及有效地管理需求規(guī)格說明文檔和跟蹤更改需求的狀態(tài)。1）控制對(duì)基準(zhǔn)需求規(guī)格說明的變動(dòng)。2）保持項(xiàng)目計(jì)劃與需求一致。3）控制單個(gè)需求的更改和需求規(guī)格說明文檔的更改。4）管理需求和需求間的聯(lián)系，以及需求與設(shè)計(jì)和實(shí)現(xiàn)等方面的依賴關(guān)系。5）跟蹤需求更改的狀態(tài)，控制多個(gè)需求同時(shí)更改的復(fù)雜性。需求管理

目錄需求變更控制需求規(guī)格說明文檔的版本控制需求變更狀態(tài)的跟蹤需求跟蹤9-19-29-39-49-1需求變更控制9-1需求變更控制需求變更的內(nèi)容主要涉及兩個(gè)方面：一方面是需求變更只對(duì)軟件系統(tǒng)內(nèi)部產(chǎn)生影響,例如一個(gè)需求變更可能只影響某個(gè)功能需求，而不影響其他需求。另一方面是在原有軟件需求的基礎(chǔ)上提出擴(kuò)充軟件系統(tǒng)功能的需求，就是擴(kuò)展需求。1.控制項(xiàng)目范圍的擴(kuò)展變更控制策略與需求變更的過程和標(biāo)準(zhǔn)相關(guān)。這些策略描述了變更以何種形式提出、分析和處理。以下提供一些有用的和可供參考的策略：1）建立所有需求變更所應(yīng)遵循的過程（包括變更步驟）。按此過程，當(dāng)一個(gè)變更需求在過程中某一步被拒絕后，則其后的步驟將不再予以考慮。2)

對(duì)于未獲批準(zhǔn)的變更，除進(jìn)行可行性論證外，不應(yīng)再做其后的工作。3）對(duì)所提出的多個(gè)變更請(qǐng)求，應(yīng)由項(xiàng)目變更小組委員會(huì)決定實(shí)現(xiàn)哪些變更，以及先后次序。4）項(xiàng)目開發(fā)人員和用戶應(yīng)該能了解已變更需求的情況。5)

不準(zhǔn)隨意刪除和修改與需求變更請(qǐng)求和實(shí)現(xiàn)相關(guān)的原始文檔。6）每一個(gè)實(shí)施后的變更必須與一個(gè)經(jīng)核準(zhǔn)的變更請(qǐng)求相對(duì)應(yīng)。2.建立變更控制的策略9-1需求變更控制3.變更控制的步驟實(shí)施變更控制的步驟如圖9-1所示。此圖是用流程圖的形式來描述的。變更控制的步驟中，每步的工作任務(wù)明確，各步間是相互依賴的。各步的具體任務(wù)：1）變更控制的啟動(dòng)。啟動(dòng)的條件是通過合適的渠道接受一個(gè)合法的變更請(qǐng)求。2）確定角色與責(zé)任。3）影響分析與評(píng)估。評(píng)估變更請(qǐng)求的技術(shù)可行性、代價(jià)和資源限制等，提供對(duì)變更請(qǐng)求的準(zhǔn)確理解，幫助做出信息量充分的變更批準(zhǔn)決策。4）實(shí)施變更。當(dāng)需求變更請(qǐng)求被采納后，開始對(duì)涉及的軟件系統(tǒng)實(shí)施更新。5）驗(yàn)證。主要是通過檢查來確保更新后的需求規(guī)格說明的正確性。6）變更控制的結(jié)束。9-2需求規(guī)格說明文檔的版本控制軟件需求版本控制是需求管理的一個(gè)必要方面，也是容易忽視和出錯(cuò)的方面。需求規(guī)格說明的每一個(gè)版本必須統(tǒng)一確定，并保證開發(fā)人員必須知道和得到新的需求規(guī)格說明版本。為了有效地實(shí)施版本控制，可以遵循如下的版本控制策略:1）專人修改。2）版本應(yīng)該包括修改版本的歷史情況。3）根據(jù)修改工作量的大小手工標(biāo)記需求規(guī)格說明版本的每一次修改。4）每個(gè)版本的需求規(guī)格說明必須是獨(dú)立說明的，以避免新舊版本的混淆。9-2需求規(guī)格說明文檔的版本控制版本控制策略9-3需求變更狀態(tài)的跟蹤9-3需求變更狀態(tài)的跟蹤對(duì)于一個(gè)大型而復(fù)雜的軟件系統(tǒng)的需求規(guī)格說明，可能會(huì)面臨多個(gè)需求變更的情況。為了便于管理和控制需求變更，對(duì)于一個(gè)變更請(qǐng)求可用狀態(tài)圖來描述其在不同時(shí)間所處的狀態(tài)，以使各類人員知道更改的進(jìn)度。圖9-2表示一個(gè)需求變更請(qǐng)求所對(duì)應(yīng)的狀態(tài)圖，其中方框表示需求變更狀態(tài)。為了便于管理和控制需求變更，可建立一個(gè)如表9-1所示的數(shù)據(jù)庫或文件來記錄需求變更請(qǐng)求。需求變更請(qǐng)求狀態(tài)9-4需求跟蹤需求跟蹤的定義所謂需求跟蹤是指編制每個(gè)需求與系統(tǒng)元素之間聯(lián)系（即可跟蹤信息）的文檔，其中,系統(tǒng)元素包括:其他需求、體系結(jié)構(gòu)、設(shè)計(jì)部件、測試文檔等。9-4需求跟蹤9-4-1可跟蹤信息分類軟件需求與系統(tǒng)元素之間的聯(lián)系有很多，為簡單起見，此處根據(jù)需求系統(tǒng)元素之間聯(lián)系的類型把可跟蹤性信息粗略分為如下幾類:(1)需求—源可跟蹤性(2)需求—理由可跟蹤性(3)需求—需求可跟蹤性(4)需求—體系結(jié)構(gòu)可跟蹤性(5)需求—設(shè)計(jì)可跟蹤性(6)需求—用戶界面可跟蹤性9-4需求跟蹤9-4-2需求跟蹤技術(shù)有兩種技術(shù)可用于維護(hù)可跟蹤信息：需求跟蹤表和可跟蹤性表。需求跟蹤表（需求跟蹤能力矩陣）表示需求和系統(tǒng)元素之間聯(lián)系的最普遍的方式是使用需求跟蹤表。表9-2是一張有n個(gè)需求和m個(gè)系統(tǒng)元素的需求跟蹤表，需求沿水平方向給出，系統(tǒng)元素沿垂直方向給出，兩者之間的關(guān)系