和困難
(1)在溝通過程中,開發(fā)方與需求方雙方工作范圍沒有具體明確,急需雙方共同確定職責范圍。軟件開發(fā)方、軟件需求方雙方在項目開展過程中負責什么樣的具體工作,不應該負責哪些工作,互相之間沒有明確,導致工作責任不明確,出現(xiàn)問題后互相推卸[6] 。
(2)軟件開發(fā)方、軟件需求方雙方各類人員的職責權利關系需要互相申明。比如是否上下屬關系或者其他關系以及相互調遣權限。
(3)存在的突出問題是:軟件需求方部分需求不能完整確認。由于軟件需求方管理層人員的變動和管理決策的變化而導致項目需求有經(jīng)常性變化[7] 。軟件需求方不同部門的管理不統(tǒng)一,導致軟件需求在具體相關部門前期開發(fā)調研的內容和后期試用時得到的需求內容有較大差別,甚至產(chǎn)生沖突[8] 。
(4)軟件開發(fā)方作為進駐的定制項目,開發(fā)方需要軟件需求方的大力支持和幫助,所以在遇到困難時迫切需要尋求軟件需求方相關人員的幫助,軟件開發(fā)方、軟件需求方雙方溝通過程中,軟件開發(fā)方人員強烈感覺到軟件需求方內部人員結構復雜,部門間以及部門和領導間的關系有待理順。
3.2 通常獲取需求的方法
(1)獲取需求的來源:需求主要來自客戶、合作伙伴、最終用戶以及該領域的專家等幾個方面。而通常需要掌握如何準確判斷需求應來源于哪方面,誰是最真實的需求者,如何接近這些來源并從中獲取信息。
(2)獲得需求的方式:主要有現(xiàn)場考察、訪談、集體討論、電話詢問、問卷調查或者閱讀用戶編制的相關文件等。
(3)常規(guī)需求文檔:其中每項工作都應該有相應的記錄文檔。如查閱了大量資料的內容與格式、各種應急防御措施、統(tǒng)計分析報表、系統(tǒng)規(guī)劃書、舊系統(tǒng)業(yè)務狀況、歷史資料等,而其中在訪談過程中了解到的操作員的應用感受、技術交流與討論以及其他各種形式的交互式討論和分析等的記錄報告,所有這些最終都需要體現(xiàn)在一份詳盡的需求說明書中。
3.3 在項目開發(fā)中,逐步提出針對以上問題的解決方案
(1)本文認為,在初期常規(guī)的需求分析階段,要求需求分析人員必須充分了解用戶的目標與工作過程,設身處地替用戶考慮問題,幫助用戶將模糊的需求清晰化,將簡略的需求明細化、完善化,將混亂的需求邏輯化、條理化。因此,本項目采取的比較有效的做法就是從團隊中篩選一名經(jīng)驗豐富(包括深厚的業(yè)務和技術背景、善于溝通、能吃苦)的隊員擔任需求工程師,在前期分析階段駐扎在客戶公司,他的工作主要是界定項目的范圍和需求變更管理,通過各類規(guī)范的模板文檔來體現(xiàn)需求內容以及需求變更。其目的就是根據(jù)項目目標列表,在初步整理需求初稿的基礎上,請業(yè)務部門專門進行分析提出修改需求意見,以及在最初階段最終確認。由于軟件需求方和軟件開發(fā)方的背景不同,對同一問題的理解存在差異,這些差異如果不能在需求的最初階段盡量彌合,那么必然導致需求增加與需求更改。
(2)任何項目都有需求變更與需求增加,這是IT項目中令人很頭疼的問題。隨著客戶對需求可實現(xiàn)度的理解,IT項目客戶的需求變更要比其他類型的項目變更多得多。所以,一方面我們必須將這種變更盡早完成在初期常規(guī)需求分析階段,所使用較多的技術手段是模型法,讓客戶了解可能具有的功能。但另一方面,除了在需求收集階段需要盡可能將需求細化、在后續(xù)階段在不影響進度的前提下滿足用戶的變更需求外,還需要在適當?shù)碾A段盡量凍結一些不急需的需求,才不至于使項目陷入一種十分糾結的狀態(tài)。當然,這還涉及后期需求增加的費用以及支付方式和客戶達成共識的問題。
(3)整個項目下來,感覺到需求分析書不僅僅是初期常規(guī)需求階段的一個成果,它更是整個開