南京大學(xué) 軟件 需求工程16章.需求驗(yàn)證

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

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

3、1 評審檢查方法檢查方法描述自由方法（Ad-hoc）沒有為檢查人員提供系統(tǒng)化的引導(dǎo)檢查清單（Checklist-Based）以通用的檢查清單來引導(dǎo)檢查過程缺陷（Defect-Based）用于需求文檔，根據(jù)缺陷的分類來組織和檢查場景功能點(diǎn)（Function Point-Based）按照功能點(diǎn)來組織和檢查場景視角（Perspective-Based）按照不同涉眾類型的視角來組織和檢查場景場景（Scenario-Based）對每一個(gè)場景，都利用一系列的問題或者細(xì)節(jié)要求，來引導(dǎo)檢查過程。缺陷、功能點(diǎn)、視角都是場景方法的一個(gè)特例。逐步提升（Stepwise Abstraction）凈室軟件開發(fā)中的一種方

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

5、求對軟件系統(tǒng)功能和實(shí)現(xiàn)的描述驗(yàn)證工程范圍對系統(tǒng)沒有實(shí)現(xiàn)的功能的描述驗(yàn)證異常流程需求問題和故障的解決驗(yàn)證環(huán)境與約束需求系統(tǒng)的安裝和啟動(dòng)3.5利用跟蹤關(guān)系業(yè)務(wù)需求用戶需求系統(tǒng)需求如果業(yè)務(wù)需求和用戶需求沒有得到后項(xiàng)需求用戶需求和系統(tǒng)需求的充分支持，那么軟件需求規(guī)格說明文檔就存在不完備的缺陷。系統(tǒng)需求用戶需求業(yè)務(wù)需求如果不能依據(jù)跟蹤關(guān)系找到一條系統(tǒng)需求的前項(xiàng)用戶需求和前項(xiàng)業(yè)務(wù)需求，那么該需求就屬于非必要的需求。3.6自動(dòng)化分析主要內(nèi)容驗(yàn)證與確認(rèn)需求驗(yàn)證需求驗(yàn)證方法問題修正需求驗(yàn)證的實(shí)踐調(diào)查4. 問題修正需求澄清Requirements Clarification理解偏差：重新進(jìn)行分析工作分析遺漏：重新

6、分析和文檔化這局部信息表達(dá)不當(dāng)：重新以適宜的方式表達(dá)缺失需求重新執(zhí)行需求獲取等一系列工作需求沖突協(xié)商解決不切實(shí)際的期望工程調(diào)整與需求協(xié)商主要內(nèi)容驗(yàn)證與確認(rèn)需求驗(yàn)證需求驗(yàn)證方法問題修正需求驗(yàn)證的實(shí)踐調(diào)查5. 需求驗(yàn)證的實(shí)踐調(diào)查需求驗(yàn)證是重要的需求驗(yàn)證是容易被無視的需求驗(yàn)證的方法是多樣的評審和原型最為廣泛客戶對線索Threads和場景Scenarios表現(xiàn)出了最大的興趣技術(shù)人員、領(lǐng)域?qū)＜摇⒖蛻粢约坝脩羰亲钸m宜的評審者實(shí)例分析需求雖然寫好了也定稿了，但是并沒有得到最終確認(rèn)就開始了軟件開發(fā)工作。這種現(xiàn)象主要是由于業(yè)務(wù)小組和技術(shù)小組溝通不全面造成的，在雙方就某一問題產(chǎn)生分歧的情況下，沒有一個(gè)能出來拍板的

7、人決定有權(quán)利決定的領(lǐng)導(dǎo)不參與開發(fā)和需求編寫。所以整個(gè)工程的開發(fā)是在業(yè)務(wù)小組和技術(shù)小組的爭論中走過的。經(jīng)常出現(xiàn)業(yè)務(wù)小組提出的方案技術(shù)小組難以落實(shí)，等到后期變通修改造成功能損失的情況。因?yàn)樾枨蟮貌坏阶罱K確認(rèn)，一直在修改中，造成技術(shù)小組不停的修改已經(jīng)編寫完畢的模塊，有些改動(dòng)甚至涉及到公共基類的修改和各模塊之間的關(guān)聯(lián)，造成很大的浪費(fèi)。實(shí)例分析系統(tǒng)開發(fā)過程中，沒有好的方法檢測需求落實(shí)的情況。稅務(wù)系統(tǒng)中專業(yè)性很強(qiáng)，經(jīng)常出現(xiàn)業(yè)務(wù)人員不懂計(jì)算機(jī)的情況，有些業(yè)務(wù)人員甚至不會(huì)上網(wǎng)。技術(shù)小組編寫的代碼是否已經(jīng)實(shí)現(xiàn)了全部功能，很多業(yè)務(wù)人員在測試過程中發(fā)現(xiàn)不了問題，造成最后驗(yàn)收的時(shí)候功能是否實(shí)現(xiàn)由技術(shù)小組說了算。本章小結(jié)