《軟件需求分析》教學(xué)PPT

《軟件需求分析》教學(xué)PPT,軟件需求分析,軟件,需求,分析,教學(xué),PPT 第16章.需求驗(yàn)證主要內(nèi)容1.驗(yàn)證與確認(rèn)2.需求驗(yàn)證3.需求驗(yàn)證方法4.問題修正5.需求驗(yàn)證的實(shí)踐調(diào)查1.驗(yàn)證與確認(rèn)概念n需求驗(yàn)證：以正確的方式建立需求q需求集是正確的、完備的和一致的；q技術(shù)上是可解決的；q它們在現(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)容1.驗(yàn)證與確認(rèn)2.需求驗(yàn)證3.需求驗(yàn)證方法4.問題修正5.需求驗(yàn)證的實(shí)踐調(diào)查2.需求驗(yàn)證概念n驗(yàn)證普遍存在q獲得的用戶需求是否正確和充分的支持業(yè)務(wù)需求？q建立的分析模型是否正確的反映了問題域特性和需求？細(xì)化的系統(tǒng)需求是否充分和正確的支持用戶需求？q需求規(guī)格說明文檔是否組織良好、書寫正確？需求規(guī)格說明文檔內(nèi)的需求是否充分和正確的反映了涉眾的意圖？需求規(guī)格說明文檔是否可以作為后續(xù)開發(fā)工作（設(shè)計(jì)、實(shí)現(xiàn)、測試等等）的基礎(chǔ)？n需求驗(yàn)證是專指在需求規(guī)格說明完成之后，對需求規(guī)格說明文檔進(jìn)行的驗(yàn)證活動(dòng)2.需求驗(yàn)證活動(dòng)主要內(nèi)容1.驗(yàn)證與確認(rèn)2.需求驗(yàn)證3.需求驗(yàn)證方法1.評審2.原型與模擬3.開發(fā)測試用例4.用戶手冊編制5.利用跟蹤關(guān)系6.自動(dòng)化分析4.問題修正5.需求驗(yàn)證的實(shí)踐調(diào)查3.1 評審n由作者之外的其他人來檢查產(chǎn)品問題的方法n是主要的靜態(tài)分析手段n原則上，每一條需求都應(yīng)該進(jìn)行評審3.1 評審參與人員3.1 評審過程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ā)中的一種方法。閱讀者描述一些獨(dú)立代碼段的功能，然后將描述的范圍逐步擴(kuò)大，描述的功能抽象逐步提高，直至閱讀人員描述了整個(gè)評審物件3.1 評審類型3.2 原型與模擬n涉及到復(fù)雜的動(dòng)態(tài)行為時(shí)n成本較高3.3 開發(fā)測試用例n如果無法為某條需求定義完備的測試用例，那么它可能就存在著模糊、信息遺漏、不正確等缺陷n例外q排斥性需求（Exclusive Requirements）n這種需求要求特定的行為絕對不會(huì)發(fā)生，例如需求可能會(huì)要求系統(tǒng)故障不能導(dǎo)致數(shù)據(jù)庫的崩潰q全局性非功能性需求（Global Non-Functional Requirements）n例如可靠性、可用性等，對這些需求的測試往往都是大數(shù)據(jù)集的處理3.4 用戶手冊編制n驗(yàn)證功能需求q對軟件系統(tǒng)功能和實(shí)現(xiàn)的描述n驗(yàn)證項(xiàng)目范圍q對系統(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)容1.驗(yàn)證與確認(rèn)2.需求驗(yàn)證3.需求驗(yàn)證方法4.問題修正5.需求驗(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)容1.驗(yàn)證與確認(rèn)2.需求驗(yàn)證3.需求驗(yàn)證方法4.問題修正5.需求驗(yàn)證的實(shí)踐調(diào)查5.需求驗(yàn)證的實(shí)踐調(diào)查n需求驗(yàn)證是重要的n需求驗(yàn)證是容易被忽視的n需求驗(yàn)證的方法是多樣的q評審和原型最為廣泛q客戶對線索（Threads）和場景（Scenarios）表現(xiàn)出了最大的興趣q技術(shù)人員、領(lǐng)域?qū)＜?、客戶以及用戶是最合適的評審者實(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ù)小組的爭論中走過的。經(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ā)過程中，沒有好的辦法檢測需求落實(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ā)生的對需求規(guī)格說明文檔進(jìn)行的驗(yàn)證與確認(rèn)活動(dòng)n需求驗(yàn)證有多種有效的方法，實(shí)踐中最為重要和廣泛應(yīng)用是的評審方法和原型方法n需求驗(yàn)證不僅要發(fā)現(xiàn)問題，而且要監(jiān)督問題的解決思考題n用于需求獲取的原型與用于需求驗(yàn)證的原型有何異同？n多種需求驗(yàn)證的方法應(yīng)該如何結(jié)合運(yùn)用？