1、第16章.需求驗(yàn)證主要內(nèi)容n驗(yàn)證與確認(rèn)n需求驗(yàn)證n需求驗(yàn)證方法n問題修正n需求驗(yàn)證的實(shí)踐調(diào)查1. 驗(yàn)證與確認(rèn)概念n需求驗(yàn)證：以正確的方式建立需求q需求集是正確的、完備的和一致的；q技術(shù)上是可解決的；q它們?cè)诂F(xiàn)實(shí)世界中的滿足是可行的和可驗(yàn)證的。n需求確認(rèn)：建立的需求是正確的q每一條需求都是符合用戶原意的n系統(tǒng)驗(yàn)證：正確的建立系統(tǒng)q系統(tǒng)能夠在預(yù)期的環(huán)境中正確的執(zhí)行設(shè)定的功能。n系統(tǒng)確認(rèn)：建立的系統(tǒng)是正確的q建立的系統(tǒng)是符合系統(tǒng)需求和系統(tǒng)設(shè)計(jì)的1. 驗(yàn)證與確認(rèn)軟件工程的驗(yàn)證與確認(rèn)主要內(nèi)容n驗(yàn)證與確認(rèn)n需求驗(yàn)證n需求驗(yàn)證方法n問題修正n需求驗(yàn)證的實(shí)踐調(diào)查2. 需求驗(yàn)證概念n驗(yàn)證普遍存在q獲得的用戶需求

2、是否正確和充分的支持業(yè)務(wù)需求？q建立的分析模型是否正確的反映了問題域特性和需求？細(xì)化的系統(tǒng)需求是否充分和正確的支持用戶需求？q需求規(guī)格說明文檔是否組織良好、書寫正確？需求規(guī)格說明文檔內(nèi)的需求是否充分和正確的反映了涉眾的意圖？需求規(guī)格說明文檔是否可以作為后續(xù)開發(fā)工作（設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試等等）的基礎(chǔ)？n需求驗(yàn)證是專指在需求規(guī)格說明完成之后，對(duì)需求規(guī)格說明文檔進(jìn)行的驗(yàn)證活動(dòng)2. 需求驗(yàn)證活動(dòng)主要內(nèi)容n驗(yàn)證與確認(rèn)n需求驗(yàn)證n需求驗(yàn)證方法q評(píng)審q原型與模擬q開發(fā)測(cè)試用例q用戶手冊(cè)編制q利用跟蹤關(guān)系q自動(dòng)化分析n問題修正n需求驗(yàn)證的實(shí)踐調(diào)查3.1 評(píng)審n由作者之外的其他人來檢查產(chǎn)品問題的方法n是主要的靜態(tài)分

3、析手段n原則上，每一條需求都應(yīng)該進(jìn)行評(píng)審3.1 評(píng)審參與人員3.1 評(píng)審過程3.1 評(píng)審檢查方法檢查方法描述自由方法（Ad-hoc）沒有為檢查人員提供系統(tǒng)化的引導(dǎo)檢查清單（Checklist-Based）以通用的檢查清單來引導(dǎo)檢查過程缺陷（Defect-Based）用于需求文檔，根據(jù)缺陷的分類來組織和檢查場(chǎng)景功能點(diǎn)（Function Point-Based） 按照功能點(diǎn)來組織和檢查場(chǎng)景視角（Perspective-Based）按照不同涉眾類型的視角來組織和檢查場(chǎng)景場(chǎng)景（Scenario-Based）對(duì)每一個(gè)場(chǎng)景，都利用一系列的問題或者細(xì)節(jié)要求，來引導(dǎo)檢查過程。缺陷、功能點(diǎn)、視角都是場(chǎng)景方法的一

4、個(gè)特例。逐步提升（Stepwise Abstraction）凈室軟件開發(fā)中的一種方法。閱讀者描述一些獨(dú)立代碼段的功能，然后將描述的范圍逐步擴(kuò)大，描述的功能抽象逐步提高，直至閱讀人員描述了整個(gè)評(píng)審物件3.1 評(píng)審類型3.2 原型與模擬n涉及到復(fù)雜的動(dòng)態(tài)行為時(shí)n成本較高3.3 開發(fā)測(cè)試用例n如果無法為某條需求定義完備的測(cè)試用例，那么它可能就存在著模糊、信息遺漏、不正確等缺陷n例外q排斥性需求（Exclusive Requirements）n這種需求要求特定的行為絕對(duì)不會(huì)發(fā)生，例如需求可能會(huì)要求系統(tǒng)故障不能導(dǎo)致數(shù)據(jù)庫的崩潰q全局性非功能性需求（Global Non-Functional Requir

5、ements）n例如可靠性、可用性等，對(duì)這些需求的測(cè)試往往都是大數(shù)據(jù)集的處理3.4 用戶手冊(cè)編制n驗(yàn)證功能需求q對(duì)軟件系統(tǒng)功能和實(shí)現(xiàn)的描述n驗(yàn)證項(xiàng)目范圍q對(duì)系統(tǒng)沒有實(shí)現(xiàn)的功能的描述n驗(yàn)證異常流程需求q問題和故障的解決n驗(yàn)證環(huán)境與約束需求q系統(tǒng)的安裝和啟動(dòng)3.5利用跟蹤關(guān)系n業(yè)務(wù)需求用戶需求系統(tǒng)需求q如果業(yè)務(wù)需求和用戶需求沒有得到后項(xiàng)需求（用戶需求和系統(tǒng)需求）的充分支持，那么軟件需求規(guī)格說明文檔就存在不完備的缺陷。n系統(tǒng)需求用戶需求業(yè)務(wù)需求q如果不能依據(jù)跟蹤關(guān)系找到一條系統(tǒng)需求的前項(xiàng)用戶需求和前項(xiàng)業(yè)務(wù)需求，那么該需求就屬于非必要的需求。3.6自動(dòng)化分析主要內(nèi)容n驗(yàn)證與確認(rèn)n需求驗(yàn)證n需求驗(yàn)證方法

6、n問題修正n需求驗(yàn)證的實(shí)踐調(diào)查4. 問題修正n需求澄清（Requirements Clarification）q理解偏差：重新進(jìn)行分析工作q分析遺漏：重新分析和文檔化這部分信息q表達(dá)不當(dāng)：重新以合適的方式表達(dá)n缺失需求q重新執(zhí)行需求獲取等一系列工作n需求沖突q協(xié)商解決n不切實(shí)際的期望q項(xiàng)目調(diào)整與需求協(xié)商主要內(nèi)容n驗(yàn)證與確認(rèn)n需求驗(yàn)證n需求驗(yàn)證方法n問題修正n需求驗(yàn)證的實(shí)踐調(diào)查5. 需求驗(yàn)證的實(shí)踐調(diào)查n需求驗(yàn)證是重要的n需求驗(yàn)證是容易被忽視的n需求驗(yàn)證的方法是多樣的q評(píng)審和原型最為廣泛q客戶對(duì)線索（Threads）和場(chǎng)景（Scenarios）表現(xiàn)出了最大的興趣q技術(shù)人員、領(lǐng)域?qū)＜?、客戶以及用戶?/p>

7、最合適的評(píng)審者實(shí)例分析(一個(gè)公司的業(yè)務(wù)管理系統(tǒng))n問題q需求雖然寫好了也定稿了，但是并沒有得到最終確認(rèn)就開始了軟件開發(fā)工作。這種現(xiàn)象主要是由于業(yè)務(wù)小組和技術(shù)小組溝通不全面造成的，在雙方就某一問題產(chǎn)生分歧的情況下，沒有一個(gè)能出來拍板的人決定（有權(quán)利決定的領(lǐng)導(dǎo)不參與開發(fā)和需求編寫）。q所以整個(gè)項(xiàng)目的開發(fā)是在業(yè)務(wù)小組和技術(shù)小組的爭(zhēng)論中走過的。經(jīng)常出現(xiàn)業(yè)務(wù)小組提出的方案技術(shù)小組難以落實(shí)，等到后期變通修改造成功能損失的情況。因?yàn)樾枨蟮貌坏阶罱K確認(rèn)，一直在修改中，造成技術(shù)小組不停的修改已經(jīng)編寫完畢的模塊，有些改動(dòng)甚至涉及到公共基類的修改和各模塊之間的關(guān)聯(lián)，造成很大的浪費(fèi)。n解決q驗(yàn)證與確認(rèn)+需求管理實(shí)例分析（地稅系統(tǒng)）n問題q系統(tǒng)開發(fā)過程中，沒有好的辦法檢測(cè)需求落實(shí)的情況。最后驗(yàn)收的時(shí)候功能是否實(shí)現(xiàn)由技術(shù)小組說了算。n解決q需求規(guī)格說明+需求驗(yàn)證與確認(rèn)q用戶為中心本章小結(jié)n驗(yàn)證與確認(rèn)是軟件工程當(dāng)中一項(xiàng)重要的活動(dòng)。需求驗(yàn)證是需求工程中發(fā)生的對(duì)需求規(guī)格說明文檔