摘要:需求管理是整個軟件工程的管理的基礎,也是項目成功的關鍵所在。本文論述了企業軟件開發項目中需求管理的重要性,詳細描述了軟件需求的復雜性,分析了需求變化的原因,并針對這些問題提出相應的管理策略。
關鍵詞:需求管理 軟件需求 需求變化
0 引言
隨著信息時代的發展,計算機軟件的需求愈來愈復雜,規模愈來愈大,而且隨著企業的發展和工作過程重組,需求變更已愈來愈成為必然。在企業軟件項目的開發過程中,需求變更貫穿了軟件項目的整個生命周期,在軟件的項目立項、研發及維護各階段,用戶經驗的增加、對軟件使用感受的變化以及整個行業的新動態,都為軟件帶來不斷完善功能、優化性能、提高用戶友好性的要求。在軟件項目管理過程中,項目經理經常面對用戶的需求變更。如果不能有效處理這些需求變更,項目計劃會一再調整,軟件交付日期一再拖延,項目研發人員的士氣將越來越低落,將直接導致項目成本增加、質量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。
需求管理是軟件開發生命周期的初始階段,它對最終提交的軟件產品的質量起著至關重要的作用。有資料統計,軟件項目40%—60%的問題都源于需求分析。所以,重視需求、謹慎對待、嚴密分析,是每一個開發者應該持有的正確態度。建立軟件需求管理過程的目的在于用戶和軟件項目組之間形成共同的理解,這種共同理解應體現在用戶需求的文檔化確認和對用戶需求的控制中,并保證項目的計劃、工作產品和活動都與需求一致。
1 需求管理復雜性分析
軟件需求是整個軟件開發項目的最關鍵的一個輸入,和傳統的生產企業相比較,軟件的需求具有模糊性、不確定性、變化性和主觀性的特點,不同于生產汽車、電腦等硬件的需求,是有形的、客觀的、可描述的、可檢測的,軟件需求是企業軟件項目最難把握的問題,其復雜性體現在以下方面:
1.1 需求的描述問題。缺少正式的、完整的需求文檔浪費了大量的人力物力,但是有了需求文檔又出現了新的問題。在用戶方進行的需求評審會完全是走形式,因為用戶根本不去聽那上百頁的需求文檔。不同層次的客戶(用戶)關心的問題是不一樣的,想要每個客戶都成為需求專家是不現實的。
1.2 需求的完備程度問題。需求如何做到沒有遺漏?如何準確劃定系統的范圍?這確實是一個兩難問題,稍微大一點的系統要想窮舉需求幾乎是不可能的,每次開需求評審會時,總會冒出新的需求,以至于系統沒有一個準確的范圍界定。即使是這樣,系統還是要開發,系統的范圍還要硬性的劃定一個,從而建立一個基線。
1.3 需求開發的工期問題。在需求上花費了大量的時間,客戶、企業是否能夠忍受?為了確保需求的正確性,完備性,項目經理往往堅持要在需求階段花費大量的時間,但是客戶與企業的高層領導卻會為項目遲遲看不到實際可運行的軟件擔心不已,他們往往會催促項目組盡快往前推進,而項目組的成員往往也會被系統復雜、善變的需求折騰的筋疲力盡,希望盡快結束需求分析的相關工作。
1.4 需求的細致程度問題。需求到底描述到多細,才算可以結束了?仁者見仁,智者見智,并沒有定論,如果時間允許,要想細總可以細下去的。但是,需求的周期越長,可能的變化越多,對設計的限制越嚴格,對需求的共性提取要求越高,所以只要客戶(用戶)、需求分析人員、設計人員、測試人員認為描述清楚了,就可以進入設計階段了。
1.5 需求的變化問題。在軟件開發過程中如果只有一條真理的話,那一定是:需求的變化是永恒的,需求不可能是完備的。軟件開發的過程實際上是同變化做斗爭的過程,需求的變更不一定是壞事,也有可能是好事,是商業機會,對市場敏感的人可以從需求的變化中發現市場機會。
2 需求變化的原因:
需求變化的原因很多,比如:①一開始沒有識別全,需要增加需求;②業務發生了變化,需求必須變化;③需求錯誤;④需求不清楚。
需求的變化問題是每個開發人員、每個項目經理都遇到的問題,也是最頭痛的問題,一旦發生了需求變化,項目組不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等等。需求的變化好像為項目的正常的進展帶來不盡的麻煩,怎么辦?只有通過需求管理使需求在受控的狀態下發生變化,而不是隨意變化,需求管理就是要按照標準的流程來控制需求的變化。難題隨之而來,需求中的變化一般不是突發的革命性的變化,最常見的是項目需求的漸變(Project Scope Creep)問題,這種漸變很可能是客戶與開發方都沒有意識到的,當達到一定程度時,雙方才驀然回首,發現已經物是人非,換了一番天地。
3 需求管理策略
需求管理需要遵守以下策略:
3.1 需求一定要與投入有必然的聯系 需求一定要與投入有必然的聯系,否則如果需求變更的成本由開發方來承擔,則項目需求的變更就成為必然了。人們常說世上沒有免費的午餐,同樣也不應該有免費的需求變更。但是,接受需求變更目前卻是軟件企業不得不咽下的苦果。所以,在項目的開始無論是開發方還是出資方都要明確這一條:需求變,軟件開發的投入也要變。
3.2 要充分理解客戶提出來的需求 開發者應該理解客戶的需求,如果這點做不到,后面的工作是沒有意義的,所以,那種在沒有理解需求的情況下,就倉促開發的做法是不合適的。
3.3 需求的變更要經過出資者的認可 需求的變更引起投入的變化,所以要通過出資者的認可,這樣才會對需求的變更有成本的概念,能夠慎重地對待需求的變更。
3.4 做好需求文檔的版本管理 記錄用戶需求、系統需求、軟件分配需求的文檔都要作為基線確定下來,做好相關文檔的管理工作。需求的基線是指是否容許需求變更的分界線,需求分析人員在充分與客戶用戶進行溝通的基礎上形成第一個版本的需求文檔,這個需求文檔在通過需求評審后即可以建立第一個需求基線。此后每次需求變更并經過需求評審后,都要重新確定新的需求基線,以免將來用戶需求發生變更時,原來的需求無法查找。為有效進行需求變更控制,必然要做的工作就是保存好各個版本的需求基線,維護需求基線文檔,以備不時之需。
3.5 小的需求變更也要經過正規的需求管理流程 小的需求變更也要經過正規的需求管理流程,否則會積少成多。在實踐中,人們往往不愿意為小的需求變更去執行正規的需求管理過程,認為降低了開發效率,浪費了時間。正是由于這種觀念才使需求的漸變不可控,最終導致項目的失敗。
3.6 精確的需求與范圍定義并不會阻止需求的變更 并非對需求定義的越細,越能避免需求的漸變,這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果,因為需求的變化是永恒的,并非需求寫細了就不會變化了。
3.7 注意溝通的技巧 由于需求的變更可能來自投資方、也可能來自用戶方和開發方,作為投資方可能不愿意為需求的變更付出更多的成本,而開發方有可能主動的變更了需求目的是使軟件做的更精致。于是作為需求管理者,項目經理需要采用各種溝通技巧來使項目的各方各得其所。
4 結束語
需求管理是軟件項目中一項十分重要的工作,據調查顯示在眾多失敗的軟件項目中,由于需求原因導致的約占到45%,因此有效的需求管理是企業軟件開發項目順利達成目標的重要支撐條件。理解項目開發的目的和用途,梳理用戶需求,設計系統的各項功能需求,監控需求變化,進行需求確認,對需求風險進行防范,以一系列的方法和措施實施需求管理工作,才能推進軟件項目良性發展,達到用戶與軟件開發企業的雙贏。
參考文獻:
[1]吳艷艷.軟件項目管理中的需求管理[J].信息技術與信息化,2008(2).
[2]唐薇娜.正確應對需求變更[J].軟件工程,2007(6).
[3]江小丁,王朝暉.軟件項目需求管理的研究[J].計算機與現代化,2006[2].