從零開(kāi)始編寫(xiě)自己的C#框架（7）——需求分析

　　本章內(nèi)容雖然叫“需求分析”，實(shí)際上關(guān)于具體的需求分析操作步驟并沒(méi)有深入去寫(xiě)，因?yàn)榧?xì)化的話那將是一本厚厚的書(shū)，而需求分析在本系列中，是幫助大家了解項(xiàng)目的基本要求（主要針對(duì)本項(xiàng)目而已）。而寫(xiě)本章的主要目的想告訴初學(xué)者們一些常識(shí)與重要性，順便寫(xiě)一寫(xiě)本項(xiàng)目的開(kāi)發(fā)需求與需求文檔格式，而不是具體的需求分析步驟。由于個(gè)人水平有限，文筆也并不怎么樣，為了加快進(jìn)度早點(diǎn)進(jìn)入編碼階段所以寫(xiě)得有點(diǎn)水，大家先將就將就吧。

　　慢工出細(xì)活，磨刀不誤砍材工。計(jì)劃將要做的事情，按計(jì)劃內(nèi)容去做計(jì)劃中的事情。

　　前言

　　需求分析文檔按正常來(lái)說(shuō)，它不應(yīng)該由程序員來(lái)寫(xiě)的，是由項(xiàng)目經(jīng)理與客戶共同來(lái)完成，但是對(duì)于國(guó)內(nèi)大多數(shù)軟件公司（除了少數(shù)比較規(guī)范的公司專門(mén)設(shè)置有對(duì)應(yīng)的職位外），很多是需求方口頭提出、在Word寫(xiě)幾條要求或提供相關(guān)表格文檔、提供參考的網(wǎng)站或軟件、用相關(guān)模型軟件簡(jiǎn)單的做出模型等一種或多種組合方式提出需求，然后由技術(shù)部負(fù)責(zé)人或直接是程序員來(lái)編寫(xiě)，當(dāng)然還有不少情況是根本就沒(méi)有需求分析這個(gè)步驟，需求方直接口頭描述需要實(shí)現(xiàn)什么功能后，程序員就直接開(kāi)工......相信大部分朋友正在處于這種水深火熱當(dāng)中或即將進(jìn)入這種類型的公司。而初學(xué)者如果能了解需求文檔編寫(xiě)，對(duì)以后參與項(xiàng)目的設(shè)計(jì)與開(kāi)發(fā)將有非常大的幫助。

　　曾經(jīng)看到一個(gè)園友講述，他們公司做的外包，用了3個(gè)多月做需求分析，花一個(gè)月時(shí)間編碼，一個(gè)月時(shí)間做測(cè)試與修改BUG，然后就交付客戶使用了。從中可以看出需求分析在項(xiàng)目開(kāi)發(fā)中的重要性。

　　當(dāng)然更多聽(tīng)到的是無(wú)盡的吐槽，至于原因在前文已經(jīng)簡(jiǎn)單的描述過(guò)了。對(duì)于需求分析，很多中小型公司都不太在意。我碰到不少拍腦袋的老板和客戶，想法很多，變得也快，弄得你無(wú)從適合。同他們講需求，確認(rèn)功能，真的是一項(xiàng)非常艱巨的任務(wù)。而需求沒(méi)有最終確定，產(chǎn)生的結(jié)果就是無(wú)限期的需求變動(dòng)與修改，一個(gè)小小的功能可能改上N多次。沒(méi)有文檔就很難評(píng)估出你的工作量，通常是加班加點(diǎn)完成功能又沒(méi)有加班費(fèi)，而上頭還會(huì)以為你開(kāi)發(fā)效率低下，一個(gè)小功能你就要花費(fèi)大把時(shí)間，浪費(fèi)金錢。

　　為什么多數(shù)公司會(huì)忽略需求分析的重要性，主要原因我覺(jué)得有三種，一是需求方也不明白自己要的是什么；二是溝通問(wèn)題，需求方自認(rèn)為講得很清晰了，以為開(kāi)發(fā)方相關(guān)人員明白它想要的，而開(kāi)發(fā)方也自認(rèn)為已經(jīng)理解了需求方的要求；三是覺(jué)得需求很簡(jiǎn)單，不必要花太多時(shí)間浪費(fèi)，早點(diǎn)開(kāi)發(fā)早點(diǎn)完工，節(jié)省開(kāi)支。

　　由于篇幅有限，而需求知識(shí)點(diǎn)太多，所以本文不會(huì)詳細(xì)描述需求分析的每個(gè)步驟，只是簡(jiǎn)單講解需求分析的一些常識(shí)和本項(xiàng)目相關(guān)的需求分析。

　　需求分析說(shuō)明

　　如果嚴(yán)格按照軟件工程操作，需求分析階段有很詳細(xì)的操作流程，包括需求獲取、需求分析、編寫(xiě)需求規(guī)格說(shuō)明、需求驗(yàn)證、知識(shí)培訓(xùn)、需求管理、項(xiàng)目管理等等。而對(duì)于中小型項(xiàng)目來(lái)說(shuō)，只要求做到前四項(xiàng)基本就足夠了。

　　在處理需求前，首先我們要知道，需求對(duì)于需求方來(lái)說(shuō)（不懂技術(shù)的），它就像是要實(shí)現(xiàn)功能的一份詳細(xì)說(shuō)明；一份業(yè)務(wù)流程；一份表格或文檔；甚至可能是一個(gè)網(wǎng)站或軟件等。他們不太可能與你細(xì)說(shuō)具體要用到什么技術(shù)、算法、數(shù)據(jù)庫(kù)該存儲(chǔ)什么內(nèi)容、服務(wù)器性能、安全等等，而我們?nèi)绻c他講太專業(yè)的東西，他們大都也會(huì)一頭霧水，不知道我們?cè)谡f(shuō)什么。

　　其次，由于大家對(duì)各自專業(yè)領(lǐng)域的認(rèn)知有所區(qū)別，我們也可能不了解他們專業(yè)里的工作流程和具體操作要求。

　　所以需求的采集，重點(diǎn)在于溝通與記錄，要多提問(wèn)多思考多論證。

　　怎么進(jìn)行需求采集

　　在同用戶的交流過(guò)程中收集各種用戶的信息與要求，且第一時(shí)間將得到的需求整理成文字描述，一一記錄下來(lái)。在需求采集的過(guò)程中，可以要求需求方提供相關(guān)的文檔、報(bào)表、業(yè)務(wù)流程圖等內(nèi)容給我們參考，然后在這些基礎(chǔ)上認(rèn)真思考在軟件上實(shí)現(xiàn)的UI大概樣子，里面包含什么功能，可能存在什么問(wèn)題或難點(diǎn)，及時(shí)與需求提出者做多次確認(rèn)，看我們的理解是否是正確的，排除不合理的地方，明確各個(gè)業(yè)務(wù)流程與約束。

　　那我們這個(gè)項(xiàng)目要做什么（實(shí)現(xiàn)什么功能）？

　　第二章已經(jīng)簡(jiǎn)單進(jìn)過(guò)，在這里再整理一下：

　　1、開(kāi)發(fā)一個(gè)有擴(kuò)展性的框架，以后在這個(gè)基礎(chǔ)上能實(shí)現(xiàn)網(wǎng)站后臺(tái)、OA、CMR、SCM等各種系統(tǒng)；

　　2、要求開(kāi)發(fā)、維護(hù)操作要簡(jiǎn)單，不要那么繁瑣（即增加頁(yè)面、添加修改或刪除字段時(shí)，操作簡(jiǎn)單）；

　　3、有權(quán)限管理功能；

　　4、實(shí)現(xiàn)類似QQ登陸限制的效果，即同一時(shí)間一個(gè)帳號(hào)，只能單獨(dú)在線，在不同地方登陸時(shí)會(huì)將前一個(gè)踢除下線并提醒；也可以設(shè)置公眾帳號(hào)，多人使用同時(shí)在線；

　　5、用戶登陸后使用操作都有詳細(xì)操作日志記錄（即進(jìn)入什么頁(yè)面執(zhí)行了什么操作）；

　　6、后端管理員只能屬于一個(gè)部門(mén)，但可以有多個(gè)職務(wù)（角色），有多個(gè)職務(wù)時(shí)也將擁有多個(gè)職務(wù)的共同權(quán)限；

　　7、所有頁(yè)面、按鍵（工具欄的）操作權(quán)限都可以設(shè)置，不賦予權(quán)限將不能操作；

　　8、所有頁(yè)面訪問(wèn)都需要加密處理，即不能修改頁(yè)面參數(shù)中的屬性（比如更新Id值）就可以查看到別人的資料或信息；

　　......（暫時(shí)先實(shí)現(xiàn)這些功能吧，其他的以后根據(jù)需要再考慮增加）

　　占用多少時(shí)間

　　一般對(duì)于中小型項(xiàng)目來(lái)說(shuō)，視項(xiàng)目的復(fù)雜度與難易度，需求分析大概需要占用3到12個(gè)工作日比較合適，當(dāng)然如果項(xiàng)目涉及到復(fù)雜的計(jì)算和業(yè)務(wù)流程，對(duì)安全、性能等要求也比較高的，需要分析占用時(shí)間也將成倍增長(zhǎng)。

　　編寫(xiě)需求文檔

　　需求文檔的編寫(xiě)原則是：必須清晰明了描述要求，只描述做什么，不描述怎么做。

　　對(duì)于一些簡(jiǎn)單的小型項(xiàng)目，前面的需求描述+原型設(shè)計(jì)可能就已經(jīng)足夠了，有原型的話，在視覺(jué)上能更直觀。

　　需求文檔下載

　　（注：由于時(shí)間關(guān)系，需求文檔只簡(jiǎn)單的編寫(xiě)例子，不深入編寫(xiě)細(xì)節(jié)）

　　需求確認(rèn)與變更

　　編寫(xiě)好需求文檔后，要即時(shí)與需求方進(jìn)行確認(rèn)，將整理出來(lái)的問(wèn)題與難點(diǎn)進(jìn)行反復(fù)討論確認(rèn)，然后再次完善需求文檔再次確認(rèn)，直到雙方達(dá)成共識(shí)認(rèn)可文檔。

　　當(dāng)然在整個(gè)開(kāi)發(fā)過(guò)程中，需求不斷變化這是不可避免的，所以在需要分析階段需要盡可能的將一些可能會(huì)產(chǎn)生重大變量的需求提前爆露出來(lái)。因?yàn)樗陂_(kāi)發(fā)的不同時(shí)間段內(nèi)提出變更，而對(duì)軟件產(chǎn)生的影響也是不一樣的。小的變更可能會(huì)導(dǎo)至開(kāi)發(fā)周期延長(zhǎng)，而大的變更，有可能會(huì)導(dǎo)至項(xiàng)目推倒重做。

　　我們?cè)谧鲂枨蟮臅r(shí)候，要讓需求方知道需求變更對(duì)項(xiàng)目的影響，以便讓他們?cè)诳紤]需求變更時(shí)更加謹(jǐn)慎。當(dāng)然最好讓需求方簽屬以下內(nèi)容，有存檔為證也可以避免一些不必要的不合理需求出現(xiàn)。

　　“我同意這份文檔表達(dá)了目前我們對(duì)項(xiàng)目軟件需求的了解。進(jìn)一步的變更可在此基礎(chǔ)上通過(guò)項(xiàng)目定義的變更過(guò)程來(lái)進(jìn)行。我知道變更可能會(huì)使我們要重新協(xié)商成本、資源和項(xiàng)目時(shí)間工期任務(wù)等。”（這句話摘自《北京理工大學(xué)軟件工程實(shí)踐》湯銘端老師的PPT）

　　每次需求變更時(shí)，也必須編寫(xiě)對(duì)應(yīng)的變更文檔，且讓需求方簽字確認(rèn)，這樣對(duì)計(jì)算工期（開(kāi)發(fā)成本）、延長(zhǎng)項(xiàng)目進(jìn)度，以及向上層或需求方反饋我們開(kāi)發(fā)人員工作強(qiáng)度、能力都有明確的憑證。

　　我們?cè)陂_(kāi)發(fā)本框架時(shí)，前期雖然設(shè)定好框架結(jié)構(gòu)和功能要求，但實(shí)際開(kāi)發(fā)中可能會(huì)遇到一些不可避免的因素影響，產(chǎn)生一些變化，這時(shí)將會(huì)認(rèn)真思考需求變更要求，對(duì)于必不可少，必須添加的功能則會(huì)直接加入到項(xiàng)目開(kāi)發(fā)中，而對(duì)于可有可無(wú)的，或?qū)Ξ?dāng)前項(xiàng)目開(kāi)發(fā)暫時(shí)不會(huì)產(chǎn)生影響的，將會(huì)放到以后開(kāi)發(fā)，一切以開(kāi)發(fā)文檔中的設(shè)計(jì)好的功能要求為準(zhǔn)，以做好項(xiàng)目開(kāi)發(fā)周期控制，能按時(shí)按質(zhì)按量完成項(xiàng)目開(kāi)發(fā)。

　　總結(jié)

　　最近看了不少這方面的資料，知識(shí)量太大了，很難消化完全，無(wú)從下手。本章寫(xiě)完后反復(fù)看了N多次，都不怎么滿意，沒(méi)有講明需求分析的要點(diǎn)，在此向大家抱歉。自己在需求分析這一塊也是比較薄弱的，還需要繼續(xù)努力學(xué)習(xí)。

　　總之需求分析是一項(xiàng)技術(shù)活，需要溝通與細(xì)心，它決定整個(gè)項(xiàng)目最終完成效果，是一個(gè)非常重要的步驟。沒(méi)有足夠的準(zhǔn)備，越早開(kāi)始寫(xiě)程序，就要花越長(zhǎng)時(shí)間才能夠完成。方向錯(cuò)了，跑得越快離目標(biāo)就越遠(yuǎn)，越難掉頭。離開(kāi)了計(jì)劃，在開(kāi)發(fā)中不停的添加需求，那項(xiàng)目將永遠(yuǎn)也完成不了，結(jié)束不了。

版權(quán)聲明：　　本文由AllEmpty原創(chuàng)并發(fā)布于博客園，歡迎轉(zhuǎn)載，未經(jīng)本人同意必須保留此段聲明，且在文章頁(yè)面明顯位置給出原文鏈接，否則保留追究法律責(zé)任的權(quán)利。如有問(wèn)題，可以通過(guò)1654937@qq.com 聯(lián)系我，非常感謝。

　　發(fā)表本編內(nèi)容，只要主為了和大家共同學(xué)習(xí)共同進(jìn)步，有興趣的朋友可以加加Q群：327360708 或Email給我（1654937@qq.com），大家一起探討。

　　更多內(nèi)容，敬請(qǐng)觀注博客：http://m.survivalescaperooms.com/EmptyFS/