如何正確對待需求的變更

如何正確對待需求的變更
      1、對於需求和需求變更的理解
　　軟件需求是整個軟件項目的最關鍵的一個輸入，和傳統的生產企業相比較，軟件的需求具有模糊性、不確定性、變化性和主觀性的特點，它不像生產汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。軟件需求是軟件項目最難把握的問題，同時又是關係項目成敗的關鍵因素，因此對於需求分析和需求變更的處理十分重要。

　　軟件需求變更會給項目帶來巨大的風險,會導致項目的成本費用增加、開發週期延長、產品質量下降及團隊工作效率下降等不良後果，因而需求變更在軟件開發項目中應該儘量避免。然而由於政府對特定軟件的相關要求、用戶部門市場戰略的調整、工業界的發展等因素都可能帶來需求的變更，而這些因素往往不可避免。在軟件開發過程中如果只有一條真理的話，那一定是：需求的變化是永恆的，需求不可能是完備的。因而，對於需求變更應該正確的對待，儘量將其負面影響降低到最低。

　　2、減少需求變更

　　正如前文所說，需求變更往往是不可避免的。通常是項目負責人員花費了大量的氣力避免需求變更，可最後需求變更總是會出現。但是這並不意味着項目開發人員不應該做這方面的工作，項目開發人員對於需求變更的正確態度應該和軟件測試的態度一樣，在需求並更發生之前儘量減少需求變更，以將需求變更帶來的風險降低到最低。項目開發人員切忌在項目設計之前試圖消除需求變更，這樣做往往費力不討好。

　　相比於需求開發人員而言，客戶可能對需求變更認識不足，認爲他們出錢，程序員或軟件開發公司就要爲它服務，因此客戶對需求變更往往將需求變更視爲兒戲，隨個人喜好隨意變更需求。因此，在需求人員同用戶代表或用戶部門主管人員接觸時，就應該向他們挑明態度，和他們協商好，特別是應該讓他們清楚軟件的定價應該與軟件的功能相關，以及需求隨意變更所帶來的風險的承擔者應該由客戶和項目開發者共同承擔。通過這樣做，讓客戶在需求分析之前就儘量對他們所需要的功能有個整體的瞭解和確定的思路，而不是等到程序員開始編碼了，才提出以前原本在需求分析時就可以提出的需求。

　　讓客戶明白減少需求變更的重要性後，需求分析人員應該採取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關係不應該僅僅是記錄人員和需求提供者，他們的關係應該更多的是戰略合作伙伴關係。雖然需求分析人員和客戶存在着服務商和顧客的關係，但是他們有着一個共同的目標：開發出適合客戶需求的軟件，因此需求分析人員除了記錄客戶提出的需求以外，還應和用戶討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，儘量多的召集需求研討會，邀請開發人員和客戶共同協商探討，在研討會上允許任意的提出需求，並將這些需求整理成檔後由客戶代表和需求分析人員共同商議可選的功能，這樣能夠儘量使得需求完備。在需求開發時，開發人員採用原型的方法啓發客戶思考功能需求也不失爲一個好辦法。

　　雖然需求不可能是完備的，但是在項目開始設計時儘量使得需求完備還是應該的，也是值得的。

　　3、規範文檔

　　需求文檔作爲客戶和開發人員的接口在整個項目開發過程中起着舉足輕重的作用。需求文檔應該按照一定的格式和規範書寫，而且應該具備完整性、一致性、基線控制、歷史記錄等特性。文檔書寫完畢以後應該交給客戶審閱，在客戶滿意的基礎上確定基線。一個完整規範的需求文檔不僅能夠有助於設計人員和編碼人員完成項目開發，更重要的是它作爲一個階段性的成果可以供軟件需求變更時參考。

　　需求變更發生後，也應該生成相應的文檔，並且這些文檔的書寫也應該採用規範的形式書寫。需求變更文檔也應該包含基線以供下一次修改參考，還應包含歷史記錄以供開發人員和客戶清楚當前的文檔內容的新舊以及歷史文檔的情況，以備以後查看。

　　開發軟件就如同建造一座房屋，軟件體系結構則如同建房屋時的規劃。兩層高的家庭住宅和幾十層高的商業大廈建造時的規劃必然不同，同樣，大型軟件和小軟件採用的體系結構也必然有所區別。因此，設計一個合理的體系結構對於項目的成敗也是十分關鍵的。

　　體系結構的建立一般位於需求分析結束之後，軟件設計之前。軟件體系結構的設計是從結構的角度對整個系統進行分析，選擇合適的構件，安排構件間的相互作用以及他們之間的約束，形成一個系統框架以滿足用戶需求。在設計軟件體系結構時，不僅應該想到如何完成滿足現在已經提出的用戶需求，同時也應適當地考慮到需求的變更。

　　採用有彈性和可擴展的軟件體系結構設計可以有效地降低需求變更引起的風險和維護代價，能夠在項目範圍未發生變化的前提下很好地適應需求的變化。體系結構的靈活和可擴展性設計使得開發者可以在這種體系結構上面進行各個功能層的組合和分離，也可以將各個功能層分佈在各個不同的服務器上共同提供服務，因而能夠快速的對需求變更作出響應，並且對已經開發好的系統產生儘可能少的影響。

　　體系結構的設計除了考慮到體系結構的靈活性和可擴展性以外，還應儘量採用鬆散耦合的結構，使得結構中的各個構件之間的關聯程度儘可能的少，這樣就能在需求發生變更時一個構件的變化對另一個構件產生儘可能少的影響。

　　現有的軟件體系結構很多，包括管道－過濾器結構、B/S結構（含C/S結構）、解釋器/虛擬機結構、黑板系統以及基於中間件技術的體系結構。在設計體系結構時，首先應該選出適合項目需求的系統結構，然後在從中挑選出那些擴展性比較好，構件之間耦合性比較小的體系結構。基於中間件技術的體系結構就是擴展性比較好的體系結構。採用中間件技術，中間件作爲用戶界面和操作系統以及網絡的連接點，向上爲用戶提供服務，向下屏蔽操作系統和網絡的細節。這種分層的思想能夠很好的適應操作系統和網絡的變化，可擴展性十分的好。同時，可以在中間件中給出容易改變的接口或是爲系統將來改變預留接口來實現功能上的需求變更。當然可擴展性比較好的體系結構遠不止基於中間件技術的體系結構這一種，具體的選擇和運用應該由設計人員根據實際需要考慮.

　　5、採用面向對象思想

　　需求是不穩定的，因而沒有不變的需求，然而需求之中卻有穩定的東西，這就是對象。世界都是由對象組成的，而對象都是持久的，例如動物、植物已經有相當長的時間。雖然對象也在變化，動物、植物也在不斷的進化。但對象在一個相當長的時期內都存在，動植物的存在時間肯定比任何一家企業長久。面向對象的開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象，以企業對象爲基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多，因爲企業的模式一旦變化，只需要將穩定的企業對象重新組織就行了。

　　面向對象（OO）技術的三大特徵保證了採用OO技術可以建立易於改變和加強可重用性的軟件系統。封裝可以把問題影響的範圍縮小，外部的變化要求對系統的影響可以限定到某個類層次或某些類層次中，從而改變系統的一部分相對簡單；繼承可以使改變基於原有技術基礎，很大程度上減少重複開發工作；多態的應用可以使開發和設計人員在相對統一的接口下更改系統的實現細節，從而改變系統的行爲。

　　顯然，OO技術是一種增強軟件可維護性、健壯性以及保持設計穩定性的一種分析和設計方法，可以在一定程度上快速對需求變更進行反應，並可相對減少需求變更需要的成本。因此，在系統開發過程中應該儘量的採用面向對象的思維方式來構建系統和開發系統。

　　6、需求變更控制

　　正如前文所言，需求變更不可避免的會發生，那麼當需求變更發生後項目開發人員應該如何應對呢？

　　一般來講，需求的變更通常意味着需求的增加，需求的減少相對很少，而且處理也比較容易。當客戶提出新需求的時候，項目開發人員應該分析這些新需求對項目現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間、人力、資源等等方面，再與客戶商討是否有必要進行變更和如何在最小代價下實現變更。

　　當客戶確實希望進行需求變更時，可以讓開發人員開發一個快速原型，讓用戶體驗一下，以確保客戶確確實實的希望添加這些需求。在客戶和項目開發人員共同確定了需求變更後，項目開發人員應該與客戶簽訂一份新的合同。

　　當客戶提出需求變更並且簽訂了合同後或是開發人員根據市場和國家政策作出的需求變更得到確證後，項目開發人員應該決定何時實施這些變更。對於那些對系統影響不大和一些優先權十分高的需求變更可以立即在項目中實施，而對於那些對於整個系統現階段的開發影響很大，而且又不是十分緊急的需求可以放在下一個版本中進行。無論是立即實施還是放在下一個版本中，都應該給新的需求一個充足的開發和測試時間，保證產品質量。

　　結論

　　在面對需求變更時，除了通過減少需求變更和規範文檔，從分析和設計的角度通過採用合理的分析和設計方法適應需求變更以外，還應該改變我們設計的意識和對需求變更的理解，做好對需求變更的控制和管理，做到對需求變更的靈活應對，在一定程度上降低維護代價和提高用戶滿意度。