正確對待需求的變更

對于需求和需求變更的理解

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

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

減少需求變更

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

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

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

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

規范文檔

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

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

設計良好的體系結構

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

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

原文轉自：http://www.anti-gravitydesign.com