軟件需求工程09-6

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