CMM中的需求管理及需求開發(fā)

1、需求管理（Requirements Management）是屬于CMM2中的過程域，簡(jiǎn)稱為REQM，需求開發(fā)（Requirements Development）是CMM3中的過程域，簡(jiǎn)稱RD。這兩個(gè)過程域是CMMI體系中關(guān)于需求的全部?jī)?nèi)容，下面分別對(duì)這兩部分進(jìn)行介紹。本文對(duì)CMM的一些基礎(chǔ)知識(shí)、基礎(chǔ)術(shù)語不再介紹。需求管理與需求開發(fā)的分界線： 大家可以這樣理解，需求管理是指對(duì)需求變更的管理、對(duì)需求的跟蹤，而獲取需求、定義需求則屬于需求開發(fā)部分。需求管理在CMMI中，需求管理的目標(biāo)定義為：a. 把軟件需求建立一個(gè)基線供軟件工程和管理使用。b. 軟件計(jì)劃、活動(dòng)和工作產(chǎn)品同軟件需求保持一致。更高的目標(biāo)

2、：軟件需求的復(fù)用需求管理的原則和方法a. 必須與需求工程的其他活動(dòng)緊密整合b. 需求必須是文檔化的、正確的、最新的、可管理的、可理解的c. 只要需求變化了，需求變更的影響就必須被評(píng)估d. 需求必須分優(yōu)先級(jí)e. 需求一定要分類管理需求管理的主要工作：特定目標(biāo)和特定實(shí)踐 特定目標(biāo)l 管理需求管理需求并識(shí)別需求與項(xiàng)目計(jì)劃和工作產(chǎn)品之間的差異。l SP 1.1 取得需求理解l SP 1.2 取得需求承諾l SP 1.3 管理需求變更l SP 1.4 維護(hù)需求的雙向追溯性l SP 1.5 識(shí)別項(xiàng)目工作與需求間的差異REQM特定目標(biāo)的關(guān)系SP 1.1 取得需求理解SP 1.1 和需求提出者一同來了解需求。

3、l 識(shí)別出誰是需求的提供者l 識(shí)別出需求的接受標(biāo)準(zhǔn)：a. Clearly and properly stated得到清晰和恰當(dāng)?shù)亩xb. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一標(biāo)識(shí)的e. Appropriate to implement適宜實(shí)現(xiàn)f. Verifiable (testable)可以驗(yàn)證（測(cè)試）g. Traceable可追溯l 分析需求，確保符合已建立的準(zhǔn)則。l 與需求提供者達(dá)到需求共識(shí)，以使項(xiàng)目成員能承諾它們SP1.2 獲取對(duì)需求的承諾SP1.2 取得項(xiàng)目成員對(duì)需求的承諾。l

4、評(píng)估需求對(duì)現(xiàn)有承諾的影響。需求變更或新需求發(fā)生時(shí)，評(píng)估它們對(duì)項(xiàng)目成員的影響。l 協(xié)商并記錄承諾。在項(xiàng)目成員對(duì)需求或需求改變承諾之前，對(duì)現(xiàn)有承諾的改變應(yīng)先進(jìn)行協(xié)商。l 承諾的時(shí)間點(diǎn)：a. 需求剛建立時(shí)b. 需求變更時(shí)產(chǎn)出物l 需求影響評(píng)估l 需求和需求變更承諾的紀(jì)錄l 項(xiàng)目組成員工作任務(wù)書SP 1.3 管理需求變更SP 1.3 當(dāng)需求在項(xiàng)目執(zhí)行期間逐漸開發(fā)時(shí)，管理需求的變更。l 在項(xiàng)目執(zhí)行期間，造成需求變更的原因很多：a. 需要改變b. 工作進(jìn)行中產(chǎn)生新需求l 提出需求變更的動(dòng)機(jī)是好的，目的是希望產(chǎn)品更加符合用戶的需求。對(duì)項(xiàng)目開發(fā)小組而言，變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果

5、等，開發(fā)小組要為此付出較重的代價(jià)。如果每次需求變更請(qǐng)求都被采納的話，這個(gè)項(xiàng)目也許永遠(yuǎn)不能按時(shí)完成。配置變更委員會(huì)CCBl CCB是授權(quán)進(jìn)行正式基線變更的機(jī)構(gòu) 例如客戶需求、設(shè)計(jì)基線。l 職能： 確保變更被分類以及被評(píng)估 評(píng)審和批準(zhǔn)變更 確保只有被批準(zhǔn)的變更得到實(shí)施 決定需要實(shí)施的變更的優(yōu)先級(jí)l 變更控制活動(dòng)必須在整個(gè)項(xiàng)目中具有可視性l CCB成員可能包括：項(xiàng)目經(jīng)理，配置管理員，質(zhì)量保證人員，開發(fā)人員代表，客戶代表。需求變更的階段l 提交l 評(píng)估l 審批l 實(shí)施l 驗(yàn)證l 關(guān)閉產(chǎn)出物l 需求變更申請(qǐng)表l 需求變更匯總表SP 1.4 維護(hù)需求的雙向追溯性l 維護(hù)需求與項(xiàng)目計(jì)劃和工作產(chǎn)品間的雙向追溯

6、性。l 產(chǎn)出物：需求跟蹤矩陣需求跟蹤矩陣的主要作用RTM的作用A、驗(yàn)證需求的可實(shí)現(xiàn)性、可測(cè)試性B、進(jìn)行需求變更的影響分析C、維護(hù)階段，管理需求的變更需求跟蹤矩陣分為：縱向跟蹤和橫向跟蹤應(yīng)該建立哪些需求跟蹤矩陣？l 在SEI的調(diào)查中達(dá)成的基本共識(shí)是：縱向跟蹤是必須的，如果沒有，則REQM SP1.4無法通過。l 對(duì)于縱向跟蹤矩陣： 必需的： 客戶需求與產(chǎn)品需求的跟蹤 產(chǎn)品需求與測(cè)試用例的跟蹤 100%的接口需求 全局性需求 核心需求并非必需的： 性能需求 不影響系統(tǒng)架構(gòu)的功能需求需求跟蹤矩陣由誰來建立？l 有多個(gè)角色參與建立RTM：a. 需求開發(fā)人員b. 設(shè)計(jì)人員c. 測(cè)試用例的編寫人員d. P

7、PQARTM是否納入基線管理？l RTM要納入基線管理。l 納入基線后，每次變更都要申請(qǐng)，RTM的變更一般是和其他配置項(xiàng)的變更一起申請(qǐng)，很少單獨(dú)申請(qǐng)變更RTM，除非RTM有錯(cuò)誤。l 如何簡(jiǎn)化RTM的工作？l 由于在RTM中，需求可能有很多項(xiàng)，設(shè)計(jì)、測(cè)試用例、代碼等都有多項(xiàng)，所以建立和維護(hù)RTM的工作量還是比較大、比較煩瑣。對(duì)于變化頻繁的項(xiàng)目，更是如此。在實(shí)踐中，為了簡(jiǎn)化該RTM的建立與維護(hù)工作，有的企業(yè)僅僅通過需求與設(shè)計(jì)、代碼、測(cè)試用例的編號(hào)來實(shí)現(xiàn)跟蹤，如需求為：r1,r2,等編號(hào)，而設(shè)計(jì)的編號(hào)為：r1-d1,r1-d2,.,測(cè)試用例的編號(hào)為：r1-t1,r1-t2等等。需要注意的是需求與它們

8、之間是多對(duì)多的關(guān)系，僅通過編號(hào)是無法實(shí)現(xiàn)這種關(guān)系的。如果不借助DOORS之類的需求管理工具，一般只能通過EXCEL來維護(hù)RTM，工作量就l 是比較大。要簡(jiǎn)化，就要平衡管理的投入與產(chǎn)出。l 當(dāng)然也可以考慮增大需求、設(shè)計(jì)、代碼、測(cè)試用例的顆粒度大小，但是那樣RTM的作用就打了折扣，還是一個(gè)平衡問題。SP1.5 確認(rèn)項(xiàng)目工作和需求間的差異主要活動(dòng)：l 評(píng)審項(xiàng)目計(jì)劃、活動(dòng)和工作產(chǎn)品是否與需求和需求變更相符。l 識(shí)別差異來源及其理由。l 當(dāng)需求基線有變動(dòng)時(shí)，識(shí)別有關(guān)計(jì)劃和工作產(chǎn)品所需的變更。l 啟動(dòng)糾正措施。識(shí)別差距的時(shí)機(jī)？l 評(píng)審時(shí)l 變更時(shí)l 日常工作中識(shí)別出的不一致問題要有記錄，并跟蹤問題的關(guān)閉需求管理我們需要客戶方如何做。l 了解乙方需求變更流程，并與乙方就此流程達(dá)成一致l 指定專人負(fù)責(zé)需求變更l 內(nèi)部形成一個(gè)需求變更流程l 針對(duì)內(nèi)部