《軟件需求工程》PPT課件.ppt

第六章 軟件需求驗證,周立新 博士 北京大學軟件與微電子學院,課程提綱,軟件需求基本理論和概念 軟件需求工程過程 軟件需求獲取 軟件需求分析 軟件需求規(guī)格說明 軟件需求驗證 軟件需求管理 軟件需求實現(xiàn) 軟件需求工程新進展 軟件需求開發(fā)與需求管理工具,內(nèi)容提要,軟件的質(zhì)量屬性分析 需求質(zhì)量驗證 需求評審 需求測試,1. 軟件的質(zhì)量屬性分析,軟件質(zhì)量屬性(或質(zhì)量因素)的特性是系統(tǒng)非功能（也叫非行為）部分的需求。這些特性包括： 產(chǎn)品的易用程度如何， 執(zhí)行速度如何， 可靠性如何， 當發(fā)生異常情況時，系統(tǒng)如何處理等。 質(zhì)量屬性區(qū)分： 一種屬性分類的方法是把在運行時可識別的特性與那些不可識別的特性區(qū)分開； 另一種方法是把對用戶很重要的可見特性與對開發(fā)者和維護者很重要的不可見特性區(qū)分開。 那些對開發(fā)者具有重要意義的屬性使產(chǎn)品易于更改、驗證，并易于移植到新的平臺上，從而可以間接地滿足客戶的需要。,軟件質(zhì)量屬性列表,對用戶最重要的屬性： 對開發(fā)者最重要的屬性： 可用性（availability） 可維護性( maintainability） 高效性( efficiency) 可移植性( portability ) 靈活性( flexibility ) 可重用性( reusability ) 完整性( integrity) 可測試性( testability ) 互操作性( interoperability ) 可靠性( reliability ) 健壯性( robustness ),Relationships among selected quality attributes,2. 需求質(zhì)量驗證,需求驗證是需求開發(fā)的第四部分（其余三個為獲取、分析和編寫規(guī)格說明），所包括的活動是為了確定以下幾方面的內(nèi)容： 軟件需求規(guī)格說明正確描述了預(yù)期的系統(tǒng)行為和特征。 從系統(tǒng)需求或其它來源中得到軟件需求。 需求是完整的和高質(zhì)量的。 所有對需求的看法是一致的。 需求為繼續(xù)進行產(chǎn)品設(shè)計、構(gòu)造和測試提供了足夠的基礎(chǔ)。,需求驗證確保了需求符合需求陳述（ requirement statement）的良好特征（完整的、正確的、靈活的、必要的、具有優(yōu)先級的、無二義性及可驗證的）并且符合需求規(guī)格說明的良好特性（完整的、一致的、易修改的、可跟蹤的）。當然，你只能驗證那些已編寫成文檔的需求，而那些存在于用戶或開發(fā)者思維中的沒有表露的、含蓄的需求則不予驗證。,需求質(zhì)量驗證,在收集需求并編寫成需求文檔后，你所進行的需求驗證并不僅僅是一個獨立的階段。一些驗證活動，例如對漸增型軟件需求規(guī)格說明的反復評審，將貫穿著反復獲取需求、分析和編寫規(guī)格說明的整個過程。其它的驗證步驟，例如軟件需求規(guī)格說明的正式審查，是在正式確定軟件需求規(guī)格說明基線之前對需求分析質(zhì)量進行的最后一次有用的質(zhì)量過濾。當你的項目計劃或?qū)嶋H工作中的獨立任務(wù)破壞了結(jié)構(gòu)性時，就要結(jié)合進行需求驗證活動，并且為隨后出現(xiàn)的返工預(yù)先安排一段時間，這通常會在質(zhì)量控制活動之后進行。,需求質(zhì)量驗證,有時，項目的參與者不愿意在評審和測試軟件需求規(guī)格說明上花費時間。雖然在計劃安排中插入一段時間來提高需求質(zhì)量似乎相應(yīng)地把交付日期延遲了一段時間，但是這種想法是建立在假設(shè)驗證需求上的投資將不產(chǎn)生效果的基礎(chǔ)上的。實際上，這種投資可以減少返工并加快系統(tǒng)測試，從而真正縮短了開發(fā)時間。,需求質(zhì)量驗證,Validation,Answer the question “Do I build the right thing?” Requirements validation is done either against real-world user needs or high level requirements specifications,Verification,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 procedures,需求評審,由一些非軟件開發(fā)人員進行產(chǎn)品檢查以發(fā)現(xiàn)產(chǎn)品所存在的問題，這就是技術(shù)評審。 需求文檔的評審是一項精益求精的技術(shù)，它可以發(fā)現(xiàn)那些二義性的或不確定的需求，那些由于定義不清而不能作為設(shè)計基礎(chǔ)的需求，還有那些實際上是設(shè)計規(guī)格說明的所謂的“需求”。 需求評審也為風險承擔者們提供了在特定問題上達成共識的方法。,需求評審方法,非正式評審的方法包括把工作產(chǎn)品分發(fā)給許多其它的開發(fā)人員粗略看一看和走過場似地檢查一遍（walkthrough）。 正式技術(shù)評審的最好類型叫作審查（Inspection）。正式評審內(nèi)容需要記錄在案，它包括確定材料、評審員、評審小組對產(chǎn)品是否完整或是否需要進一步工作的判定，以及對所發(fā)現(xiàn)的錯誤和所提出的問題的總結(jié)。正式評審小組的成員對評審的質(zhì)量負責，而開發(fā)者則最終對他們所開發(fā)的產(chǎn)品的質(zhì)量負責。 如果你對提高軟件的質(zhì)量持有認真的態(tài)度，那么就審查所編寫需求文檔的每一行。,Software Requirement Review,Informal review Peer desk check Pass around, such as through email Walk through Formal reviews Fagan inspection - used by many organization as an effective way to improve software quality,Peer Review,需求審查過程,參與者 產(chǎn)品的開發(fā)者及其可能的同組成員編寫需求文檔的分析員提供這方面觀點。 先前產(chǎn)品的開發(fā)者或正在評審的項目的規(guī)格說明編寫者。 要根據(jù)正在審查的文檔來開展工作的人們-對于一個軟件需求規(guī)格說明，你可能需要包括一個開發(fā)人員、一個測試人員、一個項目經(jīng)理和一個用戶文檔編寫人員，他們的工作基礎(chǔ)都是軟件需求規(guī)格說明。這些審查人員將會發(fā)現(xiàn)不同類型的問題。 審查組中的審查人員應(yīng)限制在7個人左右或者更少。,需求審查過程,審查中每個成員扮演的角色 作者。作者創(chuàng)建或維護正在被審查的產(chǎn)品。 調(diào)解者。調(diào)解者（moderator）或者審查主持者所做的是：與作者一起為審查制訂計劃，協(xié)調(diào)各種活動，并且推進審查會的進行。 讀者。讀者的角色由審查員扮演。 記錄員。記錄員，或書記員，用標準化的形式記錄在審查會中提出的問題和缺陷。記錄員必須仔細審查所寫的材料以確保記錄的正確性。,需求審查過程,審查階段 規(guī)劃（Planning）。作者和調(diào)解者協(xié)同對審查進行規(guī)劃，以決定誰該參加審查，審查員在召開審查會之前應(yīng)收到什么材料并且需要召開幾次審查會。 總體會議（overview meeting）?？傮w會議可以為審查員提供了解會議的信息，包括他們要審查的材料的背景，作者所作的假設(shè)和作者的特定審查目標。 準備（Preparation）。在正式審查的準備階段，每個審查員以典型缺陷（defect）清單（在本章的后面部分介紹）為指導，檢查產(chǎn)品可能出現(xiàn)的錯誤，并提出問題。,需求審查過程,審查階段 審查會議（Inspection meeting）。在審查會進行過程中，讀者通過軟件需求規(guī)格說明指導審查小組，一次解釋一個需求。當審查員提出可能的錯誤或其它問題時，記錄員就記錄這些內(nèi)容，其形式可以成為需求作者的工作項列表。會議的目的是盡可能多地發(fā)現(xiàn)需求規(guī)格說明中的重大缺陷。 重寫（rework）。我所觀察到的幾乎每一個質(zhì)量控制活動都可能發(fā)現(xiàn)一些需求缺陷。因此，作者必須在審查會之后，安排一段時間用于重寫文檔。 重審（follow-up）。這是審查工作的最后一步，調(diào)解者或指派人單獨重審由作者重寫的需求規(guī)格說明。重審確保了所有提出的問題都能得到解決，并且正確修改了需求的錯誤。重審結(jié)束了審查的全過程并且可以使調(diào)解者做出判斷：是否已滿足審查的退出標準。,需求審查過程,進入和退出審查的標準 一些關(guān)于需求文檔的進入審查的標準： 文檔符合標準模板。 文檔已經(jīng)做過拼寫檢查和語法檢查。 作者已經(jīng)檢查了文檔在版面安排上所存在的錯誤。 已經(jīng)獲得了審查員所需要的先前或參考文檔，例如系統(tǒng)需求規(guī)格說明。 在文檔中打印了行序號以方便在審查中對特定位置的查閱。 所有未解決的問題都被標記為TBD（待確定）。 包括了文檔中使用到的術(shù)語詞匯表。,需求審查過程,進入和退出審查的標準 一些關(guān)于需求文檔的退出標準： 已經(jīng)明確闡述了審查員提出的所有問題。 已經(jīng)正確修改了文檔。 修訂過的文檔已經(jīng)進行了拼寫檢查和語法檢查。 所有TBD的問題已經(jīng)全部解決，或者已經(jīng)記錄下每個待確定問題的解決過程，目標日期和提出問題的人。 文檔已經(jīng)登記入項目的配置管理系統(tǒng)。 檢查是否已將審查過的資料送到有關(guān)收集處。,需求審查過程,需求審查清單 為了使審查員警惕他們所審查的產(chǎn)品中的習慣性錯誤，對你的公司所創(chuàng)建的每一類型的需求文檔建立一份清單。 這些清單可以提醒審查員以前經(jīng)常發(fā)生的需求問題。,需求評審的困難,大型的需求文檔 龐大的審查小組 確保每個參與者都是為了尋找錯誤，而不是為了解軟件需求規(guī)格說明中的內(nèi)容或者為了維護行政上的位置。 理解審查員所代表的觀點（例如客戶、開發(fā)者或測試者），并且委婉地拒絕以相同的觀點看待問題的參與者。 把審查組分成若干小組并行地審查軟件需求規(guī)格說明，并把他們發(fā)現(xiàn)的錯誤集中起來，剔除重復的部分。 審查員在地域上的分散,需求測試,通過閱讀軟件需求規(guī)格說明，通常很難想像在特定環(huán)境下的系統(tǒng)行為。 以功能需求為基礎(chǔ)或者從使用實例派生出來的測試用例可以使項目參與者看清系統(tǒng)的行為。雖然沒有在運行系統(tǒng)上執(zhí)行測試用例，但是設(shè)計測試用例的簡單動作可以解釋需求的許多問題。 如果你在部分需求穩(wěn)定時就開始開發(fā)測試用例，那么就可以及早發(fā)現(xiàn)問題并以較少的費用解決這些問題。 編寫關(guān)于黑盒子或功能上的測試用例可以明確在特定條件下系統(tǒng)運行的任務(wù)。因為你無法描述可能的系統(tǒng)響應(yīng)，在你面前將會出現(xiàn)一些模糊的和二義性的需求。 當分析員、開發(fā)人員和客戶通過測試用例進行研究時，他們將對產(chǎn)品如何運行的問題有更清晰的認識。,需求測試,在開發(fā)過程的早期階段，可以從使用實例中獲得概念上的功能測試用例。然后，你就可以利用測試用例來驗證文本需求規(guī)格說明和分析模型（例如對話圖）并評價原型。這些基于模仿使用的測試用例可以作為客戶驗收測試的基礎(chǔ)。 在正式的系統(tǒng)測試中，可以把它們詳述成測試用例和過程。 在客戶定義他們驗收的標準時，你詢問客戶的基本問題是：“如果開發(fā)出你們所期望的軟件，你是怎么來判斷開發(fā)出的軟件是你真正所需要的？” 如果他們不能回答關(guān)于每個特性或使用實例的這種問題，他們就必須澄清需求。,需求測試的含義最初對你來說可能看起來比較抽象?？梢杂靡粋€例子把這個概念描述得更清楚，所以讓我們看一下“化學制品跟蹤系統(tǒng)”的開發(fā)組是如何把需求規(guī)格說明、分析模型和早期創(chuàng)建的測試用例結(jié)合在一起。下面列出了與請求化學制品這一任務(wù)相關(guān)的一個業(yè)務(wù)需求、使用實例、功能需求、部分對話圖和一個測試用例。 業(yè)務(wù)需求，該系統(tǒng)的一個主要業(yè)務(wù)動機可以用如下的需求來描述：“化學制品跟蹤系統(tǒng)”通過鼓勵重復使用公司中可用的那些化學制品容器以降低購買費用。 使用實例，與這個業(yè)務(wù)需求相一致的一個使用實例是“請求一種化學制品”，它包括允