軟件需求管理

軟件需求是整個軟件開發項目的最關鍵的一個輸入，和傳統的生產企業相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，他不像生產汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。

軟件需求是軟件項目最難把握的問題，他的復雜性體現在以下方面：

1、需求的描述問題。

缺少正式的完整的需求文檔浪費了大量的人力物力，但是有了需求文檔又出現了新的問題。在用戶方進行的需求評審會完全是走形式，因為用戶根本不去聽他讀那上百頁的需求文檔。不同層次的客戶(用戶)關心的問題是不一樣的，想要每個客戶都成為需求專家是不現實的。

2、需求的完備程度問題。

需求如何做到沒有遺漏?如何準確劃定系統的范圍?這確實是一個兩難問題，稍微大一點的系統要想窮舉需求幾乎是不可能的，每次開需求評審會時，總會冒出新的需求，以至于系統沒有一個準確的范圍界定。即使是這樣，系統還是要開發，系統的范圍還要硬性的劃定一個，從而建立一個基線。

3、需求開發的工期問題。

在需求上花費了大量的時間，客戶、軟件公司是否能夠忍受?為了確保需求的正確性，完備性，項目經理往往堅持要在需求階段花費大量的時間，但是客戶與公司的高層領導卻會為項目遲遲看不到實際可運行的軟件擔心不已!他們往往會逼迫項目組盡快往前推進，而項目組的成員往往也會為系統復雜的善變的需求折騰的筋疲力盡，他們也希望盡快結束此階段。

4、需求的細致程度問題。

需求到底描述到多細，才算可以結束了?仁者見仁，智者見智，并沒有定論，如果時間允許，要想細總可以細下去的。但是，需求的周期越長，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求越高，所以只要大家(客戶、用戶、需求分析人員、設計人員、測試人員)認為描述清楚了，就可以進入設計階段了。

5、需求的變化問題。

在軟件開發過程中如果只有一條真理的話，那一定是：需求的變化是永恒的，需求不可能是完備的。軟件開發的過程實際上是同變化做斗爭的過程，需求的變更不一定是壞事，也有可能是好事，是商業機會，對市場敏感的人可以從需求的變化中發現市場機會。

需求管理需要遵守以下策略：

需求一定要與投入有必然的聯系，否則如果需求變更的成本由開發方來承擔，則項目需求的變更就成為必然了。人們常說世上沒有免費的午餐，同樣也不應該有免費的需求變更。但是，接受需求變更目前卻是軟件開發商不得不咽下的苦果。所以，在項目的開始無論是開發方還是出資方都要明確這一條：需求變，軟件開發的投入也要變。

需求的變更引起投入的變化，所以要通過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。筆者曾經經歷過一個項目，為了避免項目的風險，我們請了用戶代表全程參與了開發過程，結果此用戶代表在開發過程提出了大量“小的需求變更，當開發人員按此需求變更修改了軟件時，在項目進入現場實施階段時，卻有大量的這些變更需要改回去，問題就是出在我們的項目組成員視該用戶代表的需求為圣旨，卻忽略了需求是否經過了客戶方真正有決策權的人員的認可。

小的需求變更也要經過正規的需求管理流程，否則會積少成多。在實踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。正式由于這種觀念才使需求的漸變不可控，最終導致項目的失敗。

并非對需求定義的越細，越能避免需求的漸變，這是2個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恒的，并非由于需求寫細了，它就不會變化了。注意溝通的技巧。實際情況是用戶、開發者都認識了到了上面的幾點問題，但是由于需求的變更可能來自客戶方、也可能來自開發方，作為客戶他們可能不愿意為需求的變更付出更多的投資，開發方有可能是主動的變更了需求，他們的目的可能是使軟件做的更精致，于是作為需求管理者、項目經理需要采用各種溝通技巧來使項目的各方各得其所。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。