軟件需求工程的概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15、經(jīng)驗(yàn)的專家是非常少的，兩者的結(jié)合是需求成功的保證。,63,48,變更控制經(jīng)理,變更控制經(jīng)理負(fù)責(zé)對(duì)變更控制過程進(jìn)行監(jiān)督。 此角色通常由配置（或變更）控制委員會(huì) (CCB) 來擔(dān)任，該委員會(huì)應(yīng)該由有關(guān)各方（包括客戶、開發(fā)人員和用戶）的代表組成。 在小型項(xiàng)目中，項(xiàng)目經(jīng)理或軟件構(gòu)架設(shè)計(jì)師一人即可承擔(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)域知識(shí)的人才，但這些知識(shí)并不是所有人都必須具備的。

16、,63,50,1.需求獲取,需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生用戶需求說明書。,63,51,需求獲取,需求獲取本質(zhì)上是一個(gè)涉及不同團(tuán)體的交流過程?？煞纸鉃橄铝谢顒?dòng): 發(fā)現(xiàn)(方法：角色、活動(dòng)、資源、產(chǎn)品) 收集(方法：用例、流程圖) 分類(方法：按活動(dòng)、角色相關(guān)度) 評(píng)估(方法：風(fēng)險(xiǎn)、原因) 優(yōu)先級(jí)(方法：重要性、價(jià)值) 文檔：(用戶需求說明書),63,52,2. 需求分析,需求分析的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(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ì)人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設(shè)計(jì)工作。,63,54,需求開發(fā)過程產(chǎn)生的主要文檔,用戶需求說明書。 產(chǎn)品需求規(guī)格說明書 用例模型 補(bǔ)充規(guī)約說明,63,55,4. 需求驗(yàn)證和確認(rèn),需求驗(yàn)證是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后做出書面承諾，使需求文檔具有商業(yè)合同效果。,63,56,需求驗(yàn)證和確認(rèn),需求驗(yàn)證是確保開發(fā)活動(dòng)不斷地符合客戶需要的過程,驗(yàn)證主要是通過評(píng)審活動(dòng)來完成的。 需求確認(rèn)活動(dòng)是在軟件開發(fā)后判斷軟件是否正確地實(shí)現(xiàn)了需求,需求確認(rèn)主要是通過測試和測量活動(dòng)來完成的。,63,57,