軟件需求工程的概念

1、63,1,軟件需求工程的概念,北京航空航天大學(xué)軟件工程研究所 羅燕京 2013.2第7版 Luo_,63,2,軟件需求工程的概念,對軟件需求的認(rèn)識 軟件需求工程的基本框架 需求與其他項目過程的聯(lián)系 需求工程描述,63,3,對軟件需求的認(rèn)識,63,4,1.1 對軟件需求的初級認(rèn)識,需求不是根本問題，編碼才是軟件開發(fā)工作。 給我一個項目，無論需求多么復(fù)雜我一定能完成它。需求很重要，但很容易搞清它。 在初級軟件開發(fā)人員的潛意識中需求不是那么可怕,編程技術(shù)才是重要的。 當(dāng)這些問題與需求管理處理技能不足,缺乏管理工具，出現(xiàn)需求管理混現(xiàn)時才會逐漸引起項目管理者的重視。,1.2 業(yè)界的當(dāng)前狀況,根本某軟件公

2、司近五年的實踐總結(jié), 在軟件項目開發(fā)中的主要分類10種問題; 總結(jié)的10種問題分類中需求過程占了30%; 需求問題占了47%;,63,5,63,6,具體問題實例,我們不了解客戶的配合工作執(zhí)行情況，很難有機會與客戶交流項目進(jìn)度情況，存在溝通理解偏差的情況; 前期需求方面加大力度，明確及確認(rèn)各項需求邊界，做好需求變更控制; xx項目需求變更過大，不能有效控制; 頻繁的人員變動及需求變更導(dǎo)致進(jìn)度不斷延遲; 需求沒有在實際開發(fā)開展之前與客戶達(dá)成共識;,63,7,具體問題實例,總體感覺項目范圍界限沒有用需求規(guī)格說明書或者需求說明書規(guī)范，導(dǎo)致在系統(tǒng)設(shè)計、開發(fā)的過程中發(fā)現(xiàn)問題無據(jù)可查。 客戶不斷的提出修改要

3、求,使最初的有序開發(fā)，逐步轉(zhuǎn)變?yōu)槠Ｓ趹?yīng)付客戶新要求 面對需求頻繁變更給我們帶來的許多不確定性的問題，目前沒有太好的辦法來解決。 客戶方對自己的需求并不清晰，開發(fā)項目過程受客戶方影響過大，客戶方在適用階段才提出了不少的變更;,63,8,具體問題實例,沒有受控的需求,甚至需求還未完成的基礎(chǔ)上就已開始了測試工作; 一份與客戶達(dá)成共識的需求規(guī)格說明書很重要！ 售前工作方面提升的空間很大，包括與客戶溝通、收集客戶需求、編寫方案、等等技術(shù)技能方面都比較欠缺，對行業(yè)領(lǐng)域內(nèi)的專業(yè)知識還需要進(jìn)一步的積累;,63,9,總結(jié)評估,說明大部分軟件項目所遇到的問題是基本一致的; 說明軟件研發(fā)人員對所遇到的問題的認(rèn)識是基

4、本一致的; 說明大多數(shù)軟件項目的技術(shù)過程瓶頸是基本一致的; 說明軟件需求過程問題是當(dāng)前項目研發(fā)中的主要過程技術(shù)瓶頸;,63,10,1.3 項目失敗的根本原因,需求來源：市場需求主導(dǎo)不足 不完整的需求 缺乏用戶介入 不實際的客戶期望 需求和規(guī)范的變更 缺乏高層的支持 勝任的團(tuán)隊成員大少 缺乏項目管理經(jīng)驗,63,11,63,12,1.4 相對重要的軟件問題,一次調(diào)查以確定在產(chǎn)業(yè)中相對重要的軟件問題,根據(jù)3800個被調(diào)查人的回答,大約半數(shù)的被調(diào)查者回答的兩個最大問題是: 1)需求規(guī)格說明 2)管理客戶需求 相對而言編碼不是問題 很顯然,我們完全可以把需求當(dāng)作導(dǎo)致軟件問題的最根本原因。,63,13,需

5、求錯誤的頻率,缺陷來源 潛在缺陷 排除的效率 提交的缺陷 需求 1.00 77% 0.23 設(shè)計 1.25 85% 0.19 編碼 1.75 95% 0.09 建檔 0.60 80% 0.12 不恰當(dāng)修復(fù) 0.40 70% 0.12 合計 5.00 85% 0.75,63,14,需求錯誤的頻率,需求錯誤在提交缺陷(用戶著到的缺陷)中是最高的,占了大約全部提交缺陷的三分之一。 因此需求錯誤是系統(tǒng)開發(fā)錯誤中最常見的一類錯誤。,63,15,1.5 需求錯誤的高昂代價,如果把編碼階段發(fā)現(xiàn)和修復(fù)一個錯誤所需要的努力用1個成本單元表示的話,那么需求階段的錯誤修復(fù)成本是它的5到10倍。而且,在維護(hù)階段發(fā)現(xiàn)和

6、修復(fù)一個錯誤的成本超過20倍。 在項目的需求階段發(fā)現(xiàn)錯誤所花費的成本與維護(hù)階段發(fā)現(xiàn)錯誤的成本比例是200:1,63,16,在生命周期不同階段修復(fù)缺陷的相對成本,20,5,2,1,0.5,0.1,需求,設(shè)計,編碼,單元測試,驗收測試,維護(hù),63,17,結(jié)論,需求錯誤可能是最常見的錯誤。 需求錯誤可能是修改花費最昂貴的錯誤。 需求錯誤可能消耗整個項目預(yù)算的25%到40%。 給定需求錯誤的頻率及其“修改成本”的倍增效果因子,可以預(yù)言,需求錯誤將占去返工成本的70%或更多。 返工通常會消耗項目預(yù)算的30%到50%,因此得出:需求錯誤很容易就消耗掉整個項目預(yù)算的25%到40%!,63,18,1.6 軟件

7、需求的主要問題,領(lǐng)域知識 需求過程 需求方法 需求技術(shù) 需求工具 需求管理經(jīng)驗 高層管理的支持 勝任的團(tuán)隊成員 資金與時間,63,19,軟件需求的主要問題,63,20,什么是好的需求,好的需求是正確的、無歧義的、可檢驗和可驗證的并且是可跟蹤的。 好的需求集合是完整的、一致的和可修改的。(IEEE軟件需求規(guī)格說明標(biāo)準(zhǔn)),63,21,對現(xiàn)代軟件需求的認(rèn)識,軟件需求是領(lǐng)域知識的學(xué)習(xí)、經(jīng)驗積累的過程。 軟件需求是領(lǐng)域知識的傳遞過程。 軟件需求是在軟件開發(fā)過程中迭代增量的認(rèn)識過程。 軟件需求是不斷變化的,我們要承認(rèn)和適應(yīng)這種變化,要學(xué)習(xí)適應(yīng)軟件變化的技術(shù)和方法。 軟件需求是軟件開發(fā)過程中最關(guān)鍵的過程。,

8、63,22,軟件需求工程的基本框架,63,23,軟件需求工程的概念,軟件需求工程包括了以下主要內(nèi)容： 對軟件需求基本知識的學(xué)習(xí)和了解 掌握一個基本的需求過程 熟練過程活動的方法和技術(shù),軟件需求過程的六個主要活動,軟件需求過程包括需求開發(fā)和需求管理兩大類活動。 需求開發(fā)活動 需求獲取 需求分析 需求定義 需求管理活動 需求驗證和確認(rèn) 需求跟蹤 需求變更控制,63,24,63,25,開發(fā)過程產(chǎn)品,軟件需求工程的基本框架,63,26,需求處理過程的生命周期,63,27,軟件需求過程,軟件需求過程包括需求開發(fā)和需求管理兩大類活動。 需求開發(fā)活動 需求獲取、需求分析、需求定義 需求管理活動 需求驗證和確

9、認(rèn)、需求跟蹤、需求變更控制,63,28,需求開發(fā)與需求管理之間的界限,63,29,基本的軟件需求過程,63,30,好的過程屬性,過程被書面化 過程是靈活的，可變的 每個人都同意遵循這個過程 過程包含度量，該度量用于測量過程的有效性 度量是修改過程的基礎(chǔ) 過程被主動管理,63,31,軟件需求工程框架,我們把所有與軟件需求相關(guān)的活動通稱為軟件需求工程。 需求工程中的活動可分為兩大類: 需求開發(fā) 需求管理,63,32,需求開發(fā),需求開發(fā)包括三個知識和實踐要點: 1.需求獲取 2.需求分析 3.需求定義,63,33,需求開發(fā),需求開發(fā)可分為兩個階段：“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段”，“需求分

10、析”則貫穿于上述兩個階段。 需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進(jìn)行的。我們把從事需求開發(fā)工作的人員稱為需求分析員（系統(tǒng)分析員）,63,34,需求管理,需求管理包括三個知識和實踐要點 1.需求驗證和確認(rèn) 2.需求跟蹤 3.需求變更控制,63,35,什么是需求管理,需求定義了系統(tǒng)必須具有的能力,一個項目的成功與否往往取決于它是否符合一系列的需求。因此,探討需求的確切含義、把它們寫下來、組織起來、跟蹤它們的變更就顯得非常有意義。 需求管理定義為:為系統(tǒng)的需求進(jìn)行啟發(fā)、組織、建檔的系統(tǒng)方法,建立和維護(hù)客戶和項目團(tuán)隊之間關(guān)于變更系統(tǒng)需求所達(dá)成的一致性的過程。,63,

11、36,需求管理,任何曾經(jīng)參與過復(fù)雜軟件系統(tǒng)的人,無論是作為用戶還是開發(fā)人員,都知道從用戶和風(fēng)險承擔(dān)人那里獲取需求的能力是非常關(guān)鍵的技能; 與一個系統(tǒng)相關(guān)的需求即使沒有上千條,也至少有數(shù)百條,因此把它們合理地組織起來非常重要。 我們無法記憶太多的信息,因此為需求建檔能夠有效支持風(fēng)險承擔(dān)人之間的溝通。 必須把需求用可訪問的介質(zhì)來記錄:文檔,模型。,63,37,需求管理,需求管理與項目的大小和復(fù)雜度有關(guān) 兩個人、十條需求的項目,不需要管理需求。但是,如果要驗證一個有500-1000條需求的軟件產(chǎn)品,我們就面臨著必須對這些需求進(jìn)行組織、劃定優(yōu)先級、控制對它們的訪問以及為它們提供存儲資源的問題。 可以把

12、需求管理看成處理重要的復(fù)雜項目需求的一系列理有組織的、標(biāo)準(zhǔn)化的、系統(tǒng)化的過程和技術(shù)。,63,38,軟件需求工程的螺旋模型,63,39,過程活動的方法和技術(shù),需求獲取的方法和技術(shù) 發(fā)現(xiàn)(方法：角色、活動、資源、產(chǎn)品) 收集(方法：用例、流程圖) 分類(方法：按活動、角色相關(guān)度) 評估(方法：風(fēng)險、原因) 優(yōu)先級(方法：重要性、價值) 文檔(用戶需求說明書) 需求分析的方法和技術(shù) 結(jié)構(gòu)化分析方法和面向?qū)ο蟮幕痉椒?基于UML的用例分析技術(shù)),63,40,過程活動的方法和技術(shù),需求定義的方法和技術(shù)(需求規(guī)格說明書) 用例模型建模方法和用例補充規(guī)約說明 需求驗證和確認(rèn)的方法和技術(shù) 驗證與評審和測試方

13、法技術(shù) 需求跟蹤的方法和技術(shù) 需求跟蹤矩陣 需求變更控制的方法和技術(shù) 需求變更控制流程和變更控制委員會,63,41,需求與其他項目過程的聯(lián)系,63,42,需求工程描述,63,43,需求工程的用例,63,44,涉眾,涉眾是所有會受到項目結(jié)果重大影響的人。 要有效地解決任何復(fù)雜的問題，就會涉及到滿足不同涉眾的需要。涉眾通常會對問題持有不同的觀點，因而必須用所提供的解決方案來滿足不同的需要。 許多涉眾都是系統(tǒng)的用戶。其中許多涉眾只是系統(tǒng)的間接用戶，或者只受到系統(tǒng)所影響的業(yè)務(wù)結(jié)果的影響。還有許多涉眾是系統(tǒng)的經(jīng)濟型買主或支持者。 了解涉眾的組成及其特定需要是開發(fā)有效解決方案的關(guān)鍵。,63,45,風(fēng)險承擔(dān)

14、者,風(fēng)險承擔(dān)者是高層需求的提出者，他們往往對需求細(xì)節(jié)不是很關(guān)心。 系統(tǒng)的主要功能產(chǎn)生的作用及效益是他們關(guān)心的重點。 注意系統(tǒng)風(fēng)險承擔(dān)者的宏觀需求是有效解決問題的關(guān)鍵和項目成功的保證之一。,63,46,客戶,客戶有兩種: 系統(tǒng)的操作者和維護(hù)者，他們對系統(tǒng)的界面、易使用性、易維護(hù)性、穩(wěn)定性比較關(guān)心。 系統(tǒng)的用戶，對系統(tǒng)的功能可以給他們帶來的便利程度、舒適度、工作效率、工作滿意度比較關(guān)心。,63,47,領(lǐng)域?qū)＜?領(lǐng)域?qū)＜揖哂胸S富的業(yè)務(wù)領(lǐng)域經(jīng)驗，是系統(tǒng)業(yè)務(wù)流程、業(yè)務(wù)規(guī)則的提供者。 領(lǐng)域?qū)＜沂菢I(yè)務(wù)建模的主要角色。 但是領(lǐng)域?qū)＜乙话闳狈I(yè)務(wù)模型轉(zhuǎn)化為計算機邏輯模型的經(jīng)驗和能力。 具有領(lǐng)域經(jīng)驗和計算機建模

15、經(jīng)驗的專家是非常少的，兩者的結(jié)合是需求成功的保證。,63,48,變更控制經(jīng)理,變更控制經(jīng)理負(fù)責(zé)對變更控制過程進(jìn)行監(jiān)督。 此角色通常由配置（或變更）控制委員會 (CCB) 來擔(dān)任，該委員會應(yīng)該由有關(guān)各方（包括客戶、開發(fā)人員和用戶）的代表組成。 在小型項目中，項目經(jīng)理或軟件構(gòu)架設(shè)計師一人即可承擔(dān)此角色。,63,49,系統(tǒng)分析員,系統(tǒng)分析員通過概括系統(tǒng)的功能和界定系統(tǒng)來領(lǐng)導(dǎo)和協(xié)調(diào)需求獲取及用例建模。例如，確定存在哪些主角和用例，以及他們之間如何交互。 擔(dān)任系統(tǒng)分析員的人員應(yīng)該善于協(xié)調(diào)，并且具有良好的溝通技巧。擔(dān)任此角色的人員中必須要有具備業(yè)務(wù)和技術(shù)領(lǐng)域知識的人才，但這些知識并不是所有人都必須具備的。

16、,63,50,1.需求獲取,需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生用戶需求說明書。,63,51,需求獲取,需求獲取本質(zhì)上是一個涉及不同團(tuán)體的交流過程?？煞纸鉃橄铝谢顒? 發(fā)現(xiàn)(方法：角色、活動、資源、產(chǎn)品) 收集(方法：用例、流程圖) 分類(方法：按活動、角色相關(guān)度) 評估(方法：風(fēng)險、原因) 優(yōu)先級(方法：重要性、價值) 文檔：(用戶需求說明書),63,52,2. 需求分析,需求分析的目的是對各種需求信息進(jìn)行分析，消除錯誤，刻畫細(xì)節(jié)等。 常用的需求分析方法有 “結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?面向?qū)ο蠓治龇壳俺Ｓ玫姆椒ㄊ腔赨ML的用例分析技術(shù),產(chǎn)品是用例模

17、型。,63,53,3. 需求定義,需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生產(chǎn)品需求規(guī)格說明書。 系統(tǒng)設(shè)計人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設(shè)計工作。,63,54,需求開發(fā)過程產(chǎn)生的主要文檔,用戶需求說明書。 產(chǎn)品需求規(guī)格說明書 用例模型 補充規(guī)約說明,63,55,4. 需求驗證和確認(rèn),需求驗證是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。,63,56,需求驗證和確認(rèn),需求驗證是確保開發(fā)活動不斷地符合客戶需要的過程,驗證主要是通過評審活動來完成的。 需求確認(rèn)活動是在軟件開發(fā)后判斷軟件是否正確地實現(xiàn)了需求,需求確認(rèn)主要是通過測試和測量活動來完成的。,63,57,