學習寫需求分析
阿新 • • 發佈：2018-12-24
筆者本身是軟體工程專業出身，但是對如何寫需求分析仍然是一知半解，拿到需求，仍然不知道如何下手，才能達到寫需求分析的目的。
今天看到一篇文章，讓我受益良多，同時參考此文，筆者也嘗試寫了一個需求分析，一個小小的程式，居然寫了21頁，筆者自己都感到驚訝。
所以，我也來轉載一下此神文。
轉載之前，筆者還是列舉下自己在實際操作中碰到的一些問題：
1.UML類圖，類圖設計中的組合、聚合、複合等等一系列的關係其實是挺複雜，每次用，下次用還是忘，我就在想，這樣的類圖，如果是使用者來閱讀，能得到什麼。或者說，筆者還沒有真正的瞭解UML類圖的作用和寫法。
2.UML類圖，依然是UML類圖，比如有某個函式，我不知道將此函式，歸結到哪個物件內，似乎，放這個物件可以，放那個物件也可以。是否是對面向物件的設計還理解不夠深刻呢。
3.UML類圖，還是UML類圖，在這篇文章的最後部分，有列出，UML類圖也就是領域模型，是寫在每個功能塊兒之後的，那麼問題來了，如果我有兩個功能塊兒，都是使用到另一個功能塊兒，那麼這個另一個功能塊兒，應該拎出來單獨寫，還是前面兩個功能塊中，都要寫進入。反正筆者碰到的是個小程式，索性就把3個模組兒合到一起寫了。
4.狀態圖，本文中似乎寫，狀態圖不是必須，那麼，在文件中，狀態圖應該放在什麼位置體現。
5.行動圖，其實高階的流程圖，用於描述各個user-case之間是如何協調操作的。應該放在什麼位置寫。是否應該，整體和各個模組的地方，都應該有行動圖呢。
6.非功能模組，本文強調很重要，但，似乎並沒有描述到如何寫；
7.需求分析中，是否應該包含資料庫的設計，比如E -R圖之類的。
8最後，筆者認為還需要對，領域驅動設計，做深入的研究，這個似乎對使用者自己也不清楚需求是什麼的時候特別適用，也適用於敏捷開發。
好了，開始轉載，轉載地址來源於 http://blog.csdn.net/u014605728/article/details/50884289?locationNum=2&fps=1.
又到新年了，日曆又要從2011年翻到2012年了，這使我有太多的感慨，進而勾起了對太多往事的回憶。過去的10年，毫無疑問是中國軟體業發展最快的10年。當我們剛剛畢業的時候，還在使用VB、PB開發一些簡單的資料庫應用，而現在卻幾乎看不到它們的蹤影，換來的是諸如J2EE和.NET這樣的大型web應用。而這期間，RUP、XP、敏捷開發、持續整合••••••一個接一個的新概念層出不窮，令人眼花繚亂。現在想來，恍如隔世。
但更令我印象深刻而難以忘懷的，是我親自經歷的、親眼目睹的、道聽途說的一個又一個的軟體專案，它們有的獲得了成功，但更多的是令人沮喪的失敗。套用一下大文豪托爾斯泰體：幸福的家庭都是一樣的，不幸的家庭卻各有各的不幸；幸福的軟體專案都是一樣的，不幸的軟體專案卻各有各的不幸；或者說，成功的軟體專案都是一樣的，失敗的專案卻各有各的問題。我常常在想，我們的專案開發到底怎麼了，進而把它們一個一個的剝開來深入分析，竟然觸目驚心。它們有的是需求的問題，有的是客戶關係的問題，還有設計的問題、技術的問題、時間管理的問題、人員培養的問題••••••但歸根到底更多的還是需求的問題。需求分析既是一份體力活兒，更是一份技術活兒，它既是人際交往的藝術，又是邏輯分析與嚴密思考的產物。正是我們在需求分析過程存在的巨大隱患，最終導致了那麼多專案的失敗。也許你認為我在危言聳聽，好吧，我來舉幾個典型事例分析分析吧。
我的第一個故事來自大名鼎鼎的東軟。我在2005年接一個專案的時候，聽說這個專案之前是東軟做的。當時東軟在做這個專案的時候，整個過程經歷了10多次結構性的大變更，區域性性的調整更是不計其數。據說某天早上，客戶對某個功能不滿意，他們不得不對幾百處程式進行修改。之後客戶對修改的內容還是不滿意，又不得不將幾百處修改重新改回來。最後這個專案導致的結果是，整個這個專案組的所有成員都離開了東軟，並似乎從此不願涉足軟體開發領域。多麼慘痛的教訓啊！我常常聽到網友抱怨客戶總是對需求改來改去，但客戶對需求改來改去的真正原因是什麼呢？當我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，於是就在一點兒一點兒試，於是這種反覆變更就這樣發生了。如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什麼提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。
第二個故事來自我自己的專案，一個早期的專案。在這個專案中，客戶扔給了我們很多他們目前正在使用的統計報表，要我們按照報表的格式做出來。這些報表都是手工報表，許多格式既不規範，又很難於被計算機實現。這些報表令我耗費了不少腦細胞，直到最終專案失敗都沒法完成。這件事留給我的深刻教訓是，不能客戶怎麼說軟體就怎麼做。客戶提出的原始需求往往是不考慮技術實現，基於非計算機管理的操作模式提出來的。他們提出的很多需求常常比較理想而不切實際，畢竟人家是非技術的。但我們作為技術人員，需求分析必須實事求是的、基於技術可以實現的角度去考慮。那種“有條件要上，沒有條件創造條件也要上”的魯莽行事，結果必然是悲慘的。所以我們必須要基於技術實現去引導客戶的需求。同時，計算機資訊化管理就是一次改革，對以往手工管理模式的改革。如果我們上了資訊化管理系統，採用的管理模式卻依然是過去的手工模式，新系統的優勢從何而來呢？因此，我們做需求就應當首先理解現有的管理模式，然後站在資訊化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。
2007年，我參與了一個集團資訊化建設的專案。這個專案中的客戶是一個龐大的群體，他們分別扮演著各種角色。從機構層次劃分，有集團領導、二級機構人員、三級機構人員；從職能角色劃分，有高層領導、財務人員、生產管理員、採購人員、銷售人員，等等。在這樣一個複雜場景中，不同人員對這個專案的需求是各自不同的。非常遺憾的是，我們在進行需求分析的時候沒有認真分析清楚所有型別人員的需求。在進行需求調研的時候，總是集團領導帶領我們到基層單位，然後基層單位將各方面的人員叫來開大會。這樣的大會，各型別的人員七嘴八舌各說各自的需求，還有很多基層人員在大會上因為羞澀根本就沒有提出自己的需求。這樣經過數次開會，需求調研就草草收場。我們拿著一個不充分的需求分析結果就開始專案開發，最終的結果可想而知。直到專案上線以後，我們才發現許多更加細節的業務需求都沒能分析到，系統根本沒法執行，不得不宣告失敗。一個軟體專案的需求調研首先必須要進行角色分析，然後對不同的角色分別進行調研。需求調研的初期需要召開專案動員大會，這是十分必要的。但真正要完成需求分析，應該是一個一個的小會，1~3個業務專家，只討論某個領域的業務需求，並且很多問題都不是能一蹴而就完成的，我們必須與專家建立聯絡，反覆溝通後完成。需求分析必須遵從的是一定的科學方法，而不是盲目的大上快上。
我的最後一個故事可能典型到幾乎每個人都曾經遇到過。我們的專案從需求分析到設計、開發、測試都十分順利。但到了專案進行的後期，快到達最後期限時，我們將我們的開發成果提交給客戶看，客戶卻對開發結果不滿意，提出了一大堆修改，而且這些修改工作量還不小。怎麼辦呢？加班、趕工，測試時間被最大限度壓縮。最後專案倒是如期上線了，但大家疲憊不堪，並且上線以後才發現許多的BUG。需求分析不是一蹴而就的，它應當貫穿整個開發週期，不斷的分析確認的過程。以上這個事例，如果我們提早將開發成果給客戶看，提早解決問題，後面的情況就將不再發生。這就是敏捷開發倡導的需求反饋。敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證專案的成功。
以上的故事各有各自的不幸，各自都在不同的開發環節出現了問題。但經過深入的分析，各自的問題最終都歸結為需求分析出現了問題。為了使我們今後的軟體專案不會重蹈覆轍，似乎真的有必要討論一下我們應該怎樣做需求分析。
我們應當怎樣做需求調研：初識
在一個陽光明媚的下午，專案經理帶領著專案組成員，參加了客戶組織的見面會，一個新的軟體研發專案就這樣開始了。雙方在一種友好的氣氛中進行，相互寒暄，介紹與會人員，拉拉家常。逐漸地，會議開始進入了正題。初次接觸客戶，對於專案團隊意義重大。對方對你印象的好壞，今後如何與你交往，都在這個階段被確定下來。然而，在客戶至上的今天，與客戶保持適當的謙卑是有必要的，但過於的謙卑卻常常給專案日後的程序帶來風險。為什麼這麼說呢？過於的謙卑，處處都是諾諾諾，客戶說什麼就是什麼，就會使客戶變得非常強勢。這樣的結果就是，客戶提出了許多變態的、不太現實的、不合理的需求，而我們呢卻是一味地服從，客戶說什麼就是什麼。最後我們做得很累，結果卻不能讓客戶滿意。
正確的做法是，我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。這毫無疑問會形成一個良性迴圈，但要做到這一點並不容易，毫無疑問，在與客戶接觸初期的表現起到了極其關鍵的作用。
人與人交往，往往在接觸的初期就決定了相互的行為方式，與客戶交往也是一樣。起初的唯唯諾諾，客戶說啥就是啥，必然造成客戶不再關注你的意見，對你發號施令就可以了。相反，起初展現出一位技術專家的姿態，能大方而得體地提出自己的意見，會使客戶重視你的意見，甚至主動徵求你的意見。這一方面要求我們對自己要有足夠的自信，另一方面也要有循循善誘的表達能力。如果我們做到了這些，就會客戶心目中形成一種威信，使專案向著一種良性的方向前進。
同時，這樣的會議又是一個專案啟動會議。客戶方領導要在會議上傳達給與會代表一個清晰的訊號，那就是與會代表今後要積極配合我們完成今後的工作。這時候，我們要弄清，客戶方有哪些角色，誰是這些角色的需求提出者與決策者。這是什麼意思呢？在軟體專案中，特別是管理型軟體專案中，客戶都代表的是一個群體，而不是個人。他們代表的可能是一個單位、一個集團，甚至是一系列組織機構。在這樣一個群體中，他們按照職能被劃分成了不同的角色。拿一個單位來說，橫向可能劃分成不同的部門，財務部、銷售部、採購部、生產部••••••不同的部門，由於業務的不同，對軟體的需求自然是不同的，因此我們在進行需求調研的時候，什麼部門的需求就應當跟什麼部門談。同時，縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員，理解這些方面格外重要：
1. 高層領導
高層領導關心的是巨集觀的目標，因此軟體研發目標、巨集觀統計報表、決策支援功能，都應當與高層領導談。他們關係的都是巨集觀的問題，因此不要與他們談那些細枝末節；
2. 中層領導
中層領導關心的是具體的效益，即軟體給各個部門資訊化管理方面帶來的效益，因此，中層領導是各項業務流程、功能模組的需求決策者。他們關心功能的定義、業務流轉的銜接、查詢報表的設計，但不太關心一些具體的操作，以及一些具體業務流程的細節；
3. 基層人員
基層人員是每一項業務流程的操作者，也是軟體今後真正的使用者。他們是真正瞭解你所要開發的軟體的業務需求的領域專家，是你進行需求調研的重點物件。但是，基層人員往往受到自身視野的侷限，可能只清楚自己工作涉及的十分狹小的一個範圍，因此我們需要努力尋找那些業務涉及面廣，經驗豐富，又有一定大局觀的真正的專家。另外，他們就是軟體今後真正的使用者，讓他們參加，會讓他們成為今後軟體推行的忠實支持者，對其他操作人員的指導者，益處多多。而他們關心的則是每項操作的細節。
劃分清楚角色，弄清楚每個角色的需求提出者與決策者，就是為了在今後的需求調研中找對正確的人，使今後的調研工作事半功倍。另外，如果客戶方是一個集團、一個多組織機構的政府機關、事業單位，需求的多元化問題必須引起我們的足夠重視。什麼是多元化問題呢？比如同樣一個業務操作，在同一級別的A單位是這樣操作的，而在B單位卻是那樣操作的。需求的多元化往往會給今後的軟體開發帶來巨大挑戰。因此，我們要在需求調研階段降低軟體的多元化需求。要解決這樣的問題，首先應當從高層領導著手，提出規範化管理的口號。同時，在進行需求調研時，儘可能地召集各個單位的代表在一起開會討論。同時，應當有高層領導，或者指定一個負責人，在出現分歧的時候最終拍板決策。這些都需要在專案啟動的時候事先規劃好。
最後，與客戶方領導制訂出軟體目標，是相當重要但常常被我們忽視的一個步驟。軟體資訊化管理不是包治百病的神藥。很多專案的失敗都歸因與專案目標不明確造成的專案範圍的失控。因此，這時討論專案目標，既重要又適時。
也許在此之前我們已經做足了功課，對業務需求進行了一番詳細的整理，有了一大堆疑問急需解答。但是，在這時，不是解答具體問題的地方，這是我們常常會犯的一個毛病。在這樣一個會議上，我們應當詢問客戶方領導對這個專案的期望，渴望達到的專案預期，而我們應當描述的，是對達到這些預期的整體解決方案，凡此等等。
俗話說：萬事開頭難。如果你在專案開始的時候總感覺千頭萬緒不知如何著手，在這裡我給大家的三點建議：1）樹立良好的職業威信；2）進行詳細角色分析，將與會各方代表對號入座；3）從巨集觀上制訂目標與方案。隨後的工作，就是與各方程式碼建立聯絡，逐一拜訪他們，將需求調研工作一步一步進行下去。
我們應當怎樣做需求調研：拜訪
與西方人不同，中國人做事往往比較重視感情，這是與中國數千年的文化分不開的。讓我們來聽聽一位金牌銷售員是怎麼做生意的：“我跟客戶頭幾次見面，絕對不提生意的事，玩，就是玩。吃飯啦，唱卡拉OK啦，打球啦••••••先建立關係，關係好了再慢慢提生意的事兒。”這說得比較誇張，畢竟他是在做銷售，但至少傳達出一個概念，那就是做事先培養感情，感情培養起來才好慢慢做事，需求調研也是一樣。
需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作（假如專案還有後期維護）。在這漫長的時間裡，我們需要依靠客戶這個群體的幫助，一步一步掌握真實可靠的業務需求。不僅如此，技術這東西總有不如意甚至實現不了的地方，我們需要客戶的理解與包容，這都需要有良好的客戶關係。按照現在的軟體運作理念，軟體專案已經不是一錘子的買賣，而是長期的、持續不斷的提供服務。按照這樣的理念，軟體供應商與客戶建立的是長期共贏的戰略協作關係，這更需要我們與客戶建立長期友好的關係。
儘管如此，我們也不能總是期望客戶中的所有人都能與我們合作，很多專案都不可避免地存在阻礙專案開展的人。如很多ERP專案會損害採購和銷售人員的利益，因為資訊化的管理斷了他們的財路；很多企業管理軟體會遭到來自基層操作人員的抵制，因為它會給基層操作人員帶來更多的工作量負擔。有一次，我們給一個集團開發一套軟體，當我們下到基層單位時，才發現，一些基層單位已經有了相應的管理軟體。我們的軟體成功上線，必然就意味著這些基層單位的管理軟體壽終正寢，這必然影響到基層資訊化管理專員的利益和政績。
分析一個客戶人群的關係，就是在分析這個人群中，誰有意願支援我們，而誰卻在自覺不自覺地阻礙我們。那些通過這個專案可以提高政績，提高自身價值的人，都是我們可以爭取的盟友。他們是我們最可以依賴的人，我們一定要與他們站在一起，榮辱與共，建立戰略合作伙伴關係。
另一種人，即使軟體獲得了成功，也與他沒有太多關係，但你與他相處得好，卻可以給予你巨大的幫助，這種人是我們需要拼命爭取的人。所謂領域專家，他可以給你多講點兒，但隨便打發你，對他也沒太大影響。報著謙虛謹慎、相互尊重的態度，大方地與他們交往。當他們幫助我們以後，真誠地予以感謝。這是我總結出來的，與他們交往的準則。
最後，就是那些對我們懷有敵意的人。儘管有敵意，但我們能夠坦蕩的，敞開心扉的與他們交往。雖然不能奢望太多，但拿出誠意去爭取他們，也還是有機會化干戈為玉帛、化敵為友。如果能夠那樣，那是再好不過了。
經過一番交往，我們將逐漸在客戶中結識一批可以幫助我們的人。今後一段日子裡，我們將依靠他們去學習和認識業務知識，收集業務需求，為日後的軟體研發提供素材。
我們應當怎樣做需求調研：研討會
經過一番努力，我們終於在客戶中找到了一批人，可以解答困擾我們多時的業務問題了，真是不容易呀。但是，如何以合適的時間、合適的地點、通過合適的形式與客戶研討業務需求，是擺在專案經理面前的一道難題。在我所經歷的專案中，業務研討會沒有一個是相同的。
我曾經做過一個政府機關的專案，在這個專案中，從總局到省、地市、區縣，形成了一個多組織機構的管理系統。雖然全國管理流程大體相同，但各地因各地實際情況的不同、領導管理思路和政策理解的不同，管理模式在許多細節上存在著差異，也就是說，這個專案存在著需求個性化的問題。在專案進行之初，客戶方領導提前意識到這方面的問題，因此在組織需求研討時，分別從各個省市抽調業務人員，集中在一起進行研討。同時，在研討時，根據與會人員的業務特點，將他們分成若干個業務組，分別對某個相對獨立的業務模組的需求進行研討。採用這樣的組織形式，各地的業務差異在會上都會被提出來。一些地區不合理的管理模式，一經提出，就會得到其它地區業務人員的糾正，進而避免了不合理需求的提出。當然業務人員之間也會出現意見分歧。在會議啟動之時，高層領導就明確提出了必須形成全國統一版本。因此，一旦出現分歧時，業務人員就會通過激烈辯論、各抒己見，進而形成統一意見。如果分歧雙方誰都說服不了誰，業務組指定的組長則拍板採用哪個方案。如果他不能做出決定，就立即反映到總局領導那裡當場做出決定。採用這種集中式的研討，可以使問題的處理變得高效而及時。當然，也會因地區化差異而出現多個方案，每個方案都是合理的，我們必須在軟體中分別對其進行處理的情況。出現這種情況時，至少我們很容易理清楚有幾種情況，有沒有可以合併的地方，使得差異最小化，最終在軟體維護中體現出來，讓客戶自己去選擇自己的管理模式。
另外，將業務人員劃分為多個業務組也是一項比較成功的經驗。由於業務人員自身的侷限，不可能對所有業務領域的細節全面掌握，往往總是有自己熟悉的部分，也有自己不熟悉的部分。劃分業務組，可以讓業務人員分別在自己最熟悉的業務範圍內參與討論，可以有效提高業務討論的質量。同時，一個管理系統涉及的業務是複雜而系統的，如果劃分成多個模組並行地進行業務討論，也可以大大提高業務研討的工作效率。這個專案採用這種方式，使這個專案在執行數年後依然能保持統一的版本，而不至於形成一個一個的地方版本。統一的版本使得軟體的升級維護成本大大降低，使專案進入良性的進化、完善的迴圈中。
以上講的是一種集中式的業務研討形式。採用這是形式固然好處多多，但並非所有軟體專案都能夠採用這種模式。我參與過的另一個專案就沒有如此幸運了。在這個專案中，雖然也是多組織機構管理系統，但總公司對各分子公司的管理是鬆散的，所以很難組織各地的業務代表集中在一起討論，甚至不能要求各分子公司採用統一的管理模式。企業資訊化的目的就是要建立統一的、規範化的管理形式，它本身就是一場企業管理的變革。我們的軟體，如果不能規範各分支機構的管理，抑制個性化差異，而是照貓畫虎地一家一家為分子公司做軟體，不僅我們的成本是巨大的，客戶的資訊化管理效果也不能發揮出來，而且為日後的執行維護帶來巨大的隱患。毫無疑問，它是我們做管理軟體的一個雷區，我們必須小心應對。
起先，總公司領導帶著我們一家一家地去分子公司開需求研討會。每個需求研討會，我們都要著力注意各個單位管理模式的差異。當業務代表在描述自己業務流程的時候，我們常常提示業務代表，×××公司是這樣管理的。這時候，業務代表會思考，採用×××公司的管理模式是否會更好，或者採用×××公司的管理模式行不行。如果他提出×××公司的管理模式可能會出現什麼什麼問題時，我們也會著力記錄下來，下次再和×××公司討論，他們是不是會出現這些問題。
採用這種分散式的業務研討形式，讓我們作為外人來規範客戶的管理模式，常常會有這樣那樣的不便，但這也是我們可能面對得最多的需求研討形式。在這樣的形式中，尋找一個典型範例也許可以算是一種最佳實踐。當我們面對管理鬆散的多組織機構時，尋找一個管理規範、對我們的支援度高的分支機構，首先將他們的資訊化系統建立起來，產生預期的效益，這就樹立了一個範例。它的成功就會為其它分支機構帶來一種精神動力和成功案例，照著做肯定不會錯。這樣就可以更容易地說服其它分支機構，摒棄現有的管理模式而朝著規範化管理邁進。
業務研討形式比較容易出現的另一個問題，就是將各個方面的業務代表拉過來開大會。在大會上，你說你的，我說我的，雜亂無章，一些重要的需求被不經意地漏掉。遇上這樣的情形，專案經理應當有清醒的認識，我們需要再下來開小會。銷售部門的需求跟銷售部門談，採購部門的需求跟採購部門談••••••既然是小會，每次談的時候人不在多，在精，參會的業務人員對自己的業務瞭解精細而全面。這樣的會議，通常有一至三個業務人員，和一個負責人（負責拍板）參加。會議之後，我們最好詢問與會人員的聯絡方式，便於日後建立長期的聯絡，畢竟業務需求不是一蹴而就的事情。同時，如果我們今後採用的是迭代式開發，他們也就成為了我們業務驗證的客戶代表。
業務研討會是重要的，但同時又是靈活的，沒有一個定式，甚至有時都不能稱之為會議。專案經理需要根據實際情況，合理地與客戶組織研討會。但不論怎樣組織，必須注意兩點：有效抑制個性化差異、分模組組織專項研討會。
我們應當怎樣做需求調研：需求研討
前面我們探討了業務研討會應當怎樣組織，下面我們再具體討論一下我們應當怎樣與客戶討論業務需求。如果說組織業務研討會是專案經理的功底，那麼討論業務需求就是需求分析人員的功底。以往我們常常認為，需求分析是一件最簡單的事情。客戶說他們需要做一個什麼軟體，有些什麼功能，我們照著做就可以了，所謂的需求分析員就是需求的記錄員。我要說，這是一個極大的錯誤，許多失敗的軟體專案，或者說軟體專案中的需求問題，大多都源於此。經過人們多年的研究發現，在需求分析過程中，客戶存在的最大問題就是提不出正確的需求，這表現為幾種形式：
1. 由於對軟體不瞭解，客戶提不出需求，不知道軟體最終會做成什麼樣子。這類客戶在需求討論過程中，往往只能描述目前自己手工管理的方式是怎樣的，不知道計算機會怎樣管理。
2. 能提出一些業務需求，但當軟體做出來擺在自己面前時，需求就變了。這類客戶，他們能熟練使用電腦，對資訊化管理是清楚的。他們提出的業務需求從整體上應當是八九不離十的。但是，由於沒有實物，在軟體中的一些具體操作並沒有完全想清楚。因此，當軟體真正做出來擺在自己面前時，甚至經過一系列流程操作以後，會對一些操作提出變更需求。他們正如那句經典的話說的：“I have changed when it saw it.”
3. 能非常詳細地提出業務需求，甚至有時候該怎麼做的提出來了。這類客戶，參與過很多軟體資訊化建設，甚至有些還是軟體開發的半專業人士。但是他們提出的業務需求過於具體，甚至怎樣實現都說出來了，但這些有時候不是最佳設計方案、可能在技術上難於實現，甚至有些就是過於理想化而不可實現。
因此，我在進行需求研討的時候，首先跟客戶探討的不是軟體功能，而是客戶現有的業務知識，用專業的話叫“業務領域分析”。客戶現有的業務流程是什麼樣的，都有些什麼操作？客戶在業務中都有些什麼事物，什麼專用名詞，都是怎樣定義的，相互之間的關係是什麼？客戶在每一項操作中的目的是什麼，為什麼要這樣做，他們製作的手工報表都說明了什麼問題？後面我會更加詳細地描述怎麼進行業務領域分析。
在認識了客戶的業務領域之後，我們才能去分析他們提出的所有原始需求。他們為什麼要提出這項需求，提這項需求的目的是什麼？只有經過這樣的分析，我們才能深刻地理解需求，進而運用我們的專業知識，提出更加合理的技術方案。但非常遺憾，我們在需求分析中常常不是這樣做的，甚至當軟體都開發出來了，需求分析人員都說不出客戶為什麼要提出這個需求，更談不上了解業務操作流程。一句經典的話是：“客戶讓我們這樣做的。”
總之，我們做需求分析，眼界不能僅僅停留在軟體本身，應當更開闊一些，應當擴充套件到跟這個業務有關的那些領域知識中。
當然，另一個極端就是為了開發軟體，無限地擴大學習領域知識的範圍。為了開發財務軟體去考會計師，為了開發稅務軟體去學習稅法等等。開發軟體不是讓我們成為這個領域的專家。我們學習領域知識是為了更好地理解和開發軟體，是學習與這個軟體有關的領域知識，而不是成為一個專家。
在客戶提出的所有原始需求中那些與業務實現有關的需求都是無效的需求，它們僅僅只能作為我們的一個參考。什麼是與業務實現有關的需求呢？比如要求做成什麼介面，資料要求怎樣處理，等等。為什麼是無效的呢？因為客戶畢竟是非專業，我們應當有這種自信，在理解客戶真實意圖以後，能夠提出比客戶更優的解決方案。
還有一些是技術難於實現或者根本就無法實現的需求，我們應當耐心地說服和引導客戶，並給他提出一個更加合理的方案。注意最後一句話：“給他提出一個更加合理的方案”。蒼白的拒絕客戶往往會讓客戶產生抵觸情緒，但當我們提出一個更加合理的方案時，客戶往往會欣然接受，當然這是在我們對客戶提出的業務需求的真實意圖進行深入分析之後。認識到這一點非常重要，為了更加清楚地說明這一點，我舉一個我的例子吧。有一次我給客戶做一個價格管理系統時，客戶提出要做一個動態報表的需求。這個動態報表要求能讓客戶從無到有，完全自由的定製自己的報表。毫無疑問，這是一個典型的不切實際的業務需求。接到這個需求以後，我們將它作為一個疑問，在整個需求調研過程中著力進行了考察，明白了客戶為什麼提出這樣的需求。當客戶在向他們的客戶報價時，他們的客戶在各個方面都要求他們報出價格細目，而且不同的客戶要求他們報的價格細目格式還不一樣。但經過仔細分析，發現他們面對的客戶就是固定的幾家，而這幾家的要求的報表雖然格式不盡相同，但其資料項大體是相同的。最後，我們給客戶提出兩個方案，一個是按照客戶所說的動態報表，但要求客戶在製作報表時必須能夠詳細設計報表中資料項的來源、專案的型別，以及繪製報表格式，讓他們意識到，即使做出來，作為非專業的他們也是很難自己完成的。同時，我們提出另一個方案：我們為客戶準備好他們需要填寫的各種客戶報表所需的所有資料項，讓他們自由刪減。同時，為他們的不同客戶提供各自相應的報表模板，這些模板可以在少量的範圍內進行修改，以此滿足他們的客戶的不同需要。當客戶拿到這樣的方案，既能滿足他們自己的需要，還操作簡便、易懂、不費事，當然就欣然接收啦。
因此，需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。
我們應當怎樣做需求調研：迭代
前面我一直在反覆強調這樣一個觀點，需求分析不是一蹴而就的，是一個反覆迭代的過程。它將從第一次需求分析開始，一直持續到整個專案生命週期。為什麼這樣說呢？讓我們一起來分析分析。在第一次的需求分析階段，我們在一段時期內需要與客戶進行反覆地討論，這個過程往往是這樣一個反覆迴圈的過程：需求捕獲->需求整理->需求驗證->再需求捕獲••••••
需求捕獲，就是我們與客戶在一起開研討會，討論需求的活動。客戶可能會描述他們的業務流程，這時我們在紙上繪製簡單的流程草圖，及時地記錄下來；客戶在描述業務的同時，可能會反覆提到一些業務名詞，詳細詢問這些名詞的含義，以及它們與其它名詞的關係，用類圖或者物件圖繪製簡單的草圖；客戶在描述業務的同時，還會提出今後的軟體希望實現的功能，如能夠展示某個報表、能夠匯出檔案，以需求列表的形式記錄下來。一個功能，在需求列表中會有多個需求，而每個需求應當能夠用1、2句話，在20個字以內就可以描述清楚。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設計，是我們的每項功能必須實現的內容。需求列表是需求驗證以及日後的使用者驗收測試的依據，不論我們今後如何分析和設計這些功能，都要能如實地實現這個列表中提出的需求。（需求列表應當如何編寫，將在後面的章節詳細描述。）
需求整理，就是在需求研討會後，需求分析人員對研討內容的分析和整理的過程。首先，需求分析人員應當通過用例模型，劃分整個系統的功能模組，以及各個模組的業務流程。用例模型分析是一個由粗到細的過程，這樣一個過程也是符合人類認識世界的思維習慣的一個過程。最先，我們應當對整個系統繪製用例圖，設計用例場景，並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行一個整體的角色分析，繪製一個角色分析圖，進行一個流程分析，繪製一個流程分析圖（可以是傳統的流程圖、UML中的行動圖，甚至一個簡單的示意圖，等等）。
然後，我們再在整體用例圖的基礎上，依次對每個用例繪製用例圖。每個用例圖中，會更細緻地劃分出多個用例，並依次進行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細化，直到我們認為需求已經描述清楚為止。
在一個系統中，用例需要細化幾次，是由這個用例的業務複雜程度決定的。對於一個簡單的用例，只需要細化一次就夠了；而對於比較複雜的用例，則需要細化2~3次，甚至更多。
用例分析的過程，之所以稱之為分析，它摻入了很多需求分析人員對業務的理解與設計：模組如何劃分、流程如何設計、業務如何轉換，等等。用例分析，還需要讓需求分析員與架構師、設計師等技術人員共同協作來完成，因為用例分析還包含對業務需求的技術可行性分析。只有一份可行的需求分析，才能為後續的設計開發掃清障礙，有效降低專案風險。最後，需求分析員應當將需求列表中的內容，逐一地與用例進行核對，以避免分析人員忽略使用者的某項業務需求。（後面將詳細描述用例模型的搭建過程。）
在用例分析的同時，需求分析人員還需要對業務中的相關事物，製作領域模型。領域模型，是對使用者業務領域中相關事物、相互關係、相互行為操作的描述，它是以物件圖和類圖的形式表達的。需求人員對領域模型的分析，對業務理解的深度，對日後軟體的設計，以及軟體的功能擴充套件、升級演化，都起到了至關重要的作用。（後面將更加詳細地講述領域模型。）
最後，當我們完成了一系列的分析整理並形成文件以後，應當對及時地與客戶進行反饋，確認我們的理解是否正確，也就是需求驗證工作。需求驗證工作應當貫穿整個研發週期，並且在不同時期表現出不同的形式。首先，在需求分析階段，需求驗證工作表現為對需求理解是否正確的資訊反饋。需求分析人員與客戶再次坐在一起，一項一項描述我們對需求的整理和理解，客戶則時不時地對一些問題進行糾正，或者更加深入地加以描述。我們則認真地記錄，回來整理，並等待下一次的驗證。在需求分析後期，我們還可以製作一些簡單的原型，更加形象地描述我們對需求的理解，會使我們與客戶的溝通更加順暢。隨後的設計開發階段，我們則應當以迭代開發的形式進行。每開發完一個迭代週期，將開發的成果與客戶反饋。這樣做的結果是，客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小。之後，當開發進入到驗收測試階段，我們則是與客戶一道，一項一項地驗證我們的軟體是否滿足需求列表中要求的業務需求。最後，當軟體迎來下一次升級開發時，我們將開啟另一次輪迴。
因此，需求分析就是按照這樣的過程，每次多理解一些，再多理解一些，更多理解一些，逐漸深入的過程。每深入一步，我們的軟體就更接近客戶的滿意。
我們應當怎樣做需求調研：需求捕獲
前面我們討論了，需求分析工作是一個迭代的過程：需求捕獲->需求整理->需求驗證->再需求捕獲······需求捕獲是這個迭代過程的開始，也是整個需求分析工作中最重要的部分。沒有捕獲哪來後面的整理與驗證工作？但是，非常遺憾，按照我以往的經驗，需求捕獲是我們最薄弱的環節。前面我提到的許許多多專案開發的問題都可以歸結為需求分析的問題，而許許多多需求分析的問題又都可以歸結為需求捕獲不完整的問題。需求捕獲是整個需求分析工作中最難把握的一個部分，它不僅僅是一個技術的問題，還涉及到人際交往、溝通、知識理解，以及心理學等一系列問題。但更讓我感到遺憾的是，在我讀過的許許多多關於需求分析的書籍中，討論需求分析與建模的書很多，但討論需求捕獲的書籍卻寥寥無幾。確實，要討論這部分內容，真的已經遠遠超出了軟體開發這個知識領域。那麼，在軟體需求捕獲過程中，最根本、最容易犯錯的問題是什麼呢？我認為是一個態度的問題，是採用主動態度去捕獲需求，還是採用被動的態度去捕獲需求。如果需求分析人員總是諾諾諾，客戶說什麼，我們就記什麼。客戶處於非常強勢的地位，給我們提出了非常多變態、技術難於實現的需求，而我們的需求分析人員卻成為記錄員，埋頭記錄客戶說的每一句話，不加分析地就直接扔給了開發人員。這就是採用被動的態度去捕獲業務需求的方式。毫無疑問，這樣的需求分析必然將給專案開發的後期帶來巨大的風險。
為什麼會出現這樣的情況呢？經過深入分析我們會發現，從客戶嘴中說出來的需求，只是整個軟體需求中的冰山一角，還有兩類需求需要我們自己去挖掘：客戶嘴中沒有說出來的需求，和客戶壓根兒就沒有想到的需求。
什麼是客戶嘴中沒有說出來的需求，並不是客戶故意賣弄官子不願說出來，而是在客戶所在業務領域已經約定俗稱，在他們看來已經是天經地義，根本就不用說出來的業務規則。然而，作為剛剛涉足該領域的需求人員，他們是不瞭解這些規則的。如果採用被動的方式去僅僅記錄客戶說出來的需求，毫無疑問會遺失這部分需求，這就是為什麼直到專案後期，軟體被研發出來即將交付使用，客戶才提出說這不是我想要的軟體，並提出大量變更需求的原因。這時，我們常常問客戶，你們為什麼不早說呢？而客戶卻十分委屈，這麼簡單的道理還需要我說出來嗎？
舉例說明吧：在我從事的稅務行業中，對納稅人徵收的稅種包括增值稅、企業所得稅。增值稅通常是按月徵收的，而企業所得稅是按季或者按年徵收的。就拿增值稅來說吧，稅款所屬期是開票日期的上個月，為什麼呢？納稅人往往是在上個月產生銷售收入，然後在下個月完成申報和繳納稅款。這些知識對於稅務人員來說是太基本的常識了，所以在他們看來就是天經地義而不需要說出來的業務規則。但作為軟體開發人員的我們卻常常因為不知道而將業務弄錯。
如何破解這樣的問題呢？那就是要求我們在需求分析的整個過程，不斷進行業務領域知識的學習。在我做需求訪談的初期，我往往不是跟客戶談需求，而是先跟客戶談業務。你們是怎樣操作的？都經過些什麼流程？誰來完成這些操作的？為什麼這樣操作？注意，在所有這些問題中，最後一個問題是最重要的。客戶業務領域中的所有操作、所有流程都是有它存在的意義的，它體現了其內部的原因與作用。多問為什麼，可以讓我們深入地理解這些領域知識，站在客戶的視角去思考問題，進而深入地理解客戶為什麼要提出他們的那些業務需求。當一個需求分析員能達到這樣的水平，客戶嘴中沒有說出來的需求就會被源源不斷地被髮掘出來，最終做出來的需求分析才是完整的、準確的。
另一種就是客戶壓根兒沒有想到的需求。也許你會提出這樣的疑問，客戶壓根兒沒有想到的需求我們還提出來做什麼？這種壓根兒沒有想到的，實際是在業務需求階段壓根兒沒有想到的，並不代表最終都沒有想到。很多開發人員總在埋怨，說客戶需求總是在軟體專案的後期改來改去，為什麼？客戶並不是軟體研發領域的專業人員。在業務需求階段，由於沒有可以展示和操作的實物，客戶總是在空對空的憑空想象今後的軟體應當做成什麼樣子。這就註定了客戶會有很多自己壓根兒沒有想到的需求。那麼為什麼他們會在軟體研發的後期提出來呢？因為軟體研發的後期，客戶能拿到那些研發成果的實物，去操作，可以看到。這時候，很多他們起初沒有想到的需求就會源源不斷地被提出來。但這時候，我們作為研發人員會很傷，我們付出的代價會很大。所以，以被動的態度去完成需求分析工作，必然會給專案研發帶來巨大的風險。
如何解決這樣的問題呢？首先，在需求分析階段，雖然客戶壓根兒沒有想到，但需求分析人員是軟體研發領域的專業人員，他們應當在深入理解業務領域與需求的基礎上，通過分析提前發現這些需求。作為需求分析人員，他們應當站在客戶的角度去思考，我們的軟體應當設計成什麼樣子，每個需求的真實意圖是什麼。站在這個基礎上，再運用專業知識去整理、分析與設計。我前面談到，客戶描述的最原始的需求是編寫在需求列表中的，而經過需求分析人員的整理、分析與設計，經過用例分析、領域建模，最終形成產品需求說明書（或稱為產品規格說明書）。從需求列表到產品需求說明書，這之間要經過一段長長的路，這段路就是我們的分析與設計，而不是簡單的記錄與編寫文件。只有經過這樣的過程，最後得到的才是高質量的需求分析，才能有效地指導軟體研發，避免專案的風險。所以說，好的需求分析人員就是軟體專案的司命，掌握著專案的生死。
我們再換一個角度來分析，客戶之所以提不出需求，關鍵就在於他們沒有可以展示和操作的實物，總是在空對空的憑空想象今後的軟體應當做成什麼樣子。我們能否改變這樣一種現狀呢？於是，迭代式的需求分析與開發就出現了。我們先用最短的時間先做一個可以展示和操作的原型給客戶看，讓客戶提一些意見。然後我們再在這個原型的基礎上再多做一些，再給客戶看。我們就這樣一步一步推進，直到最終專案研發結束。採用這樣的方式，最適合那些客戶在專案初期提不出什麼需求，也沒用合適的參照物來進行需求分析的軟體專案，特別是那些資料分析與決策類的軟體專案。
接下來，我們再回到那些從客戶嘴裡說出的需求。在需求分析人員中，比較普遍的一個看法就是，只要是從客戶嘴裡說出來的，就一定是對的，我們必須照著做的，這種看法是不正確的。因為客戶在軟體開發方面是非專業的，所以他們在提出需求的時候往往會考慮不夠周全。有一次，客戶在提出來一系列業務操作以後，最後提出了一個統計報表的功能。這個統計報表是從前面這一系統操作資料中統計出來的，因此我們就對這些業務操作及其結果資料進行了一個詳細的分析，最後發現根據這些資料統計出來的資料存在很多的問題，甚至可能出現相互矛盾的地方。隨後我們與客戶就這些問題進行了深入地探討，最終客戶不得不承認，他當初在設計這個報表的時候考慮不周全。在提出問題的同時，我們又提出了我們的解決方案，這是非常關鍵的。當我們提出我們的合理化建議以後，客戶欣然接受了。同時，客戶對我們這種非常專業的分析與處理過程大加讚賞，無形中也提高了我們在客戶心目中的威望。
不僅如此，客戶作為一個群體，客戶與客戶之前對同一問題也可能存在不同的看法，這特別突出地體現在那些多組織機構的管理系統中。因此，對於一些客戶非正式的場合提出的需求我們要仔細甄別。一個比較可行的方法就是，先在一些非正式的場合單獨跟客戶聊，產生第一手資料，最後將這些需求在比較正式的場合，如各部門參加的業務討論會、有使用者代表參加的需求評審會、需求定稿簽字確認會等等，以比較正式的形式討論和確定下來。
最後，我不得不說，企業資訊化管理實質就是一次改革，是企業摒棄手工操作，向資訊化建設邁進的一次改革。既然是改革，就必須要改變過去不合理的管理流程，向更加合理和高效的管理流程邁進。因此，我們的需求捕獲最初是源於企業現有的操作流程，但當我們深入理解了客戶現有的操作流程以後，應當有意識地發現那些不合理的部分，並最終提出更加合理、更適於資訊化管理的流程。如果需求人員能上到這樣一個高度，我們的需求分析就進入了一個更加嶄新的層面（關於需求分析中的流程分析，我們還會在後面詳細探討）。
我們應當怎樣做需求分析：功能角色分析與用例圖
在我們進行一系列需求調研工作的同時，我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析。當下一次開始進行需求調研時，我們應當首先將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答。這就是一個需求捕獲->需求整理->需求驗證->再需求捕獲的過程。但是，當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以後，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有一個統一和有效的方法，往往採用想到哪裡做到哪裡的方式。一些問題想到了就做了，沒有想到則忽略掉了。實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何一個