軟體開發專案的需求管理簡述(Z)

   一、前言

    在軟體專案的開發過程中，需求變更貫穿了軟體專案的整個生命週期，從軟體的專案立項，研發，維護，使用者的經驗在增加，對使用軟體的感受有變化，以及整個行業的新動態，都為軟體帶來不斷完善功能，優化效能，提高使用者友好性的要求。在軟體專案管理過程中，專案經理經常面對使用者的需求變更。如果不能有效處理這些需求變更，專案計劃會一再調整，軟體交付 日期一再拖延，專案研發人員的士氣將越來越低落，將直接導致專案成本增加、質量下降及專案交付日期推後。這決定了專案組必須擁有需求管理策略。

    二、需求管理複雜性分析

    軟體需求是整個軟體開發專案的最關鍵的一個輸入，和傳統的生產企業相比較，軟體的需求具有模糊性、不確定性、變化性和主觀性的特點，他不像生產汽車、電腦等硬體的需求，是有形的、客觀的、可描述的、可檢測的，軟體需求是軟體專案最難把握的問題，他的複雜性體現在以下方面：

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

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

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

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

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

    需求變化的原因很多，如：

    ●一開始沒有識別全，需要增加需求；

    ●業務發生了變化，需求必須變化；

    ●需求錯誤；

    ●需求不清楚。

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

    三、需求管理策略

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

   1、需求一定要與投入有必然的聯絡。

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

    2、需求的變更要經過出資者的認可。

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

    3、小的需求變更也要經過正規的需求管理流程。

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

    4、精確的需求與範圍定義並不會阻止需求的變更。

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

    基於上述的問題，必須對需求進行管理，使需求能夠真正成為軟體工程和管理的基線，使軟體計劃、活動和工作產品同軟體需求保持一致，使需求可以複用。

（RDEASY）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12231076/viewspace-117528/，如需轉載，請註明出處，否則將追究法律責任。