論文期刊網(wǎng)淺析軟件項目管理中的需求

　　摘要：需求管理是整個軟件工程的管理的基拙，也是項目成功的關(guān)健所在。本文論述了軟件項目中需求管理的重要性及存在的問題，并針對這些問題提出相關(guān)解決方法。

　　關(guān)鍵詞：軟件工程需求　管理軟件項目　論文期刊網(wǎng)

　　1背景

　　1.1需求管理的概念

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

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

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

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

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

　　2需求管理現(xiàn)狀

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

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

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

　　3存在的問題

　　3.1需求描述的細(xì)致性問題

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

　　3.2需求描述的正確性

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

　　另外一種情況就是開發(fā)人員和業(yè)主交流時，由于業(yè)主本身對需求的描述不清晰，導(dǎo)致開發(fā)人員誤解或曲解了業(yè)主最初的要求，最后開發(fā)出來的系統(tǒng)不是不能滿足用戶，就是一個發(fā)生需求錯誤的系統(tǒng)。事實上這種錯誤在需求階段也會經(jīng)常發(fā)生。更可怕的是，對于需求階段出現(xiàn)的錯誤，如果在軟件項目進行到后期的時候才發(fā)現(xiàn)，修復(fù)費用是非常可怕的，甚至?xí)鲰椖勘旧淼馁M用。因此做好需求管理、減少需求錯誤的出現(xiàn)對于降低軟件項目的成本是必要的，也是至關(guān)重要的。

　　3.3需求描述的完備性

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

　　3.4需求的變更

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

　　4解決問題的策略

　　4.1對需求文檔版本控制

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

　　4.2正確認(rèn)識需求變更

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

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

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

　　4.3管理需求變更

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

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

　　4.4建立需求管理模型

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

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

　　4.5與用戶充分溝通

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

　　4.6利用需求管理工具

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

　　5結(jié)束語

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