需求管理是需求開發的基礎

2021-10-01 01:18:21 字數 1508 閱讀 2798

為什麼cmmi建議需求管理在2級實施、而需求開發在3級實施呢?以前看cmmi的時候對這個是有疑問的,但是當時問了其他人也沒有人很清楚,也就睜一眼閉一眼了。這次培訓後,我從「成熟的過程有利於新技術的引入」的思想中得到一些啟發,我覺得是不是cmmi認為,只有把需求管理做好了,做到了對需求管理理念的理解和認同,繼而形成了好的習慣之後,需求開發作為一種新的技術,是相關管理人員在了解了自己的需求現狀(有度量和分析)後,很樸素的和必然的要考慮的問題就是「如何把需求做得更好?」,相應的自然的就回去尋求如何「開發好的需求」。不知道,我這麼理解對不對?

你的思路是對的。規範的專案過程能力,有助技術的提高,需求開發也是一樣。我們需要明白哪方面的規範,可以幫助需求開發的提高。你能夠看得通,可喜可賀!

但是你「睜一眼閉一眼」的態度就非常不好了。

問題的答案早就在cmmi的描述裡。當然,在二級的時候,我們也有需求開發的,否則專案就不可能有交付產品。但是很多時候,我們的需求做的不夠規範,沒有專員負責,需求的內容,往往是不同的開發人員補充自己的任務部分,需求不能一致、不能滿足客戶,質量不能提高。

那麼,如何才能提高需求質量?cmmi的需求管理要求:1)需求是專案與客戶的了解一致、專案按著需求開展活動,以實現需求為目標。2)乙個真心這樣做的專案,它非得到客戶真正的需求不可。開始的時候,我們的技巧未必可以達到這一點,真正明白客戶的需求。但是如果我們接受以客戶為中心,極力爭取客戶滿意,我們就會不斷地找方法把抽取需求的方法加以完善。這就是第**專心要做的。但是基礎,就是第二級的「專案就是要實現客戶滿意的需求」這個概念上的。你應該留意到,我們的專案還沒有建立這個強烈的意願,要按需求開展專案活動,所以我們連建立系統工程師團隊都不願意好好地做。3)要實現需求,就需要需求跟蹤,其意義在於確保所有需求到不多不少地得到實現。我們就需要盯著需求的變更,否則我們的工作就不是真正實現了最終版本的需求了。這一步是保證需求得到忠實實現必要的舉措。

以上各點,都是cmmi二級要求的。就是說,我們二級的時候,是有需求的,但是不規範,因為我們還不了解需求的意義。這就是我說的:「我們還不尊重需求」。當專案還不尊重需求的時候,需求是提高不了的。這裡「需求管理」裡面的」管理「,不單單是一般的管理任務而已,它是通過這些任務,表達乙個目標,這個 「需求管理」,更像是「需求意識」。就是說,知道需求的意義,重要性,與專案的關係,等等之後,必然採取的舉措。cmmi列出這些舉措,其實是要求專案建立需求意識。

其實,這裡的「管理」可以有兩個含義。字面上,他就是有一些「需求」,管理,就是如何處理它。這個含義,讓人自然地想到,如果我們沒有好需求,需求管理,就自然沒有意義。另乙個含義,就是驅動管理活動的思路與方法,而不一定是管理的實際活動。我們需要知道需求的重要性,以及它的關鍵因素,才能最有效地管理它。這裡的管理,含義在於創造有利條件,才能提高需求質量。

讓我再舉乙個案例:剛才收看了cctv4的「尋寶」節目。有些觀眾,拿來評審的文物是假的,有些是非常寶貴的。有些對考古有認識,有些沒有。自己在家裡收藏古董當然無所謂。但是如果我們要當一位規範的古董鑑賞家,我們是否需要在家裡(cmmi第二級)學習古董的價值與收藏方法(需求管理),才可以放膽投資在真正的古董上面(需求開發)?

所以需求管理,是需求開發的基礎。這個跟你的說法是非常一致的。

需求工程 需求管理

需求以自然語言進行描述,應該以某種標識方案進行編號。幾種常見的需求標識和分類的技術 最靈活和不容易出錯的方法是利用資料庫生成唯一識別符號的方法。這是因為資料庫系統支援在併發的情況下對每個新資料記錄生成唯一的識別符號。有些資料庫還可以通過版本號擴充套件唯一識別符號的方式來支援對相同記錄的多個版本的維護...

開發隨筆 需求又是需求

這兩天新系統要正式上線了,從昨天下午一直到今天的下午,在連夜上線.雖然辛苦,但心裡實在憋屈,不吐不快 需求,該死的需求,這是我唯一的想法,我剛到公司時,在了解了公司的現狀後,就感到很是鬱悶,不為別的,要做東西,需求 很多時候只是口頭確認下,還可能隨時修改.看著忙碌的同志們,不由的糾結.這不都要上線了...

需求分析 什麼是需求分析?

需求分析學習目錄 乙個使用者解決乙個問題或實現乙個目標所需的條件或能力 為了滿足乙個合同 標準 規範 或其它正是文件要求,乙個系統或系統構件必須具備或擁有的條件或能力。所有的需求共同形成系統或構件開發的基礎 一種反應1 2所描述的條件或能力的文件說明。在本人所上的軟體需求分析課程中,乙個軟體需求是指...