項目管理7-軟件需求管理

軟件需求管理周立新博士北京大學(xué)軟件與微電子學(xué)院業(yè)務(wù)需求用戶需求系統(tǒng)需求功能需求質(zhì)量屬性其他非功能需求約束條件項目視圖與范圍文檔使用實例文檔軟件需求規(guī)格說明用戶能有效的糾正文檔中的拼寫錯誤找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞。找到并高亮度提示錯詞；顯示提供替換詞的對話框以及實現(xiàn)整個文檔范圍的替換。需求工程需求工程需求管理需求開發(fā)編寫規(guī)格說明分析問題獲取驗證包括軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動

建立并維護(hù)在軟件工程中同客戶達(dá)成的契約

需求開發(fā)活動

確定產(chǎn)品所期望的用戶類。獲取每個用戶類的需求。了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。需求開發(fā)活動（續(xù)）將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部份分配給軟件組件。了解相關(guān)質(zhì)量屬性的重要性。商討實施優(yōu)先級的劃分。將所收集的用戶需求編寫成規(guī)格說明和模型。評審需求規(guī)格說明，確保對用戶需求達(dá)到共同的理解與認(rèn)識，并在整個開發(fā)小組接受說明之前將問題都弄清楚。需求管理活動定義需求基線（迅速制定需求文檔的主體）。評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。以一種可控制的方式將需求變更融入到項目中。使當(dāng)前的項目計劃與需求一致。需求管理活動（續(xù)）估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾（約定）。讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。在整個項目過程中跟蹤需求狀態(tài)及其變更情況?；鶞?zhǔn)需求說明分析編寫文檔評審、商議需求變更過程市場需求客戶管理市場客戶管理項目環(huán)境當(dāng)前基線需求開發(fā)需求管理修正后基線需求變更項目變更需求開發(fā)與需求管理之間的界限需求開發(fā)與管理之間的界線1.需求管理活動CMMI中需求管理的流程圖結(jié)束開始制定需求管理計劃求得對需求的理解求得對需求的承諾維護(hù)對需求的雙向追蹤性組織的總體方針需求管理模板管理需求變更識別項目工作與需求之間的不一致性1.1版本控制需求文檔的每一個版本必須被統(tǒng)一確定。組內(nèi)每個成員必須能夠得到需求的當(dāng)前版本。必須清楚地將變更寫成文檔，并及時通知到項目開發(fā)所涉及的人員。為了盡量減少困惑、沖突、誤傳，應(yīng)僅允許指定的人來更新需求。需求的屬性創(chuàng)建需求的時間需求的版本號創(chuàng)建需求的作者負(fù)責(zé)認(rèn)可該需求的人員需求狀態(tài)需求的原因或根據(jù)（或信息的出處）需求涉及的子系統(tǒng)需求涉及的產(chǎn)品版本號使用的驗證方法或接受的測試標(biāo)準(zhǔn)產(chǎn)品的優(yōu)先級或重要程度（例如高、中、低或）需求的穩(wěn)定性（在將來需求可能變更的指示器，不穩(wěn)定的需求意味你應(yīng)給予較多的關(guān)注，因為你將面臨不定的、混沌的、或不能重復(fù)的業(yè)務(wù)過程。）建議的需求狀態(tài)表

狀態(tài)值定義已建議該需求已被有權(quán)提出需求的人建議已批準(zhǔn)該需求已被分析，估計了其對項目余下部分的影響（包括成本和對項目其余部分的干擾），已用一個確定的產(chǎn)品版本號或創(chuàng)建編號分配到相關(guān)的基線中，軟件開發(fā)團(tuán)隊已同意實現(xiàn)該項需求已實現(xiàn)已實現(xiàn)需求代碼的設(shè)計、編寫和單元測試已驗證使用所選擇的方法已驗證了實現(xiàn)的需求，例如測試和檢測，審查該需求跟蹤與測試用例相符。該需求現(xiàn)在被認(rèn)為完成已刪除計劃的需求已從基線中刪除，但包括一個原因說明和做出刪除決定的人員已拒絕狀態(tài)跟蹤示例1.2需求變更管理應(yīng)仔細(xì)評估已建議的變更

。挑選合適的人選對變更做出決定。變更應(yīng)及時通知所有涉及的人員。項目要按一定的程序來采納需求變更?？刂祈椖糠秶臄U(kuò)展擴(kuò)展需求是指在軟件需求基線已經(jīng)確定后又要增添新的功能或進(jìn)行較大改動。問題不僅僅是需求變更本身，而是遲到的需求變更會對已進(jìn)行的工作有較大的影響。要是每個建議的需求都被采納，對于項目出資者（sponsor）、參與者與客戶來說項目將永遠(yuǎn)也不會完成—事實上，這是不可能的。控制項目范圍的擴(kuò)展對許多項目來說，一些需求的改進(jìn)是合理的且不可避免。業(yè)務(wù)過程、市場機(jī)會、競爭性的產(chǎn)品和軟件技術(shù)在開發(fā)系統(tǒng)期間是可以變更的，管理部門也會決定對項目做出一些調(diào)整。在你的項目進(jìn)度表中應(yīng)該對必要的需求改動留有余地。若不控制范圍的擴(kuò)展將使我們持續(xù)不斷地采納新的功能，而且要不斷地調(diào)整資源、進(jìn)度、或質(zhì)量目標(biāo)，這樣做極其有害。管理范圍擴(kuò)展管理范圍擴(kuò)展的第一步就是把新系統(tǒng)的視圖、范圍、限制文檔化并作為業(yè)務(wù)需求的一部分。評估每一項建議的需求和特性，將它與項目的視圖和范圍相比較決定是否應(yīng)該采納它。強(qiáng)調(diào)客戶參與的有效的需求獲取方法能夠減少遺漏需求的數(shù)量，只在做出提交承諾和分配資源后才采納該需求?？刂菩枨髷U(kuò)展的另一個有效的技術(shù)是原型法，這個方法能夠給用戶提供預(yù)覽所有可能的實現(xiàn)，以幫助用戶與開發(fā)者溝通從而準(zhǔn)確把握用戶的真實需求。要敢于說“不”。變更控制策略

所有需求變更必須遵循的過程，按照此過程，如果一個變更需求未被采納，則其后過程不再予以考慮。對于未獲批準(zhǔn)的變更，除可行性論證之外，不應(yīng)再做其它設(shè)計和實現(xiàn)工作。簡單請求一個變更不能保證能實現(xiàn)變更，要由項目變更控制委員會（CCB）決定實現(xiàn)哪些變更。項目風(fēng)險承擔(dān)者應(yīng)該能夠了解變更數(shù)據(jù)庫的內(nèi)容。絕不能從數(shù)據(jù)庫中刪除或修改變更請求的原始文檔。每一個集成的需求變更必須能跟蹤到一個經(jīng)核準(zhǔn)的變更請求。簡單變更控制步驟模板緒論目的范圍定義角色和責(zé)任變更請求狀態(tài)開始條件 任務(wù)產(chǎn)生變更請求評估變更請求作出決策通知變更人員驗證結(jié)束條件變更管理活動中可能的項目角色角色描述及責(zé)任變更控制委員會主席變更控制委員會的主席，在CCB意見不一致情況下可以獨(dú)自做出決定CCB決定采納或拒絕針對某項目所建議的變更請求的團(tuán)體評估者應(yīng)項目管理者要求分析所建議的變更帶來影響的人員修改者負(fù)責(zé)實現(xiàn)已經(jīng)被認(rèn)可的請求變更，按時更新變更狀態(tài)的人員建議者提交新變更請求的人項目管理者負(fù)責(zé)指定評估者和修改者的人員請求接受者接受提交變更請求的人驗證者負(fù)責(zé)決定變更是否正確執(zhí)行的人

變更控制委員會的組成

產(chǎn)品或計劃管理部門。項目管理部門。開發(fā)部門。測試或質(zhì)量保證部門。市場部或客戶代表。制作用戶文檔的部門。技術(shù)支持部門。幫助桌面或用戶支持熱線部門。配置管理部門。常見變更請求數(shù)據(jù)項變更需求狀態(tài)轉(zhuǎn)換圖測量變更活動接收、未作決定、結(jié)束處理的變更請求的數(shù)量。已實現(xiàn)需求變更（包括增、刪、改）的合計數(shù)量（也可以用在基線上占需求總數(shù)的百分比來表示）。每個方面發(fā)出的變更請求的數(shù)量。每一個已應(yīng)用的需求（是指已劃過基線）建議變更和實現(xiàn)變更的數(shù)量。投入處理變更的人力、物力。工作量（勞動時數(shù)）任務(wù)______________更新軟件需求規(guī)格說明書或需求數(shù)據(jù)庫______________開發(fā)并評估原型______________創(chuàng)建新的設(shè)計部件______________修改已有的設(shè)計部件______________開發(fā)新的用戶界面部件______________修改已有的用戶界面部件______________開發(fā)新的用戶文檔和幫助文件______________修改已有的用戶文檔和幫助文件______________開發(fā)新的源代碼______________修改已有的源代碼______________購買和集成第三方軟件______________修改構(gòu)造文件______________開發(fā)新單元測試和綜合測試______________進(jìn)行單元測試和綜合測試______________寫新的系統(tǒng)測試實例______________修改已有的系統(tǒng)測試實例______________修改自動測試驅(qū)動程序______________進(jìn)行回歸測試______________開發(fā)新報告______________修改已有的報告______________開發(fā)新的數(shù)據(jù)庫元素______________修改已有的數(shù)據(jù)庫元素______________開發(fā)新的數(shù)據(jù)文件______________修改已有的數(shù)據(jù)文件______________修改各種項目計劃______________更新別的文檔______________更新需求跟蹤能力矩陣______________檢查工作產(chǎn)品______________根據(jù)測試和檢查情況返工______________總計勞動時數(shù)影響分析報告模板

變更請求ID_______________標(biāo)題__________________描述__________________分析者_(dá)_________________日期_______________優(yōu)先權(quán)評估：相關(guān)收益_______________（1-9）相關(guān)代價_______________（1-9）相關(guān)成本_______________（1-9）相關(guān)風(fēng)險_______________（1-9）最終優(yōu)先級_______________預(yù)計總耗時_______________勞動時數(shù)預(yù)計損時_______________勞動時數(shù)預(yù)計對進(jìn)度的影響_______________天數(shù)額外的成本影響_______________金額質(zhì)量影響_________________________________________被影響的其他需求_________________________________被影響的其他任務(wù)_________________________________要更新的計劃_____________________________________綜合的事項_______________________________________生存期成本事項___________________________________可能的變更所需檢查的其他部件_____________________1.3需求跟蹤客戶需要需求下游工作產(chǎn)品從需求回溯從需求追溯回溯到需求追溯到需求一些可能的需求跟蹤能力聯(lián)系鏈業(yè)務(wù)需求變更請求規(guī)格說明系統(tǒng)需求，用例，業(yè)務(wù)規(guī)則及外部接口需求軟件功能需求依賴另一個系統(tǒng)測試項目計劃任務(wù)體系結(jié)構(gòu)，用戶接口或功能設(shè)計被驗證集成測試代碼單元測試被陳述被驗證連接到被實現(xiàn)被驗證影響影響影響影響RequisiteProProjectOrganizationToolbarProjecticonPackageDocumentViewsRequirementsWorkinginaViewExistingArtifactsforRUe-stProjectUCSpecRMPlancsvfile

Vision

Supl.Spec

IncludedonExerciseCDStakeholderRequestsGlossaryRUe-stProjectExistintheproject

CreateintheprojectImportintotheprojectCreateaRequirementintheExplorerorinaViewUserDocumentation