一份事實上的技術合同。
然而，由于以下幾方面的原因，開發(fā)人員對《軟件需求規(guī)格說明書》理解不準確，使得軟件開發(fā)過程中和交付使用之后不斷出現(xiàn)用戶不期望出現(xiàn)的問題，軟件產品不能準確地按用戶的期望工作。
（2） 不嚴格按需求開發(fā)，自以為是。業(yè)務人員和技術人員由于知識背景各異，長期受到的訓練不同，有很多差別。業(yè)務人員在描述問題時常常根據當前的實際做法簡略描述，許多細節(jié)被忽略。
在實際開發(fā)中，個別開發(fā)人員可能對業(yè)務需求中的一些提法和做法不愿接受，覺得從技術角度看，換一種處理方式可能更合理、更簡單。因此，有時個別開發(fā)人員可能會在某些處理中按自己“更為合理”的理解去做，其結果是開發(fā)的產品不符合業(yè)務需求。
（3）不堅持原則，根據個別人的要求變動需求。業(yè)務需求是一個業(yè)務處理的全面約定，對需求的確認和修改是嚴肅的事情，不能隨意變動需求。在金融軟件開發(fā)實踐中，開發(fā)人員有時不能堅持這項原則，對業(yè)務人員的一些個別要求不經過管理程序就隨意答應。
結果是，最終提交的產品不符合《軟件需求規(guī)格說明書》的要求，其中變動部分有時連需求提出者和相關管理部門也不掌握。
3、解決的辦法
多換位思考，注意溝通的技巧
需求的復雜性是固有的，是無法避免的。每個人的知識都是有限的，所以不要苛求業(yè)務人員對IT技術非常精通，交流時盡量使用通俗用語而不是IT術語。在規(guī)定時間內，用有限的資源來保質保量地完成項目，讓業(yè)務部門滿意是開發(fā)部門的職責。
開發(fā)部門應當想盡一切辦法克服需求開發(fā)和需求管理過程中的困難，而不是找借口推卸責任。在與業(yè)務人員的溝通中，應當更多地從業(yè)務人員的角度考慮問題，應當盡量避免正面沖突，耐心傾聽意見，多問一問“您還有什么想法？”，
等業(yè)務人員把他的想法都表述清楚以后，開發(fā)人員可以迅速評估一下他們的建議，如果實現(xiàn)起來太困難，可以給業(yè)務人員一些更加中肯的提議，多用“您看這樣行不行？”、“這樣也可以達到同樣的目的”之類的語言。
當業(yè)務人員提出需求變更時，可以站在業(yè)務人員的角度來說明需求對整個項目的重要性，比如對項目進度的影響、對系統(tǒng)架構的影響、對系統(tǒng)穩(wěn)定性的影響以及對系統(tǒng)用戶的操作習慣的影響等。
當與業(yè)務人員的爭議不可避免時，項目經理一定要堅持原則。如果遇到爭議不下的問題，可以提交雙方部門領導進行裁決。
（1）業(yè)務培訓。由于金融領域的業(yè)務知識專業(yè)性非常強，因此完全有必要在項目初期，聘請既懂技術又懂業(yè)務的專家，組織開發(fā)人員進行有針對性的業(yè)務知識培訓，避免出現(xiàn)因不熟悉業(yè)務知識，而導致需求理解上的失誤。
（2）需求調研。需求調研有幾種方式，常見的有需求討論會和跟班作業(yè)。跟班作業(yè)是最有效的方式，但消耗資源較多，且受項目成本和項目時間的約束，很少有項目采用。召開需求討論會，是需求調研的常見做法。
會前應做好充分的準備，起草需求調查問題表，將調查重點鎖定在該問題表內，否則討論將會變得漫無邊際。在討論會上要耐心聆聽，同時要善于提問，并且要主導討論內容，否則將無法保證討論進度。問題表可以有多份，隨著調查的深入，問題表將不斷地被細化。
根據經驗，業(yè)務人員通常沒有耐心回答復雜的論述題，所以問題表應當以選擇題、是非題和簡答題為主。
（3） 需求評審。在需求整理完畢形成文檔以后，開發(fā)人員最好把自己總結的需求，向業(yè)務人員比較詳細地講解一遍。這種做法不僅能夠大大減少技術人員與業(yè)務人員在業(yè)務層面的歧義，還可以及時準確地發(fā)現(xiàn)潛在的問題。
開發(fā)部門和業(yè)務部門共同對需求文檔進行評審，雙方對需求達成共識后做出書面承諾，使需求文檔具有一定的約束力。即便因為業(yè)務變化，不得不對項目需求進行大的調整，以