軟件需求第5章(參考版)
2024-09-08 13:24本頁面
【正文】 為每項(xiàng)風(fēng) 險(xiǎn)安排一個(gè)負(fù)責(zé)人負(fù)責(zé)實(shí)施降低風(fēng)險(xiǎn)的活動(dòng)。估計(jì)每項(xiàng)風(fēng)險(xiǎn)發(fā)生的可能性及其影響 ， 并將兩者乘積起來得到風(fēng)險(xiǎn)危害值。 ? 召集代表開發(fā)、市場、客戶和管理各方面的風(fēng)險(xiǎn)承擔(dān)者召開風(fēng)險(xiǎn)“集體研討”會(huì) 議。將風(fēng)險(xiǎn)因素用條件 —— 結(jié)果形式編寫成文檔， 正如 圖 52模板所示的那樣。即使不能控制項(xiàng)目可能遇到的所有風(fēng)險(xiǎn)，但風(fēng)險(xiǎn)管理能使你看清形勢，做出的決策是有依據(jù)的。 周期性的風(fēng)險(xiǎn)跟蹤能使管理人員保持對風(fēng)險(xiǎn)危害變化的了解，對那些并未得到完全控制的風(fēng)險(xiǎn)能得到高層管理人員的注意。如果用戶一直沒有參與，風(fēng) 險(xiǎn)危害值將會(huì)擴(kuò)大以至危害項(xiàng)目的成功。 風(fēng)險(xiǎn)管理是你的好助手 項(xiàng)目管理人員可以運(yùn)用風(fēng)險(xiǎn)管理來提高對造成項(xiàng)目損失的條件的警惕，在需求獲取階段要有用戶的積極參與。產(chǎn)品中未說明白的地方將耗費(fèi)比預(yù)料更多的工作量，而且按最初需求所分配好的項(xiàng)目資源也可能不按實(shí)際更改后用戶的需求而調(diào)整。 擴(kuò)充項(xiàng)目范圍 。需求跟蹤能力矩陣有助于避免在設(shè)計(jì)，結(jié)構(gòu)建立及測試期間遺漏的任何需求。需求變更過程包括對變更的影響評估，提供決策的變更控制委員會(huì)，以及支持確定重要起點(diǎn)步驟的工具。需求變更的風(fēng)險(xiǎn)來源于未曾明確的變更過程或采用的變動(dòng)機(jī)制無效或不按計(jì)劃的過程來做出變更。而為了減少需求變更的影響， 將那些易于變更的需求用多種方案實(shí)現(xiàn)，并在設(shè)計(jì)時(shí)更要注重其可修改性。用戶積極參與的具有良好合作精神的需求獲取過程可把需求變更減少近一半（ Jones 1996a）。 需求管理 變更需求 。如果評審人員不懂得怎樣正確地評審需求文檔和怎樣做到有效評審，那么很可能會(huì)遺留一些嚴(yán)重的不足之處。從客戶代表方獲得參與需求評審的贊同（承諾），并盡早且以盡可能低的成本通過非正式的評審逐漸到正式評審來找出其存在 的問題。但如果在構(gòu)造設(shè)計(jì)開始之前通過驗(yàn)證基于需求的測試計(jì)劃和原型測試來驗(yàn)證需求的正確性及其質(zhì)量，就能大大減少項(xiàng)目后期的返工現(xiàn)象。 需求驗(yàn)證 未經(jīng)驗(yàn)證的需求 。包含在 SRS中的設(shè)計(jì)方法將對開發(fā)人員 造成多余的限制并妨礙他們進(jìn)行最佳設(shè)計(jì)的創(chuàng)造性。對 SRS的評審能夠幫助參與者對關(guān)鍵術(shù)語、概念等達(dá)成一致的共識(shí)。建立一本術(shù)語和數(shù)據(jù)字典，用于定義所有的業(yè)務(wù)和技術(shù)詞匯，以防止它被不同的讀者理解為不同的意思。因此應(yīng)記錄解決每項(xiàng) TBD的負(fù)責(zé)人的名字，如何解決的以及解決的截止日期。 時(shí)間壓力對 TBD的影響 。訓(xùn)練有素且頗有經(jīng)驗(yàn)的需求分析人員能通過詢問客戶一些合適的問題，從而寫出更好的規(guī)格說明。開發(fā)人員和客戶對需求的不同理解會(huì)帶來彼此間的期望差異，將導(dǎo)致最終產(chǎn)品無法滿足客戶的要求。明確那些高風(fēng)險(xiǎn)的需求并允許一段充裕時(shí)間用來從錯(cuò)誤開始學(xué)習(xí)、實(shí)驗(yàn)及原型測試。 不熟悉的技術(shù)、方法、語言、工具或硬件平臺(tái) 。分析每項(xiàng)需求的可行性以確定是否能按計(jì)劃實(shí)現(xiàn)。評估每項(xiàng)新需求的優(yōu)先級并與已有余下的工作主體相對比以做出適宜的決策。 需求分析 劃分需求優(yōu)先級 。用戶推薦的解決方法往往掩蓋了用戶的實(shí)際需求，導(dǎo)致業(yè)務(wù)處理的低效，或者給開發(fā)人員帶來壓力以至做出很差的設(shè)計(jì)方案。將在逆向工程中收集的需求編寫成文檔，并讓客戶評審以確保其正確性 ?？墒牵嫦蚬こ虒κ占枨笫且环N既不充分也不完整的方法。開發(fā)人員有時(shí)被迫把已有的產(chǎn)品作為需求說明的來源。 把已有的產(chǎn)品作為需求基線 。 要盡量識(shí)別并記錄這些假設(shè)。 未加說明的需求 。如果不同的客戶對產(chǎn)品有不同的意見，那最后必將有些客戶會(huì)不滿意。詢問客戶關(guān)于產(chǎn)品性能、使用性、完整性、可靠性等質(zhì)量特性，編寫非功能需求文檔和驗(yàn)收標(biāo)準(zhǔn)，（像在 SRS中一樣）作為可接受的標(biāo)準(zhǔn)。 明確非功能需求 。有時(shí)容易忽略市場對產(chǎn)品的反饋信息。讓客戶代表對需求規(guī)格說明和分析模型進(jìn)行正式的評審。為確保需求是客戶真正需要的，要以用戶的任務(wù)為中心，應(yīng)用使用實(shí)例技術(shù)獲取需求。記錄你參與的每個(gè)項(xiàng)目中實(shí)際需求開發(fā)的工作量，這樣就能知道所花的時(shí)間是否合適并改進(jìn)將來項(xiàng)目的工作計(jì)劃。項(xiàng)目因其規(guī)模和應(yīng)用種類不同（如信息系統(tǒng)，系統(tǒng)軟件，商業(yè)的或軍事的應(yīng)用）而有 著很大的不同。 45b3ab679e853e21c524018e30c33611 47 需求開發(fā)所需時(shí)間 。讓產(chǎn)品代
公司管理相關(guān)推薦
鄂ICP備17016276號-1