軟件需求工程05

軟件需求工程

SoftwareRequirementsEngineering

第五章軟件需求與風(fēng)險管理負(fù)責(zé)Contoso制藥公司“化學(xué)制品跟蹤系統(tǒng)”的項目管理人員Dave會見他的首席程序員Helen和首席測試員Ramesh。他們對新項目都很有興趣，但他們也記得在以前一個稱作“藥品仿真”的項目中遇到的問題。“還記得我們直到進(jìn)入測試時才發(fā)現(xiàn)用戶對仿真程序的用戶界面極為不滿意嗎？”Helen問道?！拔覀兓宋逯軙r間重新實現(xiàn)，重新測試，我可再不愿玩這樣的死亡游戲了?！薄暗拇_是煩人，”Dave附和道。“同樣麻煩的是那些用戶提出一大堆沒人用過的特性，這樣的交互導(dǎo)致編碼花費了預(yù)計時間的三倍，我們是不管好歹，編完了事，簡直是廢品！”“我們太匆忙了，以至沒有時間寫詳細(xì)的需求說明”Ramesh回憶道。“測試人員有一半的時間都在問程序員怎樣才能判斷他們的程序工作正常，以便能測試它?？墒浅绦騿T設(shè)計的一些功能根本就不是用戶所要求的。”“特別麻煩的是，要求開發(fā)藥品仿真的管理者根本沒有看需求規(guī)格說明就在上面簽字確認(rèn)了?！盌ave補充道：“于是我們不斷遇到要求新的特性及各種變更，所以工程超期四個月，成本費用超出預(yù)算的一倍這也就不足為怪了。若再發(fā)生這樣的事，我肯定會被解雇了?！盧amesh建議道：“也許我們應(yīng)該把在仿真項目中遇到的問題一一列出來以便我們能在化學(xué)制品跟蹤系統(tǒng)中避免重蹈覆轍。我看了篇關(guān)于軟件風(fēng)險管理的文章，上面介紹說我們應(yīng)指出各種風(fēng)險并說明了怎樣才能避免它們”?！拔铱刹荒菢酉搿盌ave堅持道：“我們已從仿真項目學(xué)到了不少，我們不會再有那些問題了。這個項目還沒有達(dá)到需要用風(fēng)險管理的地步。如果要把我們可能犯的錯誤都寫下來，好像我連怎樣做軟件項目都不知道似的。我不想要任何消極想法影響項目。我們必須為成功而制定計劃?！憋L(fēng)險所謂風(fēng)險就是可能給項目的成功帶來威脅或損失的情況，而風(fēng)險管理則就是指在風(fēng)險給項目帶來損失之前就指明，評估并對風(fēng)險加以控制。在項目中，可能出現(xiàn)差錯的事情常常比可能意想不到地正常運行的事情多風(fēng)險無處不在：要有風(fēng)險意識防患于未然：要有預(yù)防措施軟件風(fēng)險管理風(fēng)險管理：就是使用某些工具或步驟把項目風(fēng)險限制在一個可接受的范圍內(nèi)。風(fēng)險管理包括的活動包括，風(fēng)險評價，風(fēng)險避免，風(fēng)險控制等。編寫項目風(fēng)險文檔：僅僅認(rèn)識到項目面臨的風(fēng)險是遠(yuǎn)遠(yuǎn)不夠的，應(yīng)該將其編寫成文檔并妥善進(jìn)行管理，這樣有利于風(fēng)險承擔(dān)者了解風(fēng)險情況狀態(tài)。制定風(fēng)險管理計劃：一張風(fēng)險列表還不等于一個風(fēng)險管理計劃。需求在軟件項目總扮演著一個核心的角色

1、正因為如此，精明的項目管理者會在初期就指明與需求相關(guān)的風(fēng)險并積極的控制它們。2、典型的需求風(fēng)險包括：對需求的誤解，不恰當(dāng)?shù)挠脩魠⑴c，不確定或隨意變更項目范圍和目標(biāo)等。3、項目管理者只能通過與客戶或客戶代表（如市場人員）合作來控制需求風(fēng)險。

風(fēng)險管理就是使用某些工具和步驟把項目風(fēng)險限制在一個可接受的范圍內(nèi)。風(fēng)險管理提供了一種標(biāo)準(zhǔn)的方法來指出風(fēng)險并把風(fēng)險因素編成文檔，評估其潛在的威脅，以及確定減少這些風(fēng)險的戰(zhàn)略（Williams，Walker，andDorofee1997）。風(fēng)險管理包括的活動如圖5-1所示。風(fēng)險評價（riskassessment）是一個檢查工程項目并識別潛在風(fēng)險區(qū)域的過程。風(fēng)險分級（riskprioritization）有助你通過評價每項風(fēng)險的潛在危害值，優(yōu)先處理最嚴(yán)重的風(fēng)險。風(fēng)險危害值(riskexposure)包括帶來損失的可能性大小和潛在損失的規(guī)模。風(fēng)險條目跟蹤模板僅僅認(rèn)識到項目面臨的風(fēng)險是遠(yuǎn)遠(yuǎn)不夠的。應(yīng)該將其編寫成文檔并妥善進(jìn)行管理，這樣在整個項目開發(fā)過程中有利于風(fēng)險承擔(dān)者了解風(fēng)險情況和狀態(tài)。序列號：<順序號>確定日期：<風(fēng)險被識別出的日期>撤消日期：<撤消風(fēng)險確定日期>描述：<以“條件-結(jié)果”的形式描述風(fēng)險>可能性：<風(fēng)險轉(zhuǎn)變?yōu)閱栴}的可能性>影響：<如果風(fēng)險變成了事實將造成的損失>危害值：<可能性×影響>降低風(fēng)險計劃：<一種或多種用來控制、避免、最小化及降低風(fēng)險的方法>負(fù)責(zé)人：<解決風(fēng)險的責(zé)任承擔(dān)者>截止日期：<完成降低風(fēng)險措施的截止日期>風(fēng)險條目跟蹤模板在編寫風(fēng)險說明時，最好采用條件—結(jié)果的形式。也就是，先說明你關(guān)心的條件，接著是潛在的有害結(jié)果（如果風(fēng)險成為事實）。有時，人們只說明了風(fēng)險條件（如“客戶不同意產(chǎn)品的需求說明”）或者只說明了結(jié)果（“我們只能滿足某些主要的客戶”）。最好將這樣的說明句子合并成條件—結(jié)果形式的結(jié)構(gòu)：“如果有些客戶不贊同產(chǎn)品的需求說明，那我們只能滿足某些主要客戶的意見?！倍粋€條件下可能有多個結(jié)果，同時也可能出現(xiàn)多個條件下導(dǎo)致同一個結(jié)果。模板能記錄風(fēng)險變?yōu)槭聦嵉目赡苄约皩椖康南麡O影響，還有整個的風(fēng)險危害值（可能性×影響）。我用0.1（極不可能）到1.0（肯定發(fā)生）來描述可能性，用1（無甚么影響）到10（有很深、很大的影響）來表示影響。將這兩個因素相乘即可作為評估風(fēng)險危害值的依據(jù)。不要試圖精確量化風(fēng)險。你的目標(biāo)是將最有威脅的風(fēng)險和那些不急需處理的風(fēng)險區(qū)別開來。大家可能更愿意用高、中和低來估計可能性及影響。但風(fēng)險條目中至少應(yīng)有一個為高的風(fēng)險。制定降低風(fēng)險計劃來明確控制風(fēng)險要采取的活動，其中一些策略是盡量降低風(fēng)險發(fā)生的可能性；而另一些則是減少風(fēng)險發(fā)生后帶來的影響。做計劃時要考慮降低風(fēng)險所耗費用，千萬別花費20000美元來控制一項僅會損失10000美元的風(fēng)險。為每項風(fēng)險安排一個負(fù)責(zé)人，并確定完成活動的截止日期。長期或復(fù)雜的風(fēng)險可能需要具有多個階段性成果的多步驟降低風(fēng)險策略計劃。下圖說明了本章開始部分介紹的“化學(xué)制品跟蹤系統(tǒng)”小組領(lǐng)導(dǎo)者討論的一個風(fēng)險。小組憑他們以前的經(jīng)驗估計了風(fēng)險的可能性及其影響。除非他們把其它風(fēng)險因素也估計出來，否則他們并不明白風(fēng)險危害值4.2究竟有多嚴(yán)重。降低風(fēng)險措施的前兩條是通過更多的用戶參與項目來減少風(fēng)險發(fā)生的可能性。而采用原型法則可以利用用戶關(guān)于界面的早期反饋來減少風(fēng)險的潛在影響。風(fēng)險條目樣例序列號：1確定日期：5/4/99撤消日期：描述：需求獲取中無合適用戶參與,導(dǎo)致測試之后用戶界面的返工。.可能性：0.6影響：7危害值：4.2降低風(fēng)險計劃：1.在第一階段早期就要收集易學(xué)、易用的需求。2.與產(chǎn)品代表一起召開JAD會議以開發(fā)需求。3.通過與產(chǎn)品代表和顧問的交流，開發(fā)一個包含核心功能的用戶界面原型。讓產(chǎn)品代表和其他用戶來評估此原型。負(fù)責(zé)人：Helen截止日期：在6/16/99前完成JAD會議。與需求有關(guān)的風(fēng)險需求獲取1)產(chǎn)品視圖與范圍沒有對產(chǎn)品功能達(dá)成一個清晰的共識，則很可能導(dǎo)致項目范圍的逐漸擴(kuò)大。最好在項目早期寫一份項目視圖與范圍將業(yè)務(wù)需求涵蓋在內(nèi)，并將其作為新的需求及修改需求的指導(dǎo)。2)需求開發(fā)所需時間需求開發(fā)工作應(yīng)占全部工作量的15%不要因為工期緊張就不按要求作需求。

3)需求規(guī)格說明的完整性和正確性以用戶的任務(wù)為中心，應(yīng)用使用實例技術(shù)獲取需求。根據(jù)不同的使用情景編寫需求測試用例，建立原型，使需求對用戶來說更加直觀，同時獲取用戶的反饋信息。讓客戶代表對需求規(guī)格說明和分析模型進(jìn)行正式的評審。4)對革新產(chǎn)品的需求有時容易忽略市場對產(chǎn)品的反饋信息。故要強(qiáng)調(diào)市場調(diào)查研究，建立原型，并運用客戶核心小組來獲得革新產(chǎn)品任務(wù)的反饋信息。與需求有關(guān)的風(fēng)險

與需求有關(guān)的風(fēng)險

5)明確非功能需求由于一般強(qiáng)調(diào)產(chǎn)品的功能性要求，非常容易忽略產(chǎn)品的非功能性的需求。詢問客戶關(guān)于產(chǎn)品性能、使用性、完整性、可靠性等質(zhì)量特性，編寫非功能需求文檔和驗收標(biāo)準(zhǔn)，（像在SRS中一樣）作為可接受的標(biāo)準(zhǔn)。6)客戶贊同產(chǎn)品需求如果不同的客戶對產(chǎn)品有不同的意見，那最后必將有些客戶會不滿意。確定出主要的客戶，并采用產(chǎn)品代表的方法來確?？蛻舸淼姆e極參與，確保在需求決定權(quán)上有正確的人選。與需求有關(guān)的風(fēng)險

7)未加說明的需求客戶可能會有一些隱含的期望要求，但并未說明。要盡量識別并記錄這些假設(shè)。提出大量的問題來提示客戶以充分表達(dá)他們的想法、主意和應(yīng)關(guān)注的一切。8)把已有的產(chǎn)品作為需求基線在升級或重做的項目中需求開發(fā)可能顯得不很重要。開發(fā)人員有時被迫把已有的產(chǎn)品作為需求說明的來源?！爸皇切薷囊恍╁e誤和增加一些新特性”，這時的開發(fā)人員不得不通過現(xiàn)有產(chǎn)品的逆向工程(reverseengineering)來獲取需求?？墒?，逆向工程對收集需求是一種既不充分也不完整的方法。因此新系統(tǒng)很可能會有一些與現(xiàn)有系統(tǒng)同樣的缺陷。將在逆向工程中收集的需求編寫成文檔，并讓客戶評審以確保其正確性。9)給出期望的解決辦法用戶推薦的解決方法往往掩蓋了用戶的實際需求，導(dǎo)致業(yè)務(wù)處理的低效，或者給開發(fā)人員帶來壓力以至做出很差的設(shè)計方案。因此分析人員應(yīng)盡力從客戶敘說的解決方法中提煉出其本質(zhì)核心與需求有關(guān)的風(fēng)險

需求分析1)劃分需求優(yōu)先級。2)帶來技術(shù)困難的特性3)不熟悉的技術(shù)、方法、語言、工具或硬件平臺需求規(guī)格說明1)需求理解不同理解評審的團(tuán)隊?wèi)?yīng)包括開發(fā)人員，測試人員和客戶。2)時間壓力對TBD的影響將SRS中需要將來進(jìn)一步解決的需求注上TBD記號，但如果這3)具有二義性的術(shù)語4)需求說明中包括了設(shè)計說做什么，而不是說怎么做。需求驗證1)未經(jīng)驗證的需求2)審查的有效性

需求管理1)變更需求將項目視圖與范圍文檔作為變更的參照可以減少項目范圍的延伸。用戶積極合作參與可把需求變更減