我說CMMI之七：需求管理過程域--轉載

版權聲明：本文爲博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接和本聲明。
本文連接：https://blog.csdn.net/dylanren/article/details/5951912

我說CMMI之七：需求管理過程域

先講講需求管理的含義。

何謂需求管理？需求管理就是管理需求的一致性。

這裏講的需求指什麼?指的產品與產品構件需求，對於軟件而言一般就是軟件需求規格說明書（SRS）。在CMMI模型中將需求分紅了2類：客戶需求，產品與產品構件需求。客戶需求是採用用戶的術語表達的，用戶驗收的依據，通常是由客戶提出需求，由開發人員記錄、描述、整理下來。客戶需求是平衡了客戶的須要、指望、約束和接口需求後的結果。產品與產品構件需求是採用開發人員的屬於表達的，是開發方驗收的依據。產品與產品構件的需求是基於客戶需求派生而獲得的，可是又並不是僅僅基於客戶需求，還可能由開發方附加了一些需求，還可能因爲技術路線的實現約束而附件了一些需求。

誰和需求的一致性呢？用戶需求、設計文檔、代碼、測試文檔、用戶手冊、安裝手冊、項目計劃書等文檔。

在什麼時候保證和需求的一致性呢？在需求開發的初期，在設計時，在編碼時，在編寫測試用例時，在編寫用戶手冊時，在需求發生變動時，在設計、編碼、測試用例、用戶手冊發生變動時！

需求管理是CMMI 2級中的惟一的一個工程類過程域，工程類過程域包括需求管理、需求開發、技術解決方案、產品集成、驗證、確認，只有將需求管理放在了CMMI的2級，爲何呢？不管需求是如何獲取的如何描述的，首先要管理需求的變動！這裏隱含了一個前提，即需求是文檔化的，需求管理的對象是需求，需求不能是虛無飄渺的，要固化下來，固化下來就是需求文檔。

 

在此過程域中包含了5條特定實踐，翻譯以下：

SP1.1 理解需求：與需求的提供者對需求的含義達成一致

SP1.2 得到對需求的承諾：得到項目組成員對需求的承諾

SP1.3 管理需求的變動：在項目進行中，管理需求的變動

SP1.4 維護需求的雙向可跟蹤性：維護需求和工做產品之間的雙向可跟蹤性

SP1.5 肯定項目工做和需求間的差別：識別項目計劃、工做產品和需求之間的不一致

每條實踐都有一個編號，以「SP1.3 管理需求的變動：在項目進行中，管理需求的變動」來講明一下，SP表明特定實踐，1表明是第1個目標的實踐，3表明是第3條實踐。每條實踐有一個名字，「管理需求的變動」便是這條實踐的名字，「在項目進行中，管理需求的變動」是這條實踐的正文。編號和名字都是解釋性的信息，是幫助記憶的，每條實踐的正文是「指望的」。

 

逐條解釋每條實踐：

 

SP1.1理解需求：與需求的提供者對需求的含義達成一致。

模型的每條實踐都是動賓結構的描述方式，是沒有主語的，咱們在理解時要結合公司的實際狀況，加上主語。對於這條實踐，是誰與需求的提供者對需求的含義達成一致呢？是需求分析人員，是項目組的開發人員，是乙方。

需求的提供者是誰呢？是甲方，是客戶、最終用戶與間接用戶。客戶是出資者，是花錢買系統的人，最終用戶是真正使用系統的人，間接用戶是既不用系統也不掏錢買系統的，可是對系統是否上市、可否成功起了重要做用的人。舉例來說，大家家小孩須要買個手機，你是出資者、小孩子是最終用戶、國家工信部是間接用戶，三者的需求是不同的，關注點是不一樣的。手機要既知足你的需求、小孩子的需求、政府的要求才能夠銷售出去。注意三者是and的關係，不是or的關係，缺一不可。

在CMMI中將需求分紅了4個組成部分：須要，指望，約束條件和接口需求。須要是最基本的、不可裁剪的需求；指望是能夠實現也能夠不實現，最好能實現的需求，指望是能夠妥協的需求；約束條件是對須要和指望的限制條件，是實現須要和指望的環境與障礙；接口需求是系統與其餘系統之間的銜接關係，任何一個系統都不是孤立存在的。

何謂「一致」？是需求分析人員承認需求而且需求的提供者也承認了需求。僅僅是需求分析人員承認，需求提供者不承認，這顯然是不成的，最終驗收時確定沒法經過；僅僅是需求提供者一廂情願，需求分析人員或者開發方不承認也是沒法實現的。需求提供者關注什麼？其一是正確性：是否準確表達了本身的需求？其二是完備性：是否遺漏了需求？開發人員關注什麼？除了上述的正確性與完備性，還關注無二義性、可測試性、可實現性等等。

如何達成一致呢？一般是需求提供者（客戶+最終用戶+間接用戶）講解需求，需求提供者提供最初的需求，由需求分析人員整理需求，而後再給需求提供者確認需求，確認後通常是簽字承認、郵件確認或體如今會議紀要中。

 

SP1.2 得到對需求的承諾：得到項目組成員對需求的承諾。

這條實踐所講的承諾是指對需求可實現性的承諾，是項目組成員對客戶的承諾，承諾什麼呢？是承諾需求是能夠實現的。注意，這個承諾不是客戶對項目組的承諾，不是客戶承諾需求不變。

項目的參與人員在瞭解的需求以後，在和客戶對需求的理解達成一致後，在評估了需求的技術可行性以後對客戶承諾需求是能夠實現的。SP1.1是本條實踐的基礎，是本條實踐的前提。

在CMMI模型中主要在3處提到了承諾的管理，（1） REQM的SP1.2；（2）PP過程域中SP2.3:對需求進行承諾;（3）IPM過程域中SP2.2管理關鍵依賴的子實踐，管理存在關鍵依賴關係的人員之間的承諾。這3處分別描述了對需求的承諾、對計劃的承諾、對關鍵依賴關係的承諾，承諾的層次是逐步細化的，從宏觀到微觀，要求逐步加深。

中國人自古以來說究一言既出;駟馬難追，這個「諾」是一種口頭的承諾，是一種作人的信譽，在模型中提到的承諾要求必定要文檔化，有記錄，是書面的承諾，能夠做爲一種官方的依據，不能空口白說。

在實踐中能夠經過項目組的核心承諾對需求進行了評審、進行了估算、進行技術可行性的確認以後書面簽字確認來記錄。在SP1.1中要求了客戶承認開發方對需求理解，客戶須要書面確認，這裏開發方也要進行書面承諾，兩者均可能表現爲書面的簽字，簽字的含義不一樣。

 

SP1.3 管理需求的變動

管理這個單詞是在CMMI中出現頻率很高的一個單詞，這個單詞的賓語不一樣含義是不一樣的，這裏所說的管理就同這個PA的名字中的管理的含義是一致的：即保證需求的一致性。

這裏所說的管理首先是要肯定這個變動是應該變動的，其次要確保變動了全部相關內容，最後要確保修改的正確性，即很少改、很多改、不錯改。評價是否須要變動時，須要由客戶方與開發方的人員都要參與評價，不能僅僅由一方說了算，須要雙方成立決策的小組，對需求的變動進行綜合的評估。要考慮需求更變的技術影響、管理影響：

技術影響：

修改需求

修改設計

修改代碼

修改測試用例

修改用戶操做手冊

產生的技術風險

……

管理影響：

變動工期

變動工做量

變動成本

變動計劃

變動質量目標

……

須要創建需求變動的控制流程，是否全部的需求變動都走相同的流程呢？未必！

理解CMMI模型要靈活，不要僵化，要根據本身企業的實際狀況進行裁剪。

有一家客戶將需求的變動劃分了高級別與低級別的兩種變動，低級別的變動PM批准便可了，高級別的變動須要CCB批准：

高級別的需求變動：

影響其餘項目組或者影響項目外部承諾的變動；

單次變動估算規模大於項目整體估算規模5%；

單次變動致使工做量成本增長超過1人周；

項目整體累計變動規模大於項目整體估算規模30%後的變動。

低級別的需求變動：

    除上述高級別變動之外的變動。

 

在需求變動的流程中有幾個要點須要強調：

（1）   變動的波及範圍分析要完備；在進行波及範圍分析時要參考需求跟蹤矩陣；

（2）   需求的變動要有評審、批准；

（3）   需求變動完成後要驗證變動的正確性；

（4）   變動完成後要變動基線，從新發布基線，通知相關人員。

 

SP1.4創建需求跟蹤矩陣

需求跟蹤矩陣通常簡寫爲RTM，RTM能夠表達2類跟蹤關係：

   橫向跟蹤關係：需求與需求之間的影響關係；

   縱向跟蹤關係：需求到設計、代碼、用戶文檔、測試用例、計劃之間的影響關係。

 

 並不是全部的跟蹤關係都要創建矩陣，要根據企業的實際狀況進行取捨，好比有的企業只創建客戶需求到產品需求，產品需求到產品需求，產品需求到設計，產品需求到系統測試用例的跟蹤關係。也並不是全部的需求都要創建跟蹤矩陣，好比有的企業僅對全局性的需求創建了跟蹤關係。

這條實踐在不少企業中都被忽略了，或者即便作了也只是形式上有了RTM，實際中並無發現有何做用，而白白地增長了工做量。其實這條實踐的做用與項目的規模頗有關係，項目規模越大，這條實踐的做用也越大，項目規模越小，這個實踐的做用也越小。

針對RTM在我以前的博客中有多篇博文都討論了，這裏再也不多說了，請搜索相關的博文看看吧。

 

SP1.5 識別項目計劃、工做產品與需求之間的不一致性

這條實踐中的字眼就是工做產品，這裏說的工做產品指的設計文檔、代碼、用戶手冊、測試用例等之類的技術文檔。這句話能夠改寫爲：

   識別項目計劃與需求的不一致：便是否有的需求沒有責任到人去開發呢？

   識別設計與需求的不一致：是否有的需求沒有被設計呢？是否有的設計不能知足需求呢？

   識別代碼與需求的不一致：是否有的需求沒有被實現呢？是否有的實現不能知足需求呢？

   …….

   如何理解上述的識別2字呢？

   識別就是找出來，識別就發現出來，識別就是評審出來，識別就是測試出來。識別的手段包括了評審、測試等驗證與確認手段。這個識別不是一次性的，而是在項目進展過程持續進行屢次的，這個識別是要參考RTM的。

   若是發現了不一致，怎麼辦？記錄問題，定義措施，跟蹤關閉，使其保持一致！

 

以上對REQM的5條特定實踐進行了解釋，如何創建需求管理的流程呢？其實這個PA並不是必定要去編寫一個需求管理的流程。須要仔細分析一下，下面給出一種思路供參考：

    SP1.1 能夠編寫到需求獲取的流程中，當需求獲取完成後，由客戶確認需求理解的一致性；

    SP1.2 能夠編寫到需求評審的流程中，當需求評審完成後，由開發人員確認需求的可實現性；

    SP1.3 須要編寫一個需求變動的流程，該流程能夠合併到配置管理的變動管理流程中；

    SP1.4 能夠在需求開發過程當中創建客戶需求到產品需求，產品需求到產品需求的跟蹤矩陣，能夠在設計過程當中創建設計到產品需求的跟蹤矩陣，在測試過程當中創建測試用例到產品需求的跟蹤矩陣，以此類推；

    SP1.5 能夠在需求評審、設計評審、代碼評審、測試用例評審、測試、用戶手冊評審、需求變動、設計變動等流程中體現識別不一致的活動。

不必定須要寫一個需求管理的流程吧！

模型，要用活了！
————————————————
版權聲明：本文爲CSDN博主「麥哲思科技任甲林」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。
原文連接：https://blog.csdn.net/dylanren/article/details/5951912