elasticsearch入門系列">elasticsearch入門系列
836
2022-05-29
十年來國內軟件工程方面的進展有目共睹,在軟件需求方面,我們看到在大多數組織中已經建立起了一級或兩級需求體系(業務需求和軟件需求);在某些組織中,需求分析員已經成為一種專門的職位;甚至在某個大型國有商業銀行已經成立一個專門的部門來負責需求分析工作。應該來說,這是一些非常可喜的進步。
然而,目前大多數的項目參與者都對需求工程的現狀不滿,這又是為什么呢?首先,我們必須承認市場快速變化而帶來的需求變化的確對項目帶來了很大的挑戰,為此許多項目應用了迭代化開發來應對這樣的變化。但根據我們對客戶的訪談,更多的需求變化是由于需求溝通不力造成的,也就是說,參與需求溝通的各方并沒有達成真正的共識,這又是什么原因呢?根據我們的分析,這主要是由于缺少一個可以被各方真正理解和溝通、并可以被逐步精化的需求體系。
目前,大多數用戶采用的需求體系基本上是沿襲了結構化分析的文檔體系(包括數據流圖,數據字典等)。這種文檔體系起源于70年代,當時,軟件的主要應用還是科學計算或信息處理,理解需求的人往往也受過結構化分析的相關教育,然而這些內容對今天的大多說業務人員或最終用戶而言就是很難理解的了。這里的主要問題是分析代替了需求。為了解決這個問題,有的組織引入了非形式化、非結構化的業務需求,然而卻很難在兩種需求之間建立明確的對應關系,從而出現了業務人員/最終用戶認可業務需求,但開發人員覺得不夠詳細;開發人員認可軟件需求,但業務人員/最終用戶無法給與確認。
那么,我們如何解決這一軟件需求的困境呢? (待續)
軟件開發
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。