本章內容雖然叫“需求分析”，實際上關於具體的需求分析操作步驟並沒有深入去寫，因為細化的話那將是一本厚厚的書，而需求分析在本系列中，是幫助大家了解項目的基本要求（主要針對本項目而已）。而寫本章的主要目的想告訴初學者們一些常識與重要性，順便寫一寫本項目的開發需求與需求文檔格式，而不是具體的需求分析步驟。由於個人水平有限，文筆也並不怎么樣，為了加快進度早點進入編碼階段所以寫得有點水，大家先將就將就吧。
慢工出細活，磨刀不誤砍材工。計划將要做的事情，按計划內容去做計划中的事情。
前言
需求分析文檔按正常來說，它不應該由程序員來寫的，是由項目經理與客戶共同來完成，但是對於國內大多數軟件公司（除了少數比較規范的公司專門設置有對應的職位外），很多是需求方口頭提出、在WORD寫幾條要求或提供相關表格文檔、提供參考的網站或軟件、用相關模型軟件簡單的做出模型等一種或多種組合方式提出需求，然后由技術部負責人或直接是程序員來編寫，當然還有不少情況是根本就沒有需求分析這個步驟，需求方直接口頭描述需要實現什么功能后，程序員就直接開工......相信大部分朋友正在處於這種水深火熱當中或即將進入這種類型的公司。而初學者如果能了解需求文檔編寫，對以后參與項目的設計與開發將有非常大的幫助。
曾經看到一個園友講述，他們公司做的外包，用了3個多月做需求分析，花一個月時間編碼，一個月時間做測試與修改BUG，然后就交付客戶使用了。從中可以看出需求分析在項目開發中的重要性。
當然更多聽到的是無盡的吐槽，至於原因在前文已經簡單的描述過了。對於需求分析，很多中小型公司都不太在意。我碰到不少拍腦袋的老板和客戶，想法很多，變得也快，弄得你無從適合。同他們講需求，確認功能，真的是一項非常艱巨的任務。而需求沒有最終確定，產生的結果就是無限期的需求變動與修改，一個小小的功能可能改上N多次。沒有文檔就很難評估出你的工作量，通常是加班加點完成功能又沒有加班費，而上頭還會以為你開發效率低下，一個小功能你就要花費大把時間，浪費金錢。
為什么多數公司會忽略需求分析的重要性，主要原因我覺得有三種，一是需求方也不明白自己要的是什么；二是溝通問題，需求方自認為講得很清晰了，以為開發方相關人員明白它想要的，而開發方也自認為已經理解了需求方的要求；三是覺得需求很簡單，不必要花太多時間浪費，早點開發早點完工，節省開支。
由於篇幅有限，而需求知識點太多，所以本文不會詳細描述需求分析的每個步驟，只是簡單講解需求分析的一些常識和本項目相關的需求分析。
需求分析說明
如果嚴格按照軟件工程操作，需求分析階段有很詳細的操作流程，包括需求獲取、需求分析、編寫需求規格說明、需求驗證、知識培訓、需求管理、項目管理等等。而對於中小型項目來說，只要求做到前四項基本就足夠了。
在處理需求前，首先我們要知道，需求對於需求方來說（不懂技術的），它就像是要實現功能的一份詳細說明；一份業務流程；一份表格或文檔；甚至可能是一個網站或軟件等。他們不太可能與你細說具體要用到什么技術、算法、數據庫該存儲什么內容、服務器性能、安全等等，而我們如果與他講太專業的東西，他們大都也會一頭霧水，不知道我們在說什么。
其次，由於大家對各自專業領域的認知有所區別，我們也可能不了解他們專業里的工作流程和具體操作要求。
所以需求的采集，重點在於溝通與記錄，要多提問多思考多論證。
怎么進行需求采集
在同用戶的交流過程中收集各種用戶的信息與要求，且第一時間將得到的需求整理成文字描述，一一記錄下來。在需求采集的過程中，可以要求需求方提供相關的文檔、報表、業務流程圖等內容給我們參考，然后在這些基礎上認真思考在軟件上實現的UI大概樣子，里面包含什么功能，可能存在什么問題或難點，及時與需求提出者做多次確認，看我們的理解是否是正確的，排除不合理的地方，明確各個業務流程與約束。
那我們這個項目要做什么（實現什么功能）？
第二章已經簡單進過，在這里再整理一下：
1、開發一個有擴展性的框架，以后在這個基礎上能實現網站后台、OA、CMR、SCM等各種系統；
2、要求開發、維護操作要簡單，不要那么繁瑣（即增加頁面、添加修改或刪除字段時，操作簡單）；
3、有權限管理功能；
4、實現類似QQ登陸限制的效果，即同一時間一個帳號，只能單獨在線，在不同地方登陸時會將前一個踢除下線並提醒；也可以設置公眾帳號，多人使用同時在線；
5、用戶登陸后使用操作都有詳細操作日志記錄（即進入什么頁面執行了什么操作）；
6、后端管理員只能屬於一個部門，但可以有多個職務（角色），有多個職務時也將擁有多個職務的共同權限；
7、所有頁面、按鍵（工具欄的）操作權限都可以設置，不賦予權限將不能操作；
8、所有頁面訪問都需要加密處理，即不能修改頁面參數中的屬性（比如更新Id值）就可以查看到別人的資料或信息；
......（暫時先實現這些功能吧，其他的以后根據需要再考慮增加）
占用多少時間
一般對於中小型項目來說，視項目的復雜度與難易度，需求分析大概需要占用3到12個工作日比較合適，當然如果項目涉及到復雜的計算和業務流程，對安全、性能等要求也比較高的，需要分析占用時間也將成倍增長。
編寫需求文檔
需求文檔的編寫原則是：必須清晰明了描述要求，只描述做什么，不描述怎么做。
對於一些簡單的小型項目，前面的需求描述+原型設計可能就已經足夠了，有原型的話，在視覺上能更直觀。
（注：由於時間關系，需求文檔只簡單的編寫例子，不深入編寫細節）
需求確認與變更
編寫好需求文檔后，要即時與需求方進行確認，將整理出來的問題與難點進行反復討論確認，然后再次完善需求文檔再次確認，直到雙方達成共識認可文檔。
當然在整個開發過程中，需求不斷變化這是不可避免的，所以在需要分析階段需要盡可能的將一些可能會產生重大變量的需求提前爆露出來。因為它在開發的不同時間段內提出變更，而對軟件產生的影響也是不一樣的。小的變更可能會導至開發周期延長，而大的變更，有可能會導至項目推倒重做。
我們在做需求的時候，要讓需求方知道需求變更對項目的影響，以便讓他們在考慮需求變更時更加謹慎。當然最好讓需求方簽屬以下內容，有存檔為證也可以避免一些不必要的不合理需求出現。
“我同意這份文檔表達了目前我們對項目軟件需求的了解。進一步的變更可在此基礎上通過項目定義的變更過程來進行。我知道變更可能會使我們要重新協商成本、資源和項目時間工期任務等。”（這句話摘自《北京理工大學軟件工程實踐》湯銘端老師的PPT）
每次需求變更時，也必須編寫對應的變更文檔，且讓需求方簽字確認，這樣對計算工期（開發成本）、延長項目進度，以及向上層或需求方反饋我們開發人員工作強度、能力都有明確的憑證。
我們在開發本框架時，前期雖然設定好框架結構和功能要求，但實際開發中可能會遇到一些不可避免的因素影響，產生一些變化，這時將會認真思考需求變更要求，對於必不可少，必須添加的功能則會直接加入到項目開發中，而對於可有可無的，或對當前項目開發暫時不會產生影響的，將會放到以后開發，一切以開發文檔中的設計好的功能要求為准，以做好項目開發周期控制，能按時按質按量完成項目開發。
總結
最近看了不少這方面的資料，知識量太大了，很難消化完全，無從下手。本章寫完后反復看了N多次，都不怎么滿意，沒有講明需求分析的要點，在此向大家抱歉。自己在需求分析這一塊也是比較薄弱的，還需要繼續努力學習。
總之需求分析是一項技術活，需要溝通與細心，它決定整個項目最終完成效果，是一個非常重要的步驟。沒有足夠的准備，越早開始寫程序，就要花越長時間才能夠完成。方向錯了，跑得越快離目標就越遠，越難掉頭。離開了計划，在開發中不停的添加需求，那項目將永遠也完成不了，結束不了。
版權聲明：
本文由AllEmpty原創並發布於博客園，歡迎轉載，未經本人同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利。如有問題，可以通過1654937@qq.com 聯系我，非常感謝。
發表本編內容，只要主為了和大家共同學習共同進步，有興趣的朋友可以加加Q群：327360708 或Email給我（1654937@qq.com），大家一起探討。
更多內容，敬請觀注博客：http://www.cnblogs.com/EmptyFS/