論軟件項目管理中的需求問題及創新

　　論文摘要：由于需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進行組織，并在發生變化時對它們進行追蹤，這些活動都是有意義的。換句話說，需求管理就是:一種獲取，組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。需求管理是整個軟件工程的管理的基拙，也是項目成功的關健所在。本文論述了軟件項目中需求管理的重要性及存在的問題，并針對這些問題提出相關解決方法。本文選自《中國信息化》。《中國信息化》雜志由新聞出版總署正式批準、中華人民共和國工業和信息化部主管主辦的一本國家批準創刊的唯一一份以關注工業化與信息化融合，推進信息化進程為使命的國家級信息化媒體國公開刊物。《中國信息化》雜志立足經濟與社會發展大背景和信息化發展趨勢，反映信息化實踐，深度體現信息產業與信息化相互促進。主要面向和服務于政府信息化推進部門的決策層，重點領域應用機構的領導層，企業的CIO及管理層，信息化實施部門的主導層，以及關注信息化的專家、學者等。集思想性、知識性、可讀性為一體的權威雜志傳媒。

　關鍵詞：軟件工程需求,管理軟件項目,中國信息化

　　1背景

　　1.1需求管理的概念

　　理解需求管理的第一步就是對什么是需求管理達成共識。Rational把需求定義為“(正在構建的)系統必須符合的條件或具備的功能”。

　　由于需求是正在構建的系統必須符合的事務，而且符合某些需求決定了項目的成功或失敗，因此找出需求是什么，將它們記下來，進行組織，并在發生變化時對它們進行追蹤，這些活動都是有意義的。換句話說，需求管理就是:一種獲取，組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。

　　1.2需求管理在軟件項目管理中的地位

　　簡單地說，系統開發團隊之所以管理需求，是因為他們想讓項目獲得成功。滿足項目需求即為成功打下了基礎。若無法管理需求，達到目標的幾率就會降低。以下最近收集的證據很有說服力:StandishGroup從1994年到2001年的CHAOSReports證實，導致項目失敗的最重要的原因與需求有關。2001年，StandishGroup的CHAOSReports報導了該公司的一項研究，該公司對多個項目作調查后發現，百分之七十四的項目是失敗的，即這些項目不能按時按預算完成。其中提到最多的導致項目失敗的原因就是“變更用戶需求”。

　　在軟件項目的開發過程中，需求變更貫穿了軟件項目的整個生命周期，在軟件項目管理中需求工程是軟件開發的第一步，是關鍵的一步，也是最難把握的一步。需求管理做得好壞直接影響到軟件的質量，甚至軟件項目的成敗。從軟件的項目立項、研發、維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能、優化性能、提高用戶友好性的要求。在項目管理過程中，項目經理經常面對用戶的需求變更，如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發人員的士氣將越來越低落，將直接導致項目成本增加、質量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。

　　2需求管理現狀

　　隨著信息時代的發展，計算機軟件的需求愈來愈復雜，規模愈來愈大，而且隨著企業的發展，工作過程重組，需求變更已愈來愈成為必然。軟件危機持續了30年之久，至今仍無法得以很好地解決。究其原因，軟件本身具有的特點固然有關，但長期以來，缺乏軟件開發和維護的正確方法以及忽視軟件開發過程的質量控制乃是最為關鍵的原因。其中軟件開發和維護方法的不正確性主要體現在:忽視軟件開發前期的需求分析;開發過程缺乏統一的、規范化的方法論的指導;文檔資料不齊全或不準確;忽視與用戶之間、開發組員之間的交流;忽視測試的重要性;不重視維護或由于上述原因造成維護工作的困難。

　　這樣，就經常出現用戶對“已完成”系統不滿意，軟件產品的質量經常出現漏洞，補丁一大堆。因此人們意識到以工程化的原則和方法組織軟件開發工作是解決軟件危機的一個主要出路。

　　需求分析作為軟件生命周期的第一個階段，并貫穿于整個軟件生命周期，其重要性越來越突出，到20世紀80年代中期，逐步形成了軟件工程的子領域—需求工程。進人20世紀90年代后，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會(ISRE),1994年起，每兩年舉辦一次需求工程國際會議(ICRE)。一些關于需求工程的工作小組相繼成立。

　　3存在的問題

　　3.1需求描述的細致性問題

　　在文章的開頭就說明了軟件需求在整個軟件系統開發中的重要性，正是由于它的重要性，一般來說，需求描述越詳細越好。項目的開發方與用戶在各種問題上的要求都是基本輪廓達到一致即可，具體的細節可以以后再填充，這是一種非常危險的思想。不管需求分析做的多么細致，以后對需求的變更都是必然的。另一方面，在需求分析階段，開發人員希望再多投人一些時間，但是用戶卻不這么認為，因為需求階段是軟件系統開發首先要進人的階段，離最終開發出可用的系統還有很長一段距離，這導致了雙方的不一致。但如果在需求階段投人很多時間，時間越長，可能的變化就越多，對設計的限制越嚴格，因此在需求描述的問題上，沒有統一的界定，需要開發人員學會適當的把握。

　　3.2需求描述的正確性

　　軟件開發是一種專業行為，一般的業主難以理解軟件開發人員的開發理念。所以在和業主交流時，他們講述的需求在實際中利用現有的技術是實現不了的，用戶以為自己很清楚自己的需求了，但實際上他們只是依據當時的工作需求提出的。隨著開發工作的不斷進展，用戶可能想到更多的功能和特色，進而對以前的需求進行改動，導致需求的不一致。

　　另外一種情況就是開發人員和業主交流時，由于業主本身對需求的描述不清晰，導致開發人員誤解或曲解了業主最初的要求，最后開發出來的系統不是不能滿足用戶，就是一個發生需求錯誤的系統。事實上這種錯誤在需求階段也會經常發生。更可怕的是，對于需求階段出現的錯誤，如果在軟件項目進行到后期的時候才發現，修復費用是非常可怕的，甚至會超出項目本身的費用。因此做好需求管理、減少需求錯誤的出現對于降低軟件項目的成本是必要的，也是至關重要的。

　　3.3需求描述的完備性

　　系統的需求是層出不窮的，我們不可能做到把所有的需求都一一列舉出來，并且隨著時間的推進，用戶的需求也會越來越多，要窮舉需求是不可能做到的。另外，并不是用戶提出的所有需求都要滿足，在項目的最后，改變一個需求對整個項目的影響或損失很可能會超過需求本身給用戶帶來的益處。

　　3.4需求的變更

　　需求的變化問題是每個開發人員、每個項目經理都遇到的問題，也是最頭痛的問題，一旦發生了需求變化，你不得不來修改你的設計、重寫你的代碼、修改你的測試用例、調整你的項目計劃等等，需求的變化好比是萬惡之源，為項目的正常的進展帶來不盡的麻煩，怎么辦?管理它!使需求在受控的狀態下發生變化，而不是隨意變化，需求管理就是要按照標準的流程來控制需求的變化。難題隨之而來，需求中的變化一般不是突發的革命性的變化，最常見的是項目需求的漸變(ProjectScopeCreep)問題，這種漸變很可能是客戶與開發方都沒有意識到的，當達到一定程度時，雙方才驀然回首，發現已經物是人非，換了一番天地。

　　4解決問題的策略

　　4.1對需求文檔版本控制

　　客戶簽收的所有過程文檔都要作為基線確定下來，做好相關文檔的管理工作。需求的基線是指是否容許需求變更的分界線，需求分析人員在充分與客戶用戶進行溝通的基礎上形成第一個版本的需求文檔，這個需求文檔在通過需求評審后即可以建立第一個需求基線。此后每次需求變更并經過需求評審后，都要重新確定新的需求基線，以免將來用戶需求發生變更時，原來的需求無法查找。為有效進行需求變更控制，必然要做的工作就是保存好各個版本的需求基線，維護需求基線文檔，以備不時之需。

　　4.2正確認識需求變更

　　在軟件開發過程中有這樣一條真理:需求的變化是永恒的，需求不可能是完備的。軟件開發的過程實際上是一個變化的過程，需求的變更不一定是壞事，也有可能是好事。

　　變更的需求之所以變得難以管理，不僅是因為一個變更了的需求意味著要花費或多或少的時間來實現某一個新特性，而且也因為對某個需求的變更很可能影響到其他需求。應確保賦予需求一個有彈性的結構，使它能適應變更，并且確保使用可追蹤性鏈接可以表達需求與開發生命周期的其他工件之間的依賴關系。管理變更包括建立基線，確定需要追蹤的重要依賴關系，建立相關項之間的可追蹤性，以及變更控制等活動。

　　需求變更貫穿了軟件項目的整個生命周期，通過建立規范的變更控制流程，改進軟件分析與設計，把變化納人計劃之中，在應對需求變更時可以更加的從容和有信心。

　　4.3管理需求變更

　　變更控制不應該只是軟件開發過程應該考慮的事情，隨著軟件產品的開發和時間的推進，用戶會提出越來越多的新需求，甚至在交付軟件產品的最后階段用戶還會有不同的需求，因此需求變更的管理應貫穿于整個項目生命周期的全過程。

　　為了使變更對項目的影響降到最小，就應當采取合適有效的變更控制策略，確定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此流程。對需求的變更的處理應該分以下幾個步驟:提出變更、變更評估、實施變更、監督變更過程。

　　4.4建立需求管理模型

　　需求建模是表達需求的一種形式，是對需求的一種描述與闡釋，它使用標準的語言，利用類似積木的概念來建模，最大的好處是大家可以直接根據需求，輕易地反復修改需求模型。并且不會產生歧義，從而可以使大多數人快速地理解。

　　需求建模的目的是要消除人際溝通隨意性很強的弱點，所以需要致力于將溝通標準化、自動化、準確化，而且責任到人負責的具體階段。具有可測試、可驗證性的特點。建模的過程就是通過需求的特點和要求進行分析，以建模標準為基礎進行準確、完備和有效的闡述，以確保客戶和開發方都能夠明確無誤地、通用的理解。

　　4.5與用戶充分溝通

　　在需求管理過程中與用戶的溝通很重要，因為它直接決定著最終軟件產品是否滿足客戶的要求，即很大程度上決定著項目的成敗。在溝通時，雙方對需求的認識要一致，不能模棱兩可。討論需求及變更需求時，需求人員與客戶及用戶應該盡量采取協作的態度，良好的工作氛圍也會提高工作效率，很難想象雙方在“刁難”與“對付”的態度下是多糟糕的工作場景。確定需求基線的過程也是與客戶用戶交流的過程，而頻繁大量的需求變更在很大程度上也是交流不充分的后果。所以，有效的充分的交流尤為重要，需求人員認真聽取客戶用戶的要求，進行分析和整理，并最終取得用戶的確認。

　　4.6利用需求管理工具

　　需求變更控制委員會可以采取商業化的需求管理工具，以此來在數據庫中存儲不同類型的需求。這些工具提供了對每項需求的屬性描述、狀態跟蹤等，并可以在需求與其它的相關工作產品間建立跟蹤能力聯系鏈。

　　5結束語

　　需求管理是需求分析過程中的一個步驟，是一個持續的不斷完善的過程，軟件項目開發過程中需求管理的問題有很多，隨時都有用戶需求變更，需求分析的錯誤也時常發生，需求質量難以保，針對這些問題，如何采取有效的措施盡可能減少這些問題可能給項目造成的影響也顯得尤其重要，另外關于需求的質量問題，怎樣結合CMM標準進行需求的質量管理，有效提高軟件的總體質量水平也是需要關注的問題。