淺談軟體項目的需求管理

標籤：建築工程   軟體開發   項目經驗   專案管理   項目實施   

軟體項目區別於其它項目的最顯著的特徵是其不可見度，它不像硬體購銷、建築工程，都是實實在在可見的東西。而軟體項目在系統交付之前很長一段時間，客戶是無法感知自己想要的系統究竟是什麼樣子。因此，需求管理就顯得十分重要，據相關統計資料分析，軟體項目90%以上失敗的原因都在於沒有重視需求或者需求管理方面做的不到位導致的。

需求管理作為軟體專案管理的一個重要內容，貫穿項目實施的全生命週期。俗話說：萬事開頭難。需求作為軟體開發的第一個環節，其重要性不言而喻。市面上關於需求管理的相關理論和書籍很多，但多數停留在理論層面，實操性不強。本文主要是根據我們以往項目的經驗，進行一些需求管理方面的探討。我們可以簡單的將軟體項目的需求管理分為需求萃取、需求分析與驗證、需求變更控制三個核心內容。

（一）需求萃取

需求萃取是軟體項目需求管理的第一個過程，在這個過程中我們需要運用科學的方法以及相關的項目經驗庫輔助我們進行需求萃取。需求萃取的核心內容是通過調研掌握軟體項目的實際需求，以便於指導整個項目的實施。需求萃取的主要方法包括：使用者訪談、問卷調查、現場觀摩、頭腦風暴等方法。在實際的項目操作過程中，相對比較明確的需求，我們可採用比較固定的需求萃取方式，比如：問卷調查等。而對於相對比較模糊的需求或者說使用者無法清晰表述自己需要的是什麼的時候，我們可採用比較靈活的方式，例如：使用者訪談、現場觀摩等。

需求的類型主要包括：業務需求、使用者需求和功能需求。在需求萃取的過程中，無論採用哪種方法，我們都需要自頂向下或自下向上去瞭解使用者真實的想法。業務需求的擷取對象主要是客戶的高層領導，我們都知道，項目的發起、實施、最終的成敗很大程度上都取決於高層領導，我們需要對他們進行訪談，瞭解高層領導的公司戰略、發展方向，更為重要的是擷取他們對將要開發的軟體系統的期望，以及希望該系統在解決現有業務問題，對公司整體戰略的支撐方面的期望。協助我們去更好地理解系統的宏觀構想。在掌握了業務需求後，我們需要對中層管理員進行調研，核心問題是搞清楚在宏觀戰略目標落地的這層，或者說指標細化並負責實施的中層他們對軟體系統的期望以及實際要求，他們或希望此系統能夠帶來工作便利，或希望此系統能夠做到精細化管理，如此等等。但他們都是具體的業務部門負責人，對自身的業務以及系統對業務的促進方面，有比較深刻的體會。最後，我們需要在掌握了業務需求、使用者需求的基礎之上，通過對IT管理部門、主要操作人員的需求調研或根據我們對需求的理解，細化出系統的功能需求，這個需求是最低層次的需求，也是一個層層落地的過程。

（二）需求分析與驗證

在擷取到軟體項目需求後，接下來的工作就是對需求進行分析與驗證，在項目的實際操作過程中，主要包括：需求分析建模、需求規格說明書編寫和需求評審三個大的階段。

需求分析建模主要是對已搜集到的資訊進行提煉、分析和仔細審查，為終端使用者所看到的系統建立一個概念性模型，確保所有干係人都明白其含義，並能找出其中的錯誤、遺漏或不足。需求分析是軟體項目需求管理的最重要一環。

在需求分析與建模過程中，對於使用者需求不確定或使用者無法清晰表述需求的，為了加快項目進度，我們往往採用原型法進行需求分析與建模，即根據我們的經驗以及對使用者基本需求的理解，用Axure等原型設計工具搭建一套原型系統。另外，我們還需要採用UML工具進行用例分析、用例描述等，並最終編寫形成《軟體需求規格說明書》。

需求驗證或需求評審是衡量需求階段產出成果的重要手段，在完成需求分析與建模後，項目相關干係人應組織召開需求評審會，邀請相關專家、外部相關單位等進行需求評審，就需求分析的結果《需求規格說明書》、原型系統等進行評審，並對評審結果進行簽字確認，確保需求沒有偏離使用者要求，又略高於使用者要求。

（三）需求變更控制

需求管理貫穿於軟體項目開發的全生命週期，在完成需求萃取、分析與驗證等任務後，項目組將根據形成的相關報告進行系統設計、編碼、測試、發布等工作，這些過程其實都會涉及到需求的變更，這就需要我們有一套較好的機制和方法來管理和控制需求變更，以便於項目能夠按期保質又在成本範圍內完成。

通常的做法是我們為了避免需求變更的無序、頻繁、過度，在項目啟動時會制定一套章程，會有一個CCB（變更控制委員會），通過召開項目啟動會的方式，給相關干係人確定項目的實施方法、裡程碑、溝通計劃，並著重強調需求變更的流程。

在實際操作中，首先是通過VSS等版本控制工具對需求文檔進行管理，建立需求基準，並通過需求跟蹤矩陣對需求項進行詳細標註。

其次，是在項目執行過程中對需求進行變更控制，有一套規範的流程，過程雖然繁瑣，但能夠給項目的風險控制帶來很好的效果。使用者提出需求變更申請，由項目實施團隊進行需求變更的評估，評估包括可能造成的對系統其它功能的影響、實施此次變更需要投入的工作量等，評估完成後由變更控制委員會確定是否同意變更。如果同意，則由項目組進行變更的實施，並對上線後的變更內容以及整個系統進行驗證，確保不影響系統運行和操作。如果不同意，則變更不成立，直接駁回使用者方。通過這樣一種雖然看似繁瑣的方法能夠很好地進行需求變更的控制，可以有效避免無序、無理、過度的需求變更，確保項目在可控範圍內實施。

 

以上是我們對軟體項目需求管理的一點認識，軟體需求管理之所以重要，主要是因為絕大多數項目的失敗主要由需求的理解不到位、需求的變更沒有得到有效控制等原因造成的。因此，這就要求我們在軟體項目的需求管理方面，要下更大的力氣去做好需求的擷取、分析、變更控制，結合專案管理的相關理論，如PMBOOK、CMMI等，在項目實踐中，不斷總結經驗教訓，做好需求管理。

本文出自 “僱傭天下” 部落格，請務必保留此出處http://2013128588.blog.51cto.com/901427/1433734