從頭讀下來，第一眼看到，成功的軟件都是一樣的，失敗的軟件卻各有各的失敗處，我們編寫程序的最終目的是什么，不是讓別人知道自己編程能力有多厲害，只要能賣錢就好了，就算你使用的語言已經跟不上版本了，但是最終結果實現了就行，而我們失敗的軟件問題是什么沒有人在乎，只有自己，我們的軟件出了什么問題，它們有的是需求的問題，有的是客戶關系的問題，還有設計的問題、技術的問題、時間管理的問題、人員培養的問題??????但歸根到底更多的還是需求的問題。需求分析既是一份體力活兒，更是一份技術活兒，它既是人際交往的藝術，又是邏輯分析與嚴密思考的產物。正是我們在需求分析過程存在的巨大隱患，最終導致了那么多項目的失敗，所以，軟件需求的分析十分的重要。

作者的親身實例告訴我們，需求是多么的重要，改了百十行代碼，東家不滿意，又得改來改去，結果小組的人最終只得罷工，這似乎是軟件工程程序員的通病，所以很多人不樂意進行代碼的設計，但是，，“客戶對需求改來改去的真正原因是什么呢？當我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，于是就在一點兒一點兒試，于是這種反復變更就這樣發生了。如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最后做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什么提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂于接受的，變更也變得可控了”。原文作者自己是如此總結的，所以說，軟件需求分析對于一個程序員來說是多么的重要，只有真正明白了別人心中想要的程序，才能做出來最完美的程序。

　　　　但是，又不能被客戶的需求牽著鼻子走，畢竟我們是專業人士，對自己的本職工作還是比別人了解的，我們知道如何才能真正實現一個軟件，如果一味地聽從東家的，不一定會成功，軟件需求分析是我們做的，我們作為技術人員，需求分析必須實事求是的、基于技術可以實現的角度去考慮。那種“有條件要上，沒有條件創造條件也要上”的魯莽行事，結果必然是悲慘的。所以我們必須要基于技術實現去引導客戶的需求。

　　　　再說，一個軟件項目的需求調研首先必須要進行角色分析，然后對不同的角色分別進行調研。需求調研的初期需要召開項目動員大會，這是十分必要的，做程序分析是事無巨細的，一旦程序完成，在更改角色就比登天還難，所以在任何情況下，都要做好完美的調查，但真正要完成需求分析，應該是一個一個的小會，1~3個業務專家，只討論某個領域的業務需求，并且很多問題都不是能一蹴而就完成的，我們必須與專家建立聯系，反復溝通后完成。需求分析必須遵從的是一定的科學方法，而不是盲目的大上快上。

我們應當怎樣做需求調研：初識

我們對客戶提出的需求進行深入理解以后，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利于開發的可行方案，降低開發的風險

我們應當怎樣做需求調研：拜訪

需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作（假如項目還有后期維護）。在這漫長的時間里，我們需要依靠客戶這個群體的幫助，一步一步掌握真實可靠的業務需求

我們應當怎樣做需求調研：研討會

業務研討會比較靈活，應該合理組織，一定要注意兩點：有效抑制個性化差異、分模塊組織專項研討會

我們應當怎樣做需求調研：需求研討

與客戶探討業務需求，對一些技術難以實現的需求，我們應當提出合理的解決方案

?

轉載于:https://www.cnblogs.com/anjiu/p/7612228.html

總結

以上是生活随笔為你收集整理的阅读笔记，软件需求分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。