本章內容雖然叫「需求分析」，實際上關於具體的需求分析操作步驟並沒有深入去寫，因為細化的話那將是一本厚厚的書，而需求分析在本系列中，是幫助大家了解專案的基本要求（主要針對本專案而已）。而寫本章的主要目的想告訴初學者們一些常識與重要性，順便寫一寫本專案的開發需求與需求文件格式，而不是具體的需求分析步驟。由於個人水平有限，文筆也並不怎麼樣，為了加快進度早點進入編碼階段所以寫得有點水，大家先將就將就吧。
慢工出細活，磨刀不誤砍材工。計畫將要做的事情，按計畫內容去做計畫中的事情。
前言
需求分析文件按正常來說，它不應該由程式設計師來寫的，是由專案經理與客戶共同來完成，但是對於國內大多數軟體公司（除了少數比較規範的公司專門設定有對應的職位外），很多是需求方口頭提出、在word寫幾條要求或提供相關**文件、提供參考的**或軟體、用相關模型軟體簡單的做出模型等一種或多種組合方式提出需求，然後由技術部負責人或直接是程式設計師來編寫，當然還有不少情況是根本就沒有需求分析這個步驟，需求方直介面頭描述需要實現什麼功能後，程式設計師就直接開工......相信大部分朋友正在處於這種水深火熱當中或即將進入這種型別的公司。而初學者如果能了解需求文件編寫，對以後參與專案的設計與開發將有非常大的幫助。
曾經看到乙個園友講述，他們公司做的外包，用了3個多月做需求分析，花乙個月時間編碼，乙個月時間做測試與修改bug，然後就交付客戶使用了。從中可以看出需求分析在專案開發中的重要性。
當然更多聽到的是無盡的吐槽，至於原因在前文已經簡單的描述過了。對於需求分析，很多中小型公司都不太在意。我碰到不少拍腦袋的老闆和客戶，想法很多，變得也快，弄得你無從適合。同他們講需求，確認功能，真的是一項非常艱鉅的任務。而需求沒有最終確定，產生的結果就是無限期的需求變動與修改，乙個小小的功能可能改上n多次。沒有文件就很難評估出你的工作量，通常是加班加點完成功能又沒有加班費，而上頭還會以為你開發效率低下，乙個小功能你就要花費大把時間，浪費金錢。
為什麼多數公司會忽略需求分析的重要性，主要原因我覺得有三種，一是需求方也不明白自己要的是什麼；二是溝通問題，需求方自認為講得很清晰了，以為開發方相關人員明白它想要的，而開發方也自認為已經理解了需求方的要求；三是覺得需求很簡單，不必要花太多時間浪費，早點開發早點完工，節省開支。
由於篇幅有限，而需求知識點太多，所以本文不會詳細描述需求分析的每個步驟，只是簡單講解需求分析的一些常識和本專案相關的需求分析。
需求分析說明
如果嚴格按照軟體工程操作，需求分析階段有很詳細的操作流程，包括需求獲取、需求分析、編寫需求規格說明、需求驗證、知識培訓、需求管理、專案管理等等。而對於中小型專案來說，只要求做到前四項基本就足夠了。
在處理需求前，首先我們要知道，需求對於需求方來說（不懂技術的），它就像是要實現功能的乙份詳細說明；乙份業務流程；乙份**或文件；甚至可能是乙個**或軟體等。他們不太可能與你細說具體要用到什麼技術、演算法、資料庫該儲存什麼內容、伺服器效能、安全等等，而我們如果與他講太專業的東西，他們大都也會一頭霧水，不知道我們在說什麼。
其次，由於大家對各自專業領域的認知有所區別，我們也可能不了解他們專業裡的工作流程和具體操作要求。
所以需求的採集，重點在於溝通與記錄，要多提問多思考多論證
。
怎麼進行需求採集
在同使用者的交流過程中收集各種使用者的資訊與要求，且第一時間將得到的需求整理成文字描述，一一記錄下來。在需求採集的過程中，可以要求需求方提供相關的文件、報表、業務流程圖等內容給我們參考，然後在這些基礎上認真思考在軟體上實現的ui大概樣子，裡面包含什麼功能，可能存在什麼問題或難點，及時與需求提出者做多次確認，看我們的理解是否是正確的，排除不合理的地方，明確各個業務流程與約束。
那我們這個專案要做什麼（實現什麼功能）？
第二章已經簡單進過，在這裡再整理一下：
1、開發乙個有擴充套件性的框架，以後在這個基礎上能實現**後台、oa、cmr、scm等各種系統；
2、要求開發、維護操作要簡單，不要那麼繁瑣（即增加頁面、新增修改或刪除欄位時，操作簡單）；
3、有許可權管理功能；
5、使用者登陸後使用操作都有詳細操作日誌記錄（即進入什麼頁面執行了什麼操作）；
6、後端管理員只能屬於乙個部門，但可以有多個職務（角色），有多個職務時也將擁有多個職務的共同許可權；
7、所有頁面、按鍵（工具欄的）操作許可權都可以設定，不賦予許可權將不能操作；
8、所有頁面訪問都需要加密處理，即不能修改頁面引數中的屬性（比如更新id值）就可以檢視到別人的資料或資訊；
......（暫時先實現這些功能吧，其他的以後根據需要再考慮增加）
占用多少時間
一般對於中小型專案來說，視專案的複雜度與難易度，需求分析大概需要占用3到12個工作日比較合適，當然如果專案涉及到複雜的計算和業務流程，對安全、效能等要求也比較高的，需要分析占用時間也將成倍增長。
編寫需求文件
需求文件的編寫原則是：必須清晰明了描述要求，只描述做什麼，不描述怎麼做。
對於一些簡單的小型專案，前面的需求描述+原型設計可能就已經足夠了，有原型的話，在視覺上能更直觀。
（注：由於時間關係，需求文件只簡單的編寫例子，不深入編寫細節）
需求確認與變更
編寫好需求文件後，要即時與需求方進行確認，將整理出來的問題與難點
進行反覆討論確認，然後再次完善需求文件再次確認，直到雙方達成共識認可文件。
當然在整個開發過程中，需求不斷變化這是不可避免的，所以在需要分析階段需要盡可能的將一些可能會產生重大變數的需求提前爆露出來。因為它在開發的不同時間段內提出變更，而對軟體產生的影響也是不一樣的。小的變更可能會導至開發周期延長，而大的變更，有可能會導至專案推倒重做。
我們在做需求的時候，要讓需求方知道需求變更對專案的影響，以便讓他們在考慮需求變更時更加謹慎。當然最好讓需求方簽屬以下內容，有存檔為證也可以避免一些不必要的不合理需求出現。
「我同意這份文件表達了目前我們對專案軟體需求的了解。進一步的變更可在此基礎上通過專案定義的變更過程來進行。我知道變更可能會使我們要重新協商成本、資源和專案時間工期任務等。」（這句話摘自《北京理工大學軟體工程實踐》湯銘端老師的ppt）
每次需求變更時，也必須編寫對應的變更文件，且讓需求方簽字確認，這樣對計算工期（開發成本）、延長專案進度，以及向上層或需求方反饋我們開發人員工作強度、能力都有明確的憑證。
我們在開發本框架時，前期雖然設定好框架結構和功能要求，但實際開發中可能會遇到一些不可避免的因素影響，產生一些變化，這時將會認真思考需求變更要求，對於必不可少，必須新增的功能則會直接加入到專案開發中，而對於可有可無的，或對當前專案開發暫時不會產生影響的，將會放到以後開發，一切以開發文件中的設計好的功能要求為準，以做好專案開發周期控制，能按時按質按量完成專案開發。
總結
最近看了不少這方面的資料，知識量太大了，很難消化完全，無從下手。本章寫完後反覆看了n多次，都不怎麼滿意，沒有講明需求分析的要點，在此向大家抱歉。自己在需求分析這一塊也是比較薄弱的，還需要繼續努力學習。
總之需求分析是一項技術活，需要溝通與細心，它決定整個專案最終完成效果，是乙個非常重要的步驟。沒有足夠的準備，越早開始寫程式，就要花越長時間才能夠完成。方向錯了，跑得越快離目標就越遠，越難掉頭。離開了計畫，在開發中不停的新增需求，那專案將永遠也完成不了，結束不了。
。如有問題，可以通過[email protected]聯絡我，非常感謝。
發表本編內容，只要主為了和大家共同學習共同進步，有興趣的朋友可以加加q群：327360708 或email給我（[email protected]），大家一起**。
從零開始編寫自己的C 框架（7） 需求分析
本章內容雖然叫 需求分析 實際上關於具體的需求分析操作步驟並沒有深入去寫，因為細化的話那將是一本厚厚的書，而需求分析在本系列中，是幫助大家了解專案的基本要求 主要針對本專案而已 而寫本章的主要目的想告訴初學者們一些常識與重要性，順便寫一寫本專案的開發需求與需求文件格式，而不是具體的需求分析步驟。由於...
從零開始編寫自己的C 框架（1） 前言
記得十五年前自學程式設計時，拿著c語言厚厚的書，想要上機都不知道要用什麼編譯器來執行書中的例子。十二年前在大學自學asp時，由於身邊沒有一位同學和朋友學習這種語言，也只能整天混在圖收館裡拼命的啃書。而再後來也差不多，自學了很多不同的知識，都一直只能自己默默的克服乙個又乙個困難。所以這幾年帶一些應屆生...
從零開始編寫自己的C 框架（1） 前言
記得十五年前自學程式設計時，拿著c語言厚厚的書，想要上機都不知道要用什麼編譯器來執行書中的例子。十二年前在大學自學asp時，由於身邊沒有一位同學和朋友學習這種語言，也只能整天混在圖收館裡拼命的啃書。而再後來也差不多，自學了很多不同的知識，都一直只能自己默默的克服乙個又乙個困難。所以這幾年帶一些應屆生...