瘋狂的訂餐系統-軟體需求分析挑戰之旅 【轉】
阿新 • • 發佈：2018-12-31
摘要：
說教性質的需求分析理論，各位看了也白看，所以咱們就來一個真實個案——“訂餐系統”體驗一下。
“訂餐系統”貌似簡單，但陷阱重重，各種需求分析的經典場景將會一一重現，各位做好準備接受這個挑戰沒有？
特別宣告：
如需轉載此文，請給出指向本網站的連線，如下：
作者：張傳波
摘自：http://www.umlonline.cn
如不能按此要求，請不要轉載此文。 1.1某IT公司員工的吃飯問題 咱們出來幹活的，天天需要吃午飯，所謂“午飯吃不好，工作幹不好”。某IT公司深知這個道理，為了讓大家方便吃午飯，由公司統一訂餐，並且費用全包。 這樣的做法，大家當然開心了，不過行政部的同事就要辛苦一點，每天要“服侍”大家吃飯，我們看看怎樣個做法：
圖1 背景、需要、需求規格
對於功能性需求，我們往往會描述成用例圖。
圖2 用例圖
對於非功能性需求，往往會對系統穩定性、效能、相容性等提出要求。
什麼是背景？
背景這東西比較籠統，簡單地說就是這個專案的來由，我們需要用說故事的方式講清楚專案的背景。
什麼是需要？
需要就是客戶真正想要的東東，是高層次的需求，我們可以把需要解決的問題、關鍵涉眾、專案的目標、範圍、專案成功標準等全部統稱為需要。
什麼是需求規格？
需求規格是很細級別的但又沒有細到詳細設計程度的需求了，描述出系統與使用者是如何互動的，系統要滿足怎樣的一些非功能要求。
需求分析過程，無非就是由背景到需要到需求規格的過程，這個過程是螺旋前進的。需求分析中最難解決的問題往往就是搞不清需求之根源，把握不清背景和需要，往往就會被繁瑣的需求規格所困住，被客戶牽著鼻子走。理論是完美的，現實是殘酷的，我們現實的需求分析工作，往往會出現這些問題：
圖3 某需求規格說明書目錄
1.3 背景-需要-需求規格
請按順序回答以下問題：
1.本專案的背景是怎樣的？
2.本專案能解決什麼問題？
3.本專案的關鍵涉眾有哪些？（說明：涉眾是指系統會影響到的人、角色、單位等，或者說什麼人、角色、單位會影響到本系統。）
4.本系統要達到怎樣的目標？
5.本系統的範圍是怎樣的？
6.本系統應該具備怎樣的功能？
7.本專案成功標準是怎樣的？
在往下閱讀之前，請先獨立思考，寫出以上問題的答案。
1.本專案的背景是怎樣的？
參考答案：員工中午飯要吃好是很重要的事情，但手工訂餐存在一些問題，領導試圖通過訂餐系統來改善。
答案點評：
1)本系統的使用者是“員工”，而客戶是“領導”。（說明：使用者是指使用系統的人員，而客戶是可以拍板付錢給公司的那個人，是專案組的米飯班主。）
2)領導的目的不是為了做這個系統，而是希望通過這個系統解決問題。
3)領導應該不太可能投入大的投資來解決這個問題，例如：不太可能將員工的午飯標準提高到每人每餐50元，也不太可能為這個專案投入100萬的經費。
背景應該怎樣描述？
背景應描述出系統的使用者和客戶是誰、專案的來源，並且可以由此推斷客戶可能的投資預算，本專案對於客戶的重要程度等。
2.本專案能解決什麼問題？
參考答案：
1)手工訂餐本身工作效率低，有時會影響員工的正常工作。
2)手工訂餐容易出錯，導致員工吃不到飯或者是吃不到自己想吃的飯。
答案點評：：
1)問題描述得很具體，並且問題產生的根源似乎都是因為“手工訂餐”導致的。
2)手工訂餐並不會讓大家吃不到飯，只是有時會出一些小問題。
3)手工訂餐的最大優勢就是靈活，不好的地方就是容易出錯，這個訂餐系統如何才能保持手工訂餐的“靈活”優勢呢？
問題應該怎樣描述？
需要清楚明確地描述清楚專案解決的問題，同時要分析好當前的工作方法的優點。系統除了要解決當前的問題，還應該保持原來工作方法的優點。很多系統解決了問題，但丟失了原來工作方法的優勢，往往是得不償失。
3.本專案的關鍵涉眾有哪些？
參考答案：員工、前臺、領導、財務、餐廳。
答案點評：
1)全面考慮了各種涉眾。
2)員工是使用本系統的主體，他們最關鍵的需求應該是能方便準確地訂餐。
3)前臺通過本系統來統計訂餐、和餐廳溝通、下訂單等，前臺可能是本系統使用功能最多、操作最複雜的角色。
4)領導有時也會通過本系統來訂餐，但對本系統的主要要求就是大家要用得舒服。
5)財務可能需要根據本系統的訂餐記錄和餐廳結帳。
6)餐廳需要提供選單給前臺，餐廳可能以傳真或電話的方式獲知我們的訂餐，不同的方式將會影響本系統的某些功能。
如果找出關鍵涉眾？
1)應廣度優先地儘量多地列出可能的涉眾。
2)列出每種涉眾在本系統的關鍵需求。
3)每一種涉眾都應該清楚說明本系統是如何影響她的，以及她是如何影響本系統的。
4.本系統要達到怎樣的目標？
參考答案：達到“吃飯易”的效果，保證員工不會因為吃飯問題影響正常工作。
答案點評：
1)目標描述應簡單容易記憶，以便專案組隨時記住。
2)本專案的目標並不是讓員工吃飯吃得開心，也不是用來保證員工正常工作（光靠這個系統，是不能保證員工正常工作的），而是希望通過本系統來消除手工訂餐的問題。
應該如何描述目標？
應該用簡單、明確、恰如其分的語言來描述。簡單、明確是方便專案組記憶，以便在工作中隨時可以用目標檢驗工作。恰如其分則要求目標描述不要誇大系統的作用，也不要縮小系統的作用。很多專案描述目標的時候，往往會誇大系統的作用，如提高工作效率、提高生產力等，這些目標往往不是單純靠系統就可以做得到的，更多是靠企業的管理，系統只是起到配合和支援的作用。
5.本系統的範圍是怎樣的？
參考答案：
1)這是一個訂餐系統，只考慮與訂餐相關的功能。
2)這是一個單獨的系統，不考慮與其它系統整合或互動。
3)使用本系統的是本公司的全體員工，不考慮分公司的員工。
答案點評：
從功能、與其它系統的關係、使用者三方面描述了本系統的範圍。
應該如何描述範圍？
範圍往往客戶並不會直接給出的，我們需要從專案解決的問題、目標等入手，從功能、與其它系統的關係、使用者等來思考系統的範圍。
由前面的資料，我們可以知道，客戶應該不會投入很多錢，客戶目標只是希望解決手工訂餐帶來的麻煩，所以我們定範圍時，應該儘量讓系統簡單，能滿足目標便可。本系統其實可以做得很複雜的，訂餐這事情其實與請假外出相關的，訂餐也會與財務結帳有關係，如果將系統邊界擴大，很可能將問題複雜化。
6.本系統應該具備怎樣的功能？
參考答案：
圖4 用例圖
對於“訂餐”這個用例，我們還可以進一步細化使用者與系統的互動：
使用者指示訂餐
系統給出選單
使用者選擇選單並確認選擇
系統儲存使用者的選擇，提示訂餐成功。 答案點評： 1)用例圖全面地描述了系統使用者與用例，條理清晰、一目瞭然。 2)對於每一個用例，還可以進一步描述使用者與系統是如何互動的，為下一步工作做好準備。 3)除了描述功能，還需要考慮系統的非功能需求，如效能要求、安全性要求等。 應該如何描述功能？ 1)要根據前面的問題匯出系統應具備的功能以及非功能需求。 2)用例圖是描述功能性需求的好工具，但不要拘泥於只用用例圖。 3)對於非功能性需求，客戶往往沒有具體想法，需要我們從客戶的需要出發，定出具體的非功能性需求。 7.本專案成功標準是怎樣的？ 參考答案：用簡單的方式達到目標的要求，達致雙贏。 答案點評： 1)“簡單”意味著成本低，符合雙方利益。 2)達到目標要求是真正的客戶所需。 如何考慮專案的成功標準？ 我們做一個專案，成功標準並不是為了賺錢，更加不是不惜一切謀取最大利益，雙贏才是最重要的原則！對於客戶來說，首要目標就是要滿足他的需要，然後就是合理的預算，對於軟體公司來說，首要目標就是為客戶提供高性價比的解決方案，賺取合理利潤。要達致雙贏，客戶的成熟度是很重要的，但更重要的是軟體公司的成熟度，專案組需要以專家、顧問這樣的高度來解決專案中的問題，引導雙方達至雙贏。 以上7個問題，問題1是背景相關的問題，問題2、3、4、5是需要相關的問題，問題6是需求規格相關的問題，而問題7是我們需要認真考慮的問題，考慮清楚專案的成功標準才能更好地指導專案後續工作，提高專案成功概率。 1.4 沒完沒了的“新需求” 由於你的徹底而深入的需求分析工作，訂餐系統進展非常順利，很快就上線運行了！但問題也就來了，客戶陸陸續續提出了以下問題： 1)要經過好幾個頁面才能進入訂餐頁面，不太方便，希望能在首頁直接進入訂餐頁面。 2)一次只能定一天的餐，不太方便，希望一次能定多天的。 3)我有時選了一個菜，前臺卻說這個菜沒有了！ 4)能不能提供多家餐館選擇？ 5)訂餐標準才8元，現在物價都漲了，能不能提高一下標準？ 6)能不能直接連到餐館的網頁上去看菜式？ 7)能不能做口味分析和營養分析？ 系統能用起來，問題肯定多多，沒問題反而說明沒有人用這個系統，所以有問題是好事，但問題多了又會讓人很煩躁，改來改去沒完沒了啊，專案的成本也會持續上升。 你準備如何招架呢？在繼續閱讀之前，請你逐一分析上述問題並提出解決方案，要寫下來奧！ 下面我們來逐一分析上述問題。 1)要經過好幾個頁面才能進入訂餐頁面，不太方便，希望能在首頁直接進入訂餐頁面。 2)一次只能定一天的餐，不太方便，希望一次能定多天的。 我們首先要思考，這兩個要求背後的需要是什麼呢？這兩個問題都是在實際使用訂餐系統中產生的，使用者提出這樣的要求無非是希望系統更加好用更加方便，訂餐系統無非是要方便大家訂餐、減少訂餐時間，故這兩個要求應該予以滿足。 系統上線後，使用者往往會提出很具體的修改要求，這些要求往往是易用性方面的問題，如：介面佈局、操作方式、文字表達、排序條件等細節問題，這些問題不解決的話會降低使用者體驗，此類問題一般應儘量解決。 前期對專案的需要把握得比較好的話，軟體基本上是能符合使用者的需要的，哪怕使用者提出了一些易用性方面的要求，一般也是很容易修改的。不過誰也不能保證對需要的理解沒有偏差，有可能系統上線後才發現理解錯了客戶的真正需要，這時修改系統的話一般來說工作量會比較大，但原則上應該給予修改，雙贏是專案的目標，客戶關鍵需要沒有滿足，專案不能算成功。 3)我有時選了一個菜，前臺卻說這個菜沒有了！ 5)訂餐標準才8元，現在物價都漲了，能不能提高一下標準？ 會什麼會有選了菜但沒有這個菜的問題呢？是軟體的bug嗎？ 原來餐廳的選單會定期更換，前臺會及時更新訂餐系統的選單，但問題是餐廳修改選單並不是很準時，而且修改後又不一定能及時通知前臺，導致有時會出現員工按照老選單訂餐，但實際上餐廳已經修改了選單的情況。 第二個問題是午餐標準的問題，明顯不是系統的問題，但使用者還是提出來了，他們難道不知道不是系統的問題嗎？為什麼還要對我們提出來？是不是希望我們向公司領導反應問題？ 軟體有些問題，並不是軟體本身的問題，而是管理的問題。要用好一套系統，必須配套相應的管理辦法，很多管理的問題軟體是不能解決的。第一個問題，要改善的話則需要加強對餐廳的管理，讓他們及時送上更新後的選單；而對於第二個問題，則需要公司檢討訂餐標準是否合適了。 專案組遇到客戶提出這類問題時，不要因為不是軟體問題就事不關己，應主動分析問題並提供適當的解決方案，很多問題只需要在管理上稍微改善一下，問題就可以立馬解決。 4)能不能提供多家餐館選擇？ 為什麼使用者希望選擇多家餐廳呢？有人喜歡吃辣菜，有人喜歡吃粵菜，有人想吃粥粉面，就算是同一個人也會今天喜歡這個明天喜歡那個，如果能有多家餐廳可供選擇，則更能滿足大家的口味了。大家能吃到自己喜歡的午餐，更有利於大家做好工作，從這點看似乎這個要求是滿足需要的，我們應該予以滿足。 要實現這點，軟體自然要費點周折去修改，但問題遠遠沒有這樣簡單，管理上會變得麻煩很多：前臺需要從多家餐館獲取選單，要管理多家餐館；財務要對多家餐館進行結帳；更麻煩的是，有些餐館要訂餐數量多才會送餐，如果哪天某餐館點的餐不夠多，還需要選擇了這個餐館的員工重新訂餐。這樣複雜的管理，軟體應該如何來適應呢？ 看來如果寄望通過修改軟體來滿足這個要求，就會陷入一個“無底洞”，似乎無論怎樣做都難以滿足要求。實際專案中，經常會遇到這類問題，這時一定要認真地分析：
圖5 需求分析高手
需求分析能力的提高，依靠長期的積累，長期的實踐！以下是一些建議：
1)不要以為學過了一些需求分析知識，就以為自己很厲害，也不要用這些大道理來指導專案組工作，不僅對專案組毫無實際幫助，還會幫倒忙。
2)不要一畢業就直接投身需求分析的工作，最好還是從編碼開始，另外也可以考慮做測試、實施。
3)要不斷地積累業務知識、技術知識。
4)學習面向物件分析、面向物件設計，並在實際工作中運用，面向物件分析與設計的方法，會從本質上提高你發現問題、分析問題、提煉問題、解決問題的能力。從這點上說，從開發開始是最好的選擇。
5)把握一切能提高你表達能力與理解能力的機會，和別人溝通要及時表達出你對別人說話的理解，平時多寫文章、部落格之類的，提高你的書面表達能力。
6)為什麼強調要有豐富的管理和被管理的經驗呢？訂餐系統中其實我們看到很多跟管理相關的問題，很多問題是需要管理辦法去解決的，缺乏管理和被管理的經驗，就會難以理解客戶的問題，更加是無從從管理上提出具體的解決辦法。
需求分析是榨乾人腦汁的活，超具挑戰性的工作！要站在比客戶更高的角度把握住客戶的需要，然後將客戶的這些需求轉化為軟體可實現的需求規格，與此同時還需要為客戶提供與軟體相匹配的管理意見。你做好準備迎接這樣的挑戰了嗎？
1.7 變被動為主動
大部分情況下，需求分析的工作總是比較被動的，總會有點被客戶牽著鼻子走的感覺，為什麼會這樣呢？看看下圖：
這個圖表示了隨著專案的開展，客戶與專案組對本專案的需要的認知程度是怎樣變化的，橫軸是時間，豎軸是對需要的認知程度。這個圖說明了這些問題：
1)專案最開始時，客戶對需要認知程度比較高，而專案組只是有朦朧的認識。
2)隨專案的開展，客戶和專案組都逐步提高了認識。
3)整個專案開展過程中，客戶對需要的理解程度總是比專案組要高。
以上該圖反應了絕大部分專案的情況，這樣的專案客戶對需要的理解永遠領先於專案組，這樣專案就不可避免地會陷入被動的境地。專案組做出來的東西往往不是客戶真正想要的，要反覆多次，但做出來後，客戶又會繼續有新的要求，周而復始，沒完沒了，客戶和專案組都相互不滿對方的表現，最終專案很可能是“雙輸”。
如果是下面這個圖呢？
在專案初期，客戶對需要的理解程度是比專案組要高的，但專案組的學習能力比較強，對需要的理解很快就超越了客戶，並且在後面持續領先於客戶。
按照這樣的曲線，專案成功的機會是很高的，只要專案組對需要的理解領先於客戶，就能化被動為主動，最終達到雙贏！
很多公司會接手很多新專案，這些專案之前是沒有什麼積累的，保證這類專案成功的關鍵，就是要提高專案組的整體水平，人的水平是決定因素，不要指望什麼用過程大框框能改善專案情況，更加不要指望那些半桶水的QA來監督專案組。
下面這個圖呢？
什麼情況下會是這樣？
產品化的專案！
產品化的專案才是公司持續盈利之道，所有公司都需要積累自己的業務與技術知識，將專案產品化。但凡產品化的專案，專案組對需要的理解要比客戶深刻很多的，客戶會很崇拜你、認可你，在專案開展過程中，專案組要不斷地去提高客戶的業務水平，同時學習專案中特有的產品中沒有的東西，將這些新內容提煉到產品中來，為下一個專案服務。
變被動為主動的奧妙就在此！提高需求分析能力沒有捷徑，努力提高水平吧！
1.8最後的瘋狂
訂餐系統的故事還沒有結束，過了一段時間，大家的抱怨陸續又來了！
來自員工的抱怨：
有些員工覺得A餐廳好吃，有些又覺得B餐廳好吃。
有些喜歡吃辣，有些喜歡吃湯粉湯麵之類的。
有些一會喜歡這個，一會喜歡那個。
很多員工強烈要求支援多家餐廳！
有些員工想自己帶飯回來吃，但公司不會給予午餐補助。
前臺的抱怨：
員工有時向她抱怨餐廳送餐慢，她也沒辦法，已經催了n次，換了幾家餐廳了。
不太同意要支援多家餐廳，她的管理工作會麻煩很多，而且有些餐廳訂餐少的話不會送餐的。
多家餐廳時，需要維護多家餐廳的選單，而且每家餐廳的選單更新時間不一樣。
財務的抱怨：
不太同意支援多家餐廳，因為財務需要每家餐廳都提供發票，而不是每家餐廳都能提供發票的，除非我們願意出更多的錢。
開發人員的抱怨：
不是吧，這班人這麼難服侍，還有需求變更啊…
支援定多天的餐和支援多家餐廳其實是有矛盾的，而且也很難實現！
領導的抱怨：
這麼簡單的訂餐系統，怎麼搞得這麼複雜！
我的這麼美好的想法，居然惹下這麼大的麻煩
另外一個領導的抱怨：
員工在辦公室內吃飯，搞得辦公室氣味怪怪的。
有些員工還不講究衛生，把桌子、地面弄髒又不搞乾淨！
你準備如何應對呢？
往下閱讀之前，請你運用前面所學的知識認真全面深入地思考，以上問題的根源是什麼呢？為什麼訂餐系統的問題會沒完沒了呢？
或許本不該上這樣的系統，每一種解決方案都不會解決全部的問題，而且都會帶來新的問題，投入這麼多到底值不值？
下面這個解決方案又如何呢？
1.所有員工的午餐標準提升到每日10元，無論是否在公司，每月都按22.5工作日提供補貼。
2.公司中午休息時間由1小時延長到1.5小時，調整上午下班與下午上班時間，與其它公司“錯峰”。
3.公司不再統一訂餐，也不允許員工在自己座位上吃午飯，公司指定吃午飯場所，讓專人負責清潔。
第一點措施提高了員工的福利，這措施應該是很受員工歡迎的，也可以抵消員工因為不能公司統一訂餐帶來不便而引發不滿情緒，當然如果補貼標準更高員工會更高興。
第二點措施，中午上下班時間儘量與別的公司“錯峰”，這樣可減少擠電梯還有在餐館排隊等候的時間，這也是很實在的措施。
至於第三點是用來解決衛生問題的，本來如果所有人都非常高尚，是不會有這樣的問題的，但至少短期內不可能讓所有人都高尚，指定場所和專人負責清潔是當前最有效的解決衛生問題的辦法了。
其實很多大企業不會統一訂餐的，也不會讓員工在辦公區內吃東西，好像有點不人性化，其實也是有道理的。
折騰了這麼久，結局原來是這樣？真是不勝唏噓啊！需求分析過程是一個很考驗人很折騰人的過程，好好總結本文所列舉的各種情況，做好準備繼續接受下面的挑戰吧！
後話
關於《軟體需求分析挑戰之旅》
本人目前正在撰寫《軟體需求分析挑戰之旅》，而“瘋狂的訂餐系統”將會是本書的開始章節（至少目前是這樣規劃，呵呵），希望通過這個“瘋狂的訂餐系統”讓大家很快地抓住需求分析的核心內容，能馬上用於實戰，而不需要啃完整本書。
在本論壇發表“瘋狂的訂餐系統”，無非就是小試牛刀，看看大家的反應如何，同時也為將來書的發售打打廣告
一、為什麼要寫《軟體需求分析挑戰之旅》一書？
需求方面的問題，從來就是每個專案的老大難問題，本人經歷過n個專案的磨練，深知其苦！關於需求方面的書籍也不少，但大都跟你講道理、講理論，開始還會覺得有點意思，但最終發現難以指導你實際的工作，解決你的具體專案問題，最終還是要靠自己想辦法去解決，久而久之我也有自己的一套經驗心得了。
於是我就有了寫這本書的想法，本書不會空講道理空講理論，全部都是真刀真槍的例項，“瘋狂的訂餐系統”就是用這樣的風格寫出來的，如果參加過“需求開發挑戰之旅”沙龍的朋友，會更加了解到我的講課風格和實用性。
二、《軟體需求分析挑戰之旅》有什麼特色？
1)實用為王
本書絕不拋書包，案例一個接一個。很多書也會有案例，但往往是單獨成文，而本書的案例貫穿全文，每個案例進行了提煉和擴充套件，內容安排精細，逐步講解和剖析，務求每一句話都給讀者帶來實實在在的收穫。
2)激發思考
希望本書是一部引人入勝的小說，吸引著大家去看，吸引著大家去思考。書中會列出很多問題，激發讀者的思考，並要求讀者寫下答案後再往下看，讀者經過思考再繼續閱讀，將會給你更大的震撼和收穫。
3)精簡易懂
不少書為了顯示出其價值，基本上是厚厚的，其中不乏拼湊的內容，有些甚至是通過加大行距來增加頁數。
本人將盡量控制文字數量，但不會減少內容，更加不會放入垃圾內容。精簡的好處就是書可以做得更薄，這樣書的成本更低；另外一個好處就是大家不需要啃這麼多文字，更加容易消化。
要保證易讀性，文字數量就可能不能太小。一些書籍確實寫得很淺顯，有些甚至用擬人法、虛擬角色等方法來寫，目的就是讓書本更生動更好讀，但我覺得還是過於羅嗦，其實有辦法做到文字少又易讀的。
4)有內涵
這本書出來後，如果被人罵之“膚淺”，那真是羞死人了！
我將竭盡全力寫好，傾注我的全部智力！
三、《軟體需求分析挑戰之旅》有什麼內容？
本書主要講解需求分析的內容，還會講解需求管理的內容。需求分析也叫做需求開發，是指獲取、分析、提煉客戶的需求，並用這些需求來指導軟體開發的工作。需求管理指的是和客戶協調、確認需求，控制和管理需求變更的工作。需求分析、需求管理的工作，本書將會統稱為需求方面的工作。很多書將做好需求管理列為改進需求方面的工作的主要方面，我不以為然，我認為需求分析至少佔80%的比重，而需求管理最多隻佔20%比重，兩者還不能割裂開來，必須互相配合才能妥善解決專案需求方面的問題。
以下是本書的內容大綱：
1.瘋狂的訂餐系統
1.1 某IT公司員工的吃飯問題
1.2 需求分析大道路
1.3 背景-需要-需求規格
1.4 沒完沒了的“新需求”
1.5 領導“突發奇想”
1.6 榨乾人腦汁的需求分析
1.7 變被動為主動
2.端正你的認識
3.你具備需求分析的基本素質嗎？
4.工欲善其事，必先利其器
5.如何做專案的需求分析？
6.如何做專案的需求管理？
7.如何做產品的需求分析？
8.如何做產品的需求管理？
9.讓需求在專案組中同步
10.提煉需求-提升公司競爭力
說明：本大綱只是暫定的，隨時會修改和細化的，歡迎大家提出建議。
四、誰適合看《軟體需求分析挑戰之旅》？
只要你感興趣，你就適合看！當然如何你有相關的工作經驗，看本書將會更加震撼和有收穫；如果你是學生，將會讓你見識到真實而又讓你震驚的需求分析世界，瞭解到具體實在的實戰經驗，為將來工作做好準備。
五、《軟體需求分析挑戰之旅》什麼時候發售？
目前我只能說盡快，期間歡迎大家在本網站多多發表，我將吸取大家的精華到本書中。
如需轉載此文，請給出指向本網站的連線，如下：
作者：張傳波
摘自：http://www.umlonline.cn
如不能按此要求，請不要轉載此文。 1.1某IT公司員工的吃飯問題 咱們出來幹活的，天天需要吃午飯，所謂“午飯吃不好，工作幹不好”。某IT公司深知這個道理，為了讓大家方便吃午飯，由公司統一訂餐，並且費用全包。 這樣的做法，大家當然開心了，不過行政部的同事就要辛苦一點，每天要“服侍”大家吃飯，我們看看怎樣個做法：
- 文員每天都要向餐廳索取最新選單，然後拿著選單找每個人確認今天吃什麼。
- 大家都確認後，文員以電話或者傳真的方式，向餐廳訂餐。
- 餐廳送來午飯，文員通知大家，然後大家來取餐。
1)本專案解決了客戶的什麼問題？
2)本專案涉及到什麼人、什麼單位？
3)本專案的目標是什麼？
4)本專案的範圍是怎樣的？
5)本專案的成功標準是什麼？
以上這些內容，我們稱之為客戶的“需要”。
圖1 背景、需要、需求規格
對於功能性需求，我們往往會描述成用例圖。
圖2 用例圖
對於非功能性需求，往往會對系統穩定性、效能、相容性等提出要求。
什麼是背景？
背景這東西比較籠統，簡單地說就是這個專案的來由，我們需要用說故事的方式講清楚專案的背景。
什麼是需要？
需要就是客戶真正想要的東東，是高層次的需求，我們可以把需要解決的問題、關鍵涉眾、專案的目標、範圍、專案成功標準等全部統稱為需要。
什麼是需求規格？
需求規格是很細級別的但又沒有細到詳細設計程度的需求了，描述出系統與使用者是如何互動的，系統要滿足怎樣的一些非功能要求。
需求分析過程，無非就是由背景到需要到需求規格的過程，這個過程是螺旋前進的。需求分析中最難解決的問題往往就是搞不清需求之根源，把握不清背景和需要，往往就會被繁瑣的需求規格所困住，被客戶牽著鼻子走。理論是完美的，現實是殘酷的，我們現實的需求分析工作，往往會出現這些問題：
- 背景啊背景，我該如何寫你呢？
- 目標在哪裡？
- 需求規格優先
圖3 某需求規格說明書目錄
1.3 背景-需要-需求規格
請按順序回答以下問題：
1.本專案的背景是怎樣的？
2.本專案能解決什麼問題？
3.本專案的關鍵涉眾有哪些？（說明：涉眾是指系統會影響到的人、角色、單位等，或者說什麼人、角色、單位會影響到本系統。）
4.本系統要達到怎樣的目標？
5.本系統的範圍是怎樣的？
6.本系統應該具備怎樣的功能？
7.本專案成功標準是怎樣的？
在往下閱讀之前，請先獨立思考，寫出以上問題的答案。
1.本專案的背景是怎樣的？
參考答案：員工中午飯要吃好是很重要的事情，但手工訂餐存在一些問題，領導試圖通過訂餐系統來改善。
答案點評：
1)本系統的使用者是“員工”，而客戶是“領導”。（說明：使用者是指使用系統的人員，而客戶是可以拍板付錢給公司的那個人，是專案組的米飯班主。）
2)領導的目的不是為了做這個系統，而是希望通過這個系統解決問題。
3)領導應該不太可能投入大的投資來解決這個問題，例如：不太可能將員工的午飯標準提高到每人每餐50元，也不太可能為這個專案投入100萬的經費。
背景應該怎樣描述？
背景應描述出系統的使用者和客戶是誰、專案的來源，並且可以由此推斷客戶可能的投資預算，本專案對於客戶的重要程度等。
2.本專案能解決什麼問題？
參考答案：
1)手工訂餐本身工作效率低，有時會影響員工的正常工作。
2)手工訂餐容易出錯，導致員工吃不到飯或者是吃不到自己想吃的飯。
答案點評：：
1)問題描述得很具體，並且問題產生的根源似乎都是因為“手工訂餐”導致的。
2)手工訂餐並不會讓大家吃不到飯，只是有時會出一些小問題。
3)手工訂餐的最大優勢就是靈活，不好的地方就是容易出錯，這個訂餐系統如何才能保持手工訂餐的“靈活”優勢呢？
問題應該怎樣描述？
需要清楚明確地描述清楚專案解決的問題，同時要分析好當前的工作方法的優點。系統除了要解決當前的問題，還應該保持原來工作方法的優點。很多系統解決了問題，但丟失了原來工作方法的優勢，往往是得不償失。
3.本專案的關鍵涉眾有哪些？
參考答案：員工、前臺、領導、財務、餐廳。
答案點評：
1)全面考慮了各種涉眾。
2)員工是使用本系統的主體，他們最關鍵的需求應該是能方便準確地訂餐。
3)前臺通過本系統來統計訂餐、和餐廳溝通、下訂單等，前臺可能是本系統使用功能最多、操作最複雜的角色。
4)領導有時也會通過本系統來訂餐，但對本系統的主要要求就是大家要用得舒服。
5)財務可能需要根據本系統的訂餐記錄和餐廳結帳。
6)餐廳需要提供選單給前臺，餐廳可能以傳真或電話的方式獲知我們的訂餐，不同的方式將會影響本系統的某些功能。
如果找出關鍵涉眾？
1)應廣度優先地儘量多地列出可能的涉眾。
2)列出每種涉眾在本系統的關鍵需求。
3)每一種涉眾都應該清楚說明本系統是如何影響她的，以及她是如何影響本系統的。
4.本系統要達到怎樣的目標？
參考答案：達到“吃飯易”的效果，保證員工不會因為吃飯問題影響正常工作。
答案點評：
1)目標描述應簡單容易記憶，以便專案組隨時記住。
2)本專案的目標並不是讓員工吃飯吃得開心，也不是用來保證員工正常工作（光靠這個系統，是不能保證員工正常工作的），而是希望通過本系統來消除手工訂餐的問題。
應該如何描述目標？
應該用簡單、明確、恰如其分的語言來描述。簡單、明確是方便專案組記憶，以便在工作中隨時可以用目標檢驗工作。恰如其分則要求目標描述不要誇大系統的作用，也不要縮小系統的作用。很多專案描述目標的時候，往往會誇大系統的作用，如提高工作效率、提高生產力等，這些目標往往不是單純靠系統就可以做得到的，更多是靠企業的管理，系統只是起到配合和支援的作用。
5.本系統的範圍是怎樣的？
參考答案：
1)這是一個訂餐系統，只考慮與訂餐相關的功能。
2)這是一個單獨的系統，不考慮與其它系統整合或互動。
3)使用本系統的是本公司的全體員工，不考慮分公司的員工。
答案點評：
從功能、與其它系統的關係、使用者三方面描述了本系統的範圍。
應該如何描述範圍？
範圍往往客戶並不會直接給出的，我們需要從專案解決的問題、目標等入手，從功能、與其它系統的關係、使用者等來思考系統的範圍。
由前面的資料，我們可以知道，客戶應該不會投入很多錢，客戶目標只是希望解決手工訂餐帶來的麻煩，所以我們定範圍時，應該儘量讓系統簡單，能滿足目標便可。本系統其實可以做得很複雜的，訂餐這事情其實與請假外出相關的，訂餐也會與財務結帳有關係，如果將系統邊界擴大，很可能將問題複雜化。
6.本系統應該具備怎樣的功能？
參考答案：
圖4 用例圖
對於“訂餐”這個用例，我們還可以進一步細化使用者與系統的互動：
使用者指示訂餐系統給出選單
使用者選擇選單並確認選擇
系統儲存使用者的選擇，提示訂餐成功。 答案點評： 1)用例圖全面地描述了系統使用者與用例，條理清晰、一目瞭然。 2)對於每一個用例，還可以進一步描述使用者與系統是如何互動的，為下一步工作做好準備。 3)除了描述功能，還需要考慮系統的非功能需求，如效能要求、安全性要求等。 應該如何描述功能？ 1)要根據前面的問題匯出系統應具備的功能以及非功能需求。 2)用例圖是描述功能性需求的好工具，但不要拘泥於只用用例圖。 3)對於非功能性需求，客戶往往沒有具體想法，需要我們從客戶的需要出發，定出具體的非功能性需求。 7.本專案成功標準是怎樣的？ 參考答案：用簡單的方式達到目標的要求，達致雙贏。 答案點評： 1)“簡單”意味著成本低，符合雙方利益。 2)達到目標要求是真正的客戶所需。 如何考慮專案的成功標準？ 我們做一個專案，成功標準並不是為了賺錢，更加不是不惜一切謀取最大利益，雙贏才是最重要的原則！對於客戶來說，首要目標就是要滿足他的需要，然後就是合理的預算，對於軟體公司來說，首要目標就是為客戶提供高性價比的解決方案，賺取合理利潤。要達致雙贏，客戶的成熟度是很重要的，但更重要的是軟體公司的成熟度，專案組需要以專家、顧問這樣的高度來解決專案中的問題，引導雙方達至雙贏。 以上7個問題，問題1是背景相關的問題，問題2、3、4、5是需要相關的問題，問題6是需求規格相關的問題，而問題7是我們需要認真考慮的問題，考慮清楚專案的成功標準才能更好地指導專案後續工作，提高專案成功概率。 1.4 沒完沒了的“新需求” 由於你的徹底而深入的需求分析工作，訂餐系統進展非常順利，很快就上線運行了！但問題也就來了，客戶陸陸續續提出了以下問題： 1)要經過好幾個頁面才能進入訂餐頁面，不太方便，希望能在首頁直接進入訂餐頁面。 2)一次只能定一天的餐，不太方便，希望一次能定多天的。 3)我有時選了一個菜，前臺卻說這個菜沒有了！ 4)能不能提供多家餐館選擇？ 5)訂餐標準才8元，現在物價都漲了，能不能提高一下標準？ 6)能不能直接連到餐館的網頁上去看菜式？ 7)能不能做口味分析和營養分析？ 系統能用起來，問題肯定多多，沒問題反而說明沒有人用這個系統，所以有問題是好事，但問題多了又會讓人很煩躁，改來改去沒完沒了啊，專案的成本也會持續上升。 你準備如何招架呢？在繼續閱讀之前，請你逐一分析上述問題並提出解決方案，要寫下來奧！ 下面我們來逐一分析上述問題。 1)要經過好幾個頁面才能進入訂餐頁面，不太方便，希望能在首頁直接進入訂餐頁面。 2)一次只能定一天的餐，不太方便，希望一次能定多天的。 我們首先要思考，這兩個要求背後的需要是什麼呢？這兩個問題都是在實際使用訂餐系統中產生的，使用者提出這樣的要求無非是希望系統更加好用更加方便，訂餐系統無非是要方便大家訂餐、減少訂餐時間，故這兩個要求應該予以滿足。 系統上線後，使用者往往會提出很具體的修改要求，這些要求往往是易用性方面的問題，如：介面佈局、操作方式、文字表達、排序條件等細節問題，這些問題不解決的話會降低使用者體驗，此類問題一般應儘量解決。 前期對專案的需要把握得比較好的話，軟體基本上是能符合使用者的需要的，哪怕使用者提出了一些易用性方面的要求，一般也是很容易修改的。不過誰也不能保證對需要的理解沒有偏差，有可能系統上線後才發現理解錯了客戶的真正需要，這時修改系統的話一般來說工作量會比較大，但原則上應該給予修改，雙贏是專案的目標，客戶關鍵需要沒有滿足，專案不能算成功。 3)我有時選了一個菜，前臺卻說這個菜沒有了！ 5)訂餐標準才8元，現在物價都漲了，能不能提高一下標準？ 會什麼會有選了菜但沒有這個菜的問題呢？是軟體的bug嗎？ 原來餐廳的選單會定期更換，前臺會及時更新訂餐系統的選單，但問題是餐廳修改選單並不是很準時，而且修改後又不一定能及時通知前臺，導致有時會出現員工按照老選單訂餐，但實際上餐廳已經修改了選單的情況。 第二個問題是午餐標準的問題，明顯不是系統的問題，但使用者還是提出來了，他們難道不知道不是系統的問題嗎？為什麼還要對我們提出來？是不是希望我們向公司領導反應問題？ 軟體有些問題，並不是軟體本身的問題，而是管理的問題。要用好一套系統，必須配套相應的管理辦法，很多管理的問題軟體是不能解決的。第一個問題，要改善的話則需要加強對餐廳的管理，讓他們及時送上更新後的選單；而對於第二個問題，則需要公司檢討訂餐標準是否合適了。 專案組遇到客戶提出這類問題時，不要因為不是軟體問題就事不關己，應主動分析問題並提供適當的解決方案，很多問題只需要在管理上稍微改善一下，問題就可以立馬解決。 4)能不能提供多家餐館選擇？ 為什麼使用者希望選擇多家餐廳呢？有人喜歡吃辣菜，有人喜歡吃粵菜，有人想吃粥粉面，就算是同一個人也會今天喜歡這個明天喜歡那個，如果能有多家餐廳可供選擇，則更能滿足大家的口味了。大家能吃到自己喜歡的午餐，更有利於大家做好工作，從這點看似乎這個要求是滿足需要的，我們應該予以滿足。 要實現這點，軟體自然要費點周折去修改，但問題遠遠沒有這樣簡單，管理上會變得麻煩很多：前臺需要從多家餐館獲取選單，要管理多家餐館；財務要對多家餐館進行結帳；更麻煩的是，有些餐館要訂餐數量多才會送餐，如果哪天某餐館點的餐不夠多，還需要選擇了這個餐館的員工重新訂餐。這樣複雜的管理，軟體應該如何來適應呢？ 看來如果寄望通過修改軟體來滿足這個要求，就會陷入一個“無底洞”，似乎無論怎樣做都難以滿足要求。實際專案中，經常會遇到這類問題，這時一定要認真地分析：
- 深入思考修改要求背後的需要是什麼。
- 如果要滿足該要求，在軟體和管理辦法上需要做什麼改變，代價有多大。
- 如果不滿足這個要求，影響會很大嗎？
- 對於符合需要的易用性方面的要求，應儘量滿足。
- 有些問題可通過改善管理辦法來解決。
- 有些問題需要同時在軟體和管理辦法上做工作來改善。
- 客戶一時衝動的要求，可另闢蹊徑解決。
- 客觀條件做不到的、技術上做不到的，應予以拒絕。
- 超出範圍的要求，可引導客戶做第二期。
圖5 需求分析高手
需求分析能力的提高，依靠長期的積累，長期的實踐！以下是一些建議：
1)不要以為學過了一些需求分析知識，就以為自己很厲害，也不要用這些大道理來指導專案組工作，不僅對專案組毫無實際幫助，還會幫倒忙。
2)不要一畢業就直接投身需求分析的工作，最好還是從編碼開始，另外也可以考慮做測試、實施。
3)要不斷地積累業務知識、技術知識。
4)學習面向物件分析、面向物件設計，並在實際工作中運用，面向物件分析與設計的方法，會從本質上提高你發現問題、分析問題、提煉問題、解決問題的能力。從這點上說，從開發開始是最好的選擇。
5)把握一切能提高你表達能力與理解能力的機會，和別人溝通要及時表達出你對別人說話的理解，平時多寫文章、部落格之類的，提高你的書面表達能力。
6)為什麼強調要有豐富的管理和被管理的經驗呢？訂餐系統中其實我們看到很多跟管理相關的問題，很多問題是需要管理辦法去解決的，缺乏管理和被管理的經驗，就會難以理解客戶的問題，更加是無從從管理上提出具體的解決辦法。
需求分析是榨乾人腦汁的活，超具挑戰性的工作！要站在比客戶更高的角度把握住客戶的需要，然後將客戶的這些需求轉化為軟體可實現的需求規格，與此同時還需要為客戶提供與軟體相匹配的管理意見。你做好準備迎接這樣的挑戰了嗎？
1.7 變被動為主動
大部分情況下，需求分析的工作總是比較被動的，總會有點被客戶牽著鼻子走的感覺，為什麼會這樣呢？看看下圖：
這個圖表示了隨著專案的開展，客戶與專案組對本專案的需要的認知程度是怎樣變化的，橫軸是時間，豎軸是對需要的認知程度。這個圖說明了這些問題：
1)專案最開始時，客戶對需要認知程度比較高，而專案組只是有朦朧的認識。
2)隨專案的開展，客戶和專案組都逐步提高了認識。
3)整個專案開展過程中，客戶對需要的理解程度總是比專案組要高。
以上該圖反應了絕大部分專案的情況，這樣的專案客戶對需要的理解永遠領先於專案組，這樣專案就不可避免地會陷入被動的境地。專案組做出來的東西往往不是客戶真正想要的，要反覆多次，但做出來後，客戶又會繼續有新的要求，周而復始，沒完沒了，客戶和專案組都相互不滿對方的表現，最終專案很可能是“雙輸”。
如果是下面這個圖呢？
在專案初期，客戶對需要的理解程度是比專案組要高的，但專案組的學習能力比較強，對需要的理解很快就超越了客戶，並且在後面持續領先於客戶。
按照這樣的曲線，專案成功的機會是很高的，只要專案組對需要的理解領先於客戶，就能化被動為主動，最終達到雙贏！
很多公司會接手很多新專案，這些專案之前是沒有什麼積累的，保證這類專案成功的關鍵，就是要提高專案組的整體水平，人的水平是決定因素，不要指望什麼用過程大框框能改善專案情況，更加不要指望那些半桶水的QA來監督專案組。
下面這個圖呢？
什麼情況下會是這樣？
產品化的專案！
產品化的專案才是公司持續盈利之道，所有公司都需要積累自己的業務與技術知識，將專案產品化。但凡產品化的專案，專案組對需要的理解要比客戶深刻很多的，客戶會很崇拜你、認可你，在專案開展過程中，專案組要不斷地去提高客戶的業務水平，同時學習專案中特有的產品中沒有的東西，將這些新內容提煉到產品中來，為下一個專案服務。
變被動為主動的奧妙就在此！提高需求分析能力沒有捷徑，努力提高水平吧！
1.8最後的瘋狂
訂餐系統的故事還沒有結束，過了一段時間，大家的抱怨陸續又來了！
來自員工的抱怨：
有些員工覺得A餐廳好吃，有些又覺得B餐廳好吃。
有些喜歡吃辣，有些喜歡吃湯粉湯麵之類的。
有些一會喜歡這個，一會喜歡那個。
很多員工強烈要求支援多家餐廳！
有些員工想自己帶飯回來吃，但公司不會給予午餐補助。
前臺的抱怨：
員工有時向她抱怨餐廳送餐慢，她也沒辦法，已經催了n次，換了幾家餐廳了。
不太同意要支援多家餐廳，她的管理工作會麻煩很多，而且有些餐廳訂餐少的話不會送餐的。
多家餐廳時，需要維護多家餐廳的選單，而且每家餐廳的選單更新時間不一樣。
財務的抱怨：
不太同意支援多家餐廳，因為財務需要每家餐廳都提供發票，而不是每家餐廳都能提供發票的，除非我們願意出更多的錢。
開發人員的抱怨：
不是吧，這班人這麼難服侍，還有需求變更啊…
支援定多天的餐和支援多家餐廳其實是有矛盾的，而且也很難實現！
領導的抱怨：
這麼簡單的訂餐系統，怎麼搞得這麼複雜！
我的這麼美好的想法，居然惹下這麼大的麻煩
另外一個領導的抱怨：
員工在辦公室內吃飯，搞得辦公室氣味怪怪的。
有些員工還不講究衛生，把桌子、地面弄髒又不搞乾淨！
你準備如何應對呢？
往下閱讀之前，請你運用前面所學的知識認真全面深入地思考，以上問題的根源是什麼呢？為什麼訂餐系統的問題會沒完沒了呢？
或許本不該上這樣的系統，每一種解決方案都不會解決全部的問題，而且都會帶來新的問題，投入這麼多到底值不值？
下面這個解決方案又如何呢？
1.所有員工的午餐標準提升到每日10元，無論是否在公司，每月都按22.5工作日提供補貼。
2.公司中午休息時間由1小時延長到1.5小時，調整上午下班與下午上班時間，與其它公司“錯峰”。
3.公司不再統一訂餐，也不允許員工在自己座位上吃午飯，公司指定吃午飯場所，讓專人負責清潔。
第一點措施提高了員工的福利，這措施應該是很受員工歡迎的，也可以抵消員工因為不能公司統一訂餐帶來不便而引發不滿情緒，當然如果補貼標準更高員工會更高興。
第二點措施，中午上下班時間儘量與別的公司“錯峰”，這樣可減少擠電梯還有在餐館排隊等候的時間，這也是很實在的措施。
至於第三點是用來解決衛生問題的，本來如果所有人都非常高尚，是不會有這樣的問題的，但至少短期內不可能讓所有人都高尚，指定場所和專人負責清潔是當前最有效的解決衛生問題的辦法了。
其實很多大企業不會統一訂餐的，也不會讓員工在辦公區內吃東西，好像有點不人性化，其實也是有道理的。
折騰了這麼久，結局原來是這樣？真是不勝唏噓啊！需求分析過程是一個很考驗人很折騰人的過程，好好總結本文所列舉的各種情況，做好準備繼續接受下面的挑戰吧！
後話
關於《軟體需求分析挑戰之旅》
本人目前正在撰寫《軟體需求分析挑戰之旅》，而“瘋狂的訂餐系統”將會是本書的開始章節（至少目前是這樣規劃，呵呵），希望通過這個“瘋狂的訂餐系統”讓大家很快地抓住需求分析的核心內容，能馬上用於實戰，而不需要啃完整本書。
在本論壇發表“瘋狂的訂餐系統”，無非就是小試牛刀，看看大家的反應如何，同時也為將來書的發售打打廣告
一、為什麼要寫《軟體需求分析挑戰之旅》一書？
需求方面的問題，從來就是每個專案的老大難問題，本人經歷過n個專案的磨練，深知其苦！關於需求方面的書籍也不少，但大都跟你講道理、講理論，開始還會覺得有點意思，但最終發現難以指導你實際的工作，解決你的具體專案問題，最終還是要靠自己想辦法去解決，久而久之我也有自己的一套經驗心得了。
於是我就有了寫這本書的想法，本書不會空講道理空講理論，全部都是真刀真槍的例項，“瘋狂的訂餐系統”就是用這樣的風格寫出來的，如果參加過“需求開發挑戰之旅”沙龍的朋友，會更加了解到我的講課風格和實用性。
二、《軟體需求分析挑戰之旅》有什麼特色？
1)實用為王
本書絕不拋書包，案例一個接一個。很多書也會有案例，但往往是單獨成文，而本書的案例貫穿全文，每個案例進行了提煉和擴充套件，內容安排精細，逐步講解和剖析，務求每一句話都給讀者帶來實實在在的收穫。
2)激發思考
希望本書是一部引人入勝的小說，吸引著大家去看，吸引著大家去思考。書中會列出很多問題，激發讀者的思考，並要求讀者寫下答案後再往下看，讀者經過思考再繼續閱讀，將會給你更大的震撼和收穫。
3)精簡易懂
不少書為了顯示出其價值，基本上是厚厚的，其中不乏拼湊的內容，有些甚至是通過加大行距來增加頁數。
本人將盡量控制文字數量，但不會減少內容，更加不會放入垃圾內容。精簡的好處就是書可以做得更薄，這樣書的成本更低；另外一個好處就是大家不需要啃這麼多文字，更加容易消化。
要保證易讀性，文字數量就可能不能太小。一些書籍確實寫得很淺顯，有些甚至用擬人法、虛擬角色等方法來寫，目的就是讓書本更生動更好讀，但我覺得還是過於羅嗦，其實有辦法做到文字少又易讀的。
4)有內涵
這本書出來後，如果被人罵之“膚淺”，那真是羞死人了！
我將竭盡全力寫好，傾注我的全部智力！
三、《軟體需求分析挑戰之旅》有什麼內容？
本書主要講解需求分析的內容，還會講解需求管理的內容。需求分析也叫做需求開發，是指獲取、分析、提煉客戶的需求，並用這些需求來指導軟體開發的工作。需求管理指的是和客戶協調、確認需求，控制和管理需求變更的工作。需求分析、需求管理的工作，本書將會統稱為需求方面的工作。很多書將做好需求管理列為改進需求方面的工作的主要方面，我不以為然，我認為需求分析至少佔80%的比重，而需求管理最多隻佔20%比重，兩者還不能割裂開來，必須互相配合才能妥善解決專案需求方面的問題。
以下是本書的內容大綱：
1.瘋狂的訂餐系統
1.1 某IT公司員工的吃飯問題
1.2 需求分析大道路
1.3 背景-需要-需求規格
1.4 沒完沒了的“新需求”
1.5 領導“突發奇想”
1.6 榨乾人腦汁的需求分析
1.7 變被動為主動
2.端正你的認識
3.你具備需求分析的基本素質嗎？
4.工欲善其事，必先利其器
5.如何做專案的需求分析？
6.如何做專案的需求管理？
7.如何做產品的需求分析？
8.如何做產品的需求管理？
9.讓需求在專案組中同步
10.提煉需求-提升公司競爭力
說明：本大綱只是暫定的，隨時會修改和細化的，歡迎大家提出建議。
四、誰適合看《軟體需求分析挑戰之旅》？
只要你感興趣，你就適合看！當然如何你有相關的工作經驗，看本書將會更加震撼和有收穫；如果你是學生，將會讓你見識到真實而又讓你震驚的需求分析世界，瞭解到具體實在的實戰經驗，為將來工作做好準備。
五、《軟體需求分析挑戰之旅》什麼時候發售？
目前我只能說盡快，期間歡迎大家在本網站多多發表，我將吸取大家的精華到本書中。