又到新年了，日曆又要從2023年翻到2023年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb、pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而這期間，rup、xp、敏捷開發、持續整合••••••乙個接乙個的新概念層出不窮，令人眼花繚亂。現在想來，恍如隔世。
但更令我印象深刻而難以忘懷的，是我親自經歷的、親眼目睹的、道聽途說的乙個又乙個的軟體專案，它們有的獲得了成功，但更多的是令人沮喪的失敗。套用一下大文豪托爾斯泰體：幸福的家庭都是一樣的，不幸的家庭卻各有各的不幸；幸福的軟體專案都是一樣的，不幸的軟體專案卻各有各的不幸；或者說，成功的軟體專案都是一樣的，失敗的專案卻各有各的問題。我常常在想，我們的專案開發到底怎麼了，進而把它們乙個乙個的剝開來深入分析，竟然觸目驚心。它們有的是需求的問題，有的是客戶關係的問題，還有設計的問題、技術的問題、時間管理的問題、人員培養的問題••••••但歸根到底更多的還是需求的問題。需求分析既是乙份體力活兒，更是乙份技術活兒，它既是人際交往的藝術，又是邏輯分析與嚴密思考的產物。正是我們在需求分析過程存在的巨大隱患，最終導致了那麼多專案的失敗。也許你認為我在危言聳聽，好吧，我來舉幾個典型事例分析分析吧。
我的第乙個故事來自大名鼎鼎的東軟。我在2023年接乙個專案的時候，聽說這個專案之前是東軟做的。當時東軟在做這個專案的時候，整個過程經歷了10多次結構性的大變更，區域性性的調整更是不計其數。據說某天早上，客戶對某個功能不滿意，他們不得不對幾百處程式進行修改。之後客戶對修改的內容還是不滿意，又不得不將幾百處修改重新改回來。最後這個專案導致的結果是，整個這個專案組的所有成員都離開了東軟，並似乎從此不願涉足軟體開發領域。多麼慘痛的教訓啊！我常常聽到網友抱怨客戶總是對需求改來改去，但客戶對需求改來改去的真正原因是什麼呢？當我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，於是就在一點兒一點兒試，於是這種反覆變更就這樣發生了。如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什麼提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。
第二個故事來自我自己的專案，乙個早期的專案。在這個專案中，客戶扔給了我們很多他們目前正在使用的統計報表，要我們按照報表的格式做出來。這些報表都是手工報表，許多格式既不規範，又很難於被計算機實現。這些報表令我耗費了不少腦細胞，直到最終專案失敗都沒法完成。這件事留給我的深刻教訓是，不能客戶怎麼說軟體就怎麼做。客戶提出的原始需求往往是不考慮技術實現，基於非計算機管理的操作模式提出來的。他們提出的很多需求常常比較理想而不切實際，畢竟人家是非技術的。但我們作為技術人員，需求分析必須實事求是的、基於技術可以實現的角度去考慮。那種「有條件要上，沒有條件創造條件也要上」的魯莽行事，結果必然是悲慘的。所以我們必須要基於技術實現去引導客戶的需求。同時，計算機資訊化管理就是一次改革，對以往手工管理模式的改革。如果我們上了資訊化管理系統，採用的管理模式卻依然是過去的手工模式，新系統的優勢從何而來呢？因此，我們做需求就應當首先理解現有的管理模式，然後站在資訊化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。
2023年，我參與了乙個集團資訊化建設的專案。這個專案中的客戶是乙個龐大的群體，他們分別扮演著各種角色。從機構層次劃分，有集團領導、二級機構人員、**機構人員；從職能角色劃分，有高層領導、財務人員、生產管理員、採購人員、銷售人員，等等。在這樣乙個複雜場景中，不同人員對這個專案的需求是各自不同的。非常遺憾的是，我們在進行需求分析的時候沒有認真分析清楚所有型別人員的需求。在進行需求調研的時候，總是集團領導帶領我們到基層單位，然後基層單位將各方面的人員叫來開大會。這樣的大會，各型別的人員七嘴八舌各說各自的需求，還有很多基層人員在大會上因為羞澀根本就沒有提出自己的需求。這樣經過數次開會，需求調研就草草收場。我們拿著乙個不充分的需求分析結果就開始專案開發，最終的結果可想而知。直到專案上線以後，我們才發現許多更加細節的業務需求都沒能分析到，系統根本沒法執行，不得不宣告失敗。乙個軟體專案的需求調研首先必須要進行角色分析，然後對不同的角色分別進行調研。需求調研的初期需要召開專案動員大會，這是十分必要的。但真正要完成需求分析，應該是乙個乙個的小會，1~3個業務專家，只討論某個領域的業務需求，並且很多問題都不是能一蹴而就完成的，我們必須與專家建立聯絡，反覆溝通後完成。需求分析必須遵從的是一定的科學方法，而不是盲目的大上快上。
我的最後乙個故事可能典型到幾乎每個人都曾經遇到過。我們的專案從需求分析到設計、開發、測試都十分順利。但到了專案進行的後期，快到達最後期限時，我們將我們的開發成果提交給客戶看，客戶卻對開發結果不滿意，提出了一大堆修改，而且這些修改工作量還不小。怎麼辦呢？加班、趕工，測試時間被最大限度壓縮。最後專案倒是如期上線了，但大家疲憊不堪，並且上線以後才發現許多的bug。需求分析不是一蹴而就的，它應當貫穿整個開發周期，不斷的分析確認的過程。以上這個事例，如果我們提早將開發成果給客戶看，提早解決問題，後面的情況就將不再發生。這就是敏捷開發倡導的需求反饋。敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證專案的成功。
以上的故事各有各自的不幸，各自都在不同的開發環節出現了問題。但經過深入的分析，各自的問題最終都歸結為需求分析出現了問題。為了使我們今後的軟體專案不會重蹈覆轍，似乎真的有必要討論一下我們應該怎樣做需求分析。
我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴充套件用例
我們應當怎樣做需求分析：行**和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：乙個需求列表的例項
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會
我們應當怎樣做需求分析
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用vb pb開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如j2ee和.net這樣的大型web應用。而...
讀《我們應當怎樣做需求分析》後
閱讀部落格 我們應當怎樣做需求分析？發表一篇閱讀筆記，說明本學期 軟體需求與分析 需要掌握哪些必要的內容？針對每個內容點說出自己的理解，並繪圖標意相互之間的關聯關係。讀了 我們應當怎樣做需求分析 後，我認為本學期 軟體需求與分析 應該掌握以下幾點 一 需求調研 需求調研是需求分析最重要的一部分，原文...
《我們應當怎樣做需求分析》閱讀筆記
通過閱讀 我們應當怎麼做需求分析 一文，我了解了需求分析的基本步驟和一些方法 1 需求調研 如何與客戶交流 建立聯絡 研討業務需求，捕獲需求 2 需求分析 功能角色分析 業務流程分析與業務領域分析，用例分析及用例圖，查詢報表分析，原文分析，非功能需求 3 需求確認 需求列表,需求例項，快速原型法，需...