計算機專業的，寫過一些項目設計文檔，需求說明書，但是不知道這個寫文檔以後能幹些什麼，想請教大神？

12-30

在學校參加一些比賽，會讓寫一個項目的需求說明書和設計文檔，不太明白以後能幹什麼就想問問，企業裡面有寫文檔這個職位嗎？怎樣能更好的去寫這些文檔？

這圖，你應該見過吧？軟體開發生命週期。

輪子哥是正統軟體開發公司文化，我就説偏一點，從一般公司運作上說一說。

環境非軟體公司的，商業機構內的開發部門。

User Requirement
用戶須求書，認真負責的，這的確可以寫的書一般厚，可以涉及用戶使用偏好，應用場景，等商業目標。
作者: 一般是商業部門，如銷售，市場部等。

然後才是圖里的
Requirement Analysis
用戶有須求，業務支持部門，就要拿來看，這是真的須求，還是有病的幻想。是真的須求，是自己開發，還是市場上有這現成好使，價格合理的系統能買到。實在買不到，要開發，就要出具概括及細分用戶系統功能，符合一系統功能的同時，還要有連貫性的業務流程。
作者: Business Analyst ，這職位要求是，要熟業務又要有技術基礎，他是業務部門和IT部門的橋樑。日後吵架，他也是磨心。

真的要自己開發了

Design ，是指System Design。IT 部門一般不負責UI UX Design。這一點，IT 千萬不要負責這一部份，須要在前兩個階段時，就要那些整天穿得光鮮、張口就成功人仕好好的落地弄出UI UX 的設計圖。

作者: System Analyst, 這就是正宗IT 部門里的人，須要熟悉各系統的架構、功能、業務分工、性能、安全要求。要知道實現些系統須要有什麼樣的開發人員，多少開發人員，要做多久，要買什麼系統、設備等。然後，他負責寫這System Design ，寫時各功能怎樣做，各子系統怎樣協同，要做多久。開支是多少，工期是多久。

有了以上三份文件，那就是IT 向業務部門要錢的時候了，剛才說的BA 就是作為一公道人，說IT 估算成本還是老實的。業務部門可能說，那太貴了 (IT 人心想，你發夢不用成本當然覺得貴)。遇到土豪部門，錢不是問題時。那你寫的System Design 及Resource Plan 就要啃到底的去交貨，反映了你專業性的地方。

Implementation

這里就沒什麼文檔的事了，業務部門繼續去拿著咖啡發夢，各組開發人員拿著系統設計做好本份。Project Manager 就負責和System Analyst 不停溝通，看開發人員的進度。怎樣看進度？就是基於System Design 的Modules, Miles Stone.

時間一天天過去，媽蛋，開發人員好不容易在Project Manager 的「關照下」，不分日夜的趕工，終於完成了。

Testing

這里分系統功能測試，和用戶驗收測試。前者拿著System Design 做測試計劃，後者是拿Business Analysis 做驗收計劃。最終出示報告，代表業務部門利益證明系統按他們要求完成了。

Evolution

系統正式上線，業務部門拿著系統用起來，才想到這個不爽，那個不夠用，年度預算又花了，怎麼辦，想系統「改進」，給管理層知道了，就知道他們想得不夠透。那就說系統問題吧，說要「系統修補」推黑鍋給IT

此時，當初的文檔就很有用途。IT 召個會，說你們有什麼不滿的呀？業務部門說，這個不好，那個很白痴。你就可以翻翻文檔，指出哪一點，這不都是你們要的嗎？改不是問題，這改動，要給個多少多少錢，半年後給到。他們只能乖乖，重新走一次SDLC，給你部門錢。

少年，當年讀CS 時，最討厭就是寫文檔，修死亡課Software Engineering時，特意找了一位長得不錯，英文功底好，會做presentation 的女同學入組，我只負責畫UML圖，拿了個高分。而這科目，其實就是為以後工作打下非常好的基礎。

現在，發現這些文檔都是非常非常重要的溝通工具，你是須要協調各團隊。想想一個複雜系統，涉及多個子系統的開發組，零碎不統一的溝通方式，項目是會做爛的。你的開發人員再辛苦，沒有白紙黑字，別的部門欺負起來，你是累死之餘還會苦死你的組員。

輪子哥說的非常到位了。

文檔這個東西是規範軟體需求和設計邊界的。

你口述的東西很容易有偏差，也很容易自己都忘記是怎麼回事。這時候就需要依靠文檔來確認你的想法和你的實現

另外輪子哥說的非常對的一點是，每個人都有錯誤，包括設計和需求。

寫複雜些的程序時候，可以先寫好設計文檔對應實現的注釋，然後像填空一樣填寫你的代碼，這樣最終實現比較不容易有偏差。而且寫注釋的過程也有助於你發現你設計的一些錯誤。

文檔都是為了溝通用的。一個項目幾千個人，總不能都靠開會、郵件和撕逼來做設計吧。所以沒一個職位的人都需要寫一些文檔。微軟也有專職寫文檔的，不過那些都是對外的，譬如說寫MSDN。開發文檔什麼的並不在此列。這些寫文檔的人很多其實都不懂技術，只是拿著我們給的草稿去潤色，最後迭代出來的。純寫文檔能做到這份上也是專業。對外的文檔是需要考慮很多事情的，譬如說例子要如何選才可以不得罪世界上任何文化，這通常都是程序員不會去考慮的。

需求說明書是很重要的，一個東西你決定要做了，你總得調研好需求吧，不然我怎麼知道要做啥，要做到什麼程度，做出來到底服務於誰？而且QA也可以拿這個文檔去測試。牛逼點的會連用例也一起寫，這些用例最終就是自動化測試的來源。只要你的需求文檔大家都同意了，除非做著做著發現做不了，否則很多跨職業的溝通就已經免去了。

設計文檔也很重要。一個軟體那麼複雜，你給出一個設計，並不僅僅是為了讓你抄出代碼來的，二是要給大家討論用的。每一個人的設計都會有失誤，所以才要大家都來看。如果你不寫文檔，靠口頭講，那麼大家的理解都不一樣，還不能重複閱讀，這樣開會就變成吵架了。所以你要有一個文檔，大家都來看，都來提意見，然後差不多都同意了，那麼大家就拿著手上的這份文檔去分工好了。

當然事情都不是這麼理想化的，因為一個軟體那麼複雜，人類怎麼可能處理的了呢？所以文檔跟代碼一樣也是會有很多bug的。這都要在開發的時候去發現，修掉，然後廣播，保持大家總是有一致的標準，互相依賴也要依賴一樣的錯誤，才能保證軟體整體上是好的。

所以如果題主將來的願望是去寫文檔，那麼多半會落空的（逃

領導：來個項目建設設計書？沒有，那可不行。項目背景呢？你為什麼要做這個？意義在哪兒？沒用你做它幹啥呢？建設目標是什麼？不清晰上面不給經費啊！你是做豆腐還是豆腐渣？總體技術框架呢？你讓下面的人用什麼框架，不統一不行啊！一個用AIX，一個用CentOS，系統版本、軟體版本、語言版本要確定，要在文檔上說明，嗯，這個要加在技術選型章節，經費預算沒有？你伺服器用三萬還是三十萬？不說清楚採購怎麼買？嗯，人工成本算貴點，這個可以彈性控制的，後面好說。

甲方：需求文檔啊？可以啊！你們先做，晚點給你們，就做個類似微信那樣的內部交流軟體。高並發？什麼意思？不用不用，我們用的人很少的。郵件通知功能？呃，可能有。語音？你可以試試，我們看看做得怎樣。不做了？一定要需求文檔啊？行吧！先寫個文檔。

乙方1：甲方沒有需求文檔？我們不會簽合同的，不然以後需求邊界怎麼確定？你說加需求就加需求，沒有一紙明文約束。—— 來個需求文檔吧！

乙方2：哎呀，這個功能不好添加啊！需求文檔裡面沒有說這個，不做不做。甲方讓做？我們兄弟時間不夠啊！甲方堅持要做？嗯，這個功能實現起來較難，需要50萬。（註：然後，就只改了一句代碼......）

開發1：產品沒有功能文檔？不開發，「實現一個類似箱子的功能」，不行！！！你得量化，四方還是長方的？鐵的還是膠的？30L還是60L的？場景是什麼？要量化啊童鞋！以後我可沒空跟你撕逼！—— 來個功能文檔吧！

開發2：這個代碼sei寫的？（答：離職了）。設計文檔呢？（答：只有老版本的）。幹啥用的？功能有點出入啊！什麼？！資料庫放哪台機器沒更新到文檔？這個數據介面呢？有說明嗎？這幾個欄位、參數啥意思？演算法沒說明啊！？文檔呢？？？！！！

測試：測試目標要說清楚啊！沒有測試文檔不行，測試用例呢？我們寫也行，但目標一定要清晰。是測邊界？還是測壓力？趕著上版本啊！測一千次也是測，測一次也是測，你不能直接跟領導說一句「已測」吧？

後記：

作為程序員，文檔了得，有時候說明理解需求到位。往上爬，發現更多的文檔要寫。但有一天，你寫個PPT路演掙的工資，是你十年前寫代碼的十倍的時候......依然不要放棄你的代碼。有時候PPT sucks，有時候文檔只有概念不能落地，而代碼是真實的擁有。

個人意見。

這叫technical writer有這個職位，專門為技術不行但是能寫的人設置，他們的最高成就是售前架構師

我就談談實際場景吧，雖然我也討厭寫文檔，但是在這個行業里做了一段時間之後，發現文檔還是非常必要的，幾個例子：

1，公司擴大，招了新人，安排你帶2個。你幹了幾年，對產品架構很熟悉了，但是他們沒有。開會培訓一段時間，也很難講的很細，遇到實際操作，會有各種問題。於是新人們不停的跑來找你。如果有文檔，直接丟一個過去，看不明白的再來

2，時間久了，你在公司里參與的項目多了，會有越來越多人用你寫的code，沒有文檔的話一天上班基本全在回復郵件和消息了。如果有文檔，直接丟一個過去，看不明白的再來

3，有長假需要離開幾周，於是組裡安排人來接你的活兒，如果沒有文檔，估計等你回來，那人還在code里打轉。如果有文檔，直接丟一個過去，看不明白也別來找我...

總之有文檔的話，可以沒事就甩一個去他們臉上

4，最後一個跟行業相關，我們公司的產品屬於醫療範圍，在美國就會有個管事大媽，隔三差五跑來查，她就是FDA。三年一大查，一年一小查。他們的辦事原則就一條：所有你做的事，全部要寫在紙上記錄，為什麼要做？怎麼做的？流程是什麼？結果怎樣？假如沒記錄的，你就是沒幹...所以怎麼辦呢？設計文檔，代碼文檔，bug文檔，等等等等，全部要有。他們還真的可以坐在會議室一天，一頁一頁的翻 - -，你說我們能怎麼辦...

所以我覺得寫文檔是一個一勞永逸的事情，寫的時候很蛋疼，寫完以後，你會慶幸自己當初寫了文檔。其實我的心情跟大家也是一樣的：你說的我都懂，但我還是不想寫

不是有個老梗么，碼農最煩的兩件事：

1，我靠，居然要我寫文檔

2，我靠，這code居然沒有文檔

為了防止欠錢不換，人們發明了欠條。

為了防止欠功能不做，人們發明了需求文檔。

從產品的角度談一下如果不寫需求文檔會怎樣吧：

1. 如果寫文檔的人和開發的人是同一個人，對，就是同學你，那麼你寫不寫是無所謂的。因為所有的細節都在你的腦子裡，在開發的過程中，你不會存在信息丟失的顧慮。如果發生了，那就只能怪自己記性不好嘍。

2. 如果寫需求的是你，負責開發的是另外一個老兄，開發時間一周左右，那麼這個情況就稍微有點複雜了。在這一周內，如果他就坐在你旁邊，有什麼不清楚的地方可以隨時問你，那麼你們基本上能保持信息一致，也不會出簍子。

3. 如果情況再複雜一點，你負責的前端分別包括前台和後台，那麼，你就需要確保前台和後台的業務邏輯一致，後端能提供前端需要的介面，前端和後端的數據格式保持一致。

4.覺得無所謂？好吧，我們把前端的任務拆得再細一點：UX+UI+研發。這下，你就要跟四個人對接任務了。你是整個項目的中樞。「中樞」這個詞聽上去很牛逼，但其實蠻恐怖的。UX跟研發吵架的時候，就得你上啊。沒了文檔，你拿什麼讓兩撥人馬閉嘴？

4. 實際情況往往比上面寫得還要再複雜一點。前端的工作一般要細化為網站+移動端。移動端分別包括手機瀏覽器、App（iPhone版、Android版）。除了這些之外，可能你還要想一想iPad版本、微信訂閱號、微信服務號，所以，你就要同時面對六個項目的需求。這些項目開發周期短則一個月，長則無上限。畢竟，研發也是人，也要娶妻生子請病假升職加薪跳槽，因此，在開發中間，這些想可能會經手好幾個人。你怎麼給新上來的哥們講需求？

5. 嗯，如果你天賦異稟，這些問題都能hold住，那我們再把情況弄得再複雜一點吧。如果你除了負責前端，還要管理後端。唔，這樣你不止要懂業務懂邏輯能管理項目，還要懂編程懂資料庫。但是，光你懂不行，你還要讓他們懂，中間還不能出錯。你要跟他們一起開一個大會講需求，然後再分別告訴每個人他們分別負責實現什麼功能。比如，他們可能正在開發著，就跑來問你，產品數據存放在哪裡？是在本地存儲，還是存在雲上。用戶上線以後，誰同步誰？如果一個用戶在兩個客戶端進行登錄，並且保存了不同的數據，你讓誰覆蓋誰？如果你的產品是支持即時通訊的，那麼，你如何保證信息同步？如果你的用戶包括國外的玩家，那麼，他們不能訪問國內伺服器怎麼辦？異地搭建伺服器如何保證穩定連接？……

你如何保證跟自己保持一致？

你如何保證別人跟你保持一致？

你如何保證別人與別人之間保持一致？

他們每個人每天過來跟你聊上半個小時，你就會崩潰了。因為你發現如果要解決一個需求，就必須引入一個新的需求，然後進入一個看上去無窮盡的過程當中……

你瞧，產品文檔就是用來解決這個問題的，多人團隊一起協同工作的時候，一份清晰的文檔，可以把你從這個災難中解脫出來。

嗯，別問我是怎麼知道的。

軟體=程序+數據+文檔

我們讓交作業，軟體需求說明書不知道怎麼寫。你寫的是哪方面的

很多時候設計文檔需要甲方簽字的，等到項目驗收的時候甲方說你們做的東西根本不是我們想要的，乙方可以把用戶簽過字的設計文檔拿出來作為證據。如果沒有設計文檔，能不能通過驗收就要看甲方的心情了

《軟體工程》里有講明文檔的種類和用途，上張圖更直觀：

至於各公司的實施情況各不相同，甚至具體到每個產品線也是不盡相同。

一、與產品的地位高低有關

1）一般來說，越是大公司的明星產品，它的文檔就更全更規範，比如：最優秀的應該是巨硬吧，看人家的MSDN多詳細。

2）小產品或功能，往往因相關人員的實施呈度不同，有的文檔可能就不寫，或者口述了。

二、編寫的人員

每種類型的文檔一般由不同的人來編寫，如：

1）用戶文檔一般由產品經理

2）設計文檔里的視覺設計由設計師來寫，產品的共性設計部分可能會形成設計規範，達到復用。

...

3）項目經理以及架構師寫偏向技術方面的文檔

4）我們小碼農寫寫代碼的注釋呀、描述呀！當然也可以不寫，理由就是「好的代碼就是文檔！耶」。

文檔是給別人看的，簡單的說，如果你自己可以翻地、種地、挖土、施肥、除草、抓蟲、天天看著你的菜苗，歪了就扶正，最後收穫，然後自己吃掉，拉出來的屎弄到地里均勻施肥，你就可以不用文檔了。可惜你顯然做不到。

需求文檔在開發中是很重要的一個介質，開發寫代碼全是按照需求方（在互聯網公司，一般是產品經理來收集需求寫文檔）給的需求文檔來寫。

說一個樓上沒人說得話,那就是有文檔在的話,萬一未來出現了嚴重的問題,甩鍋就容易了,文檔是你寫的,需求也是按照這個文檔改的,測試也是按照這個測試的,結果出了問題,你說這個鍋是誰的

文檔已經出了,這時候某個傻吊說了需求變動了,不好意思,不改,等你的第二版文檔出了,我們在考慮變動的事情

我想題主的情況可能和我差不多（姑且這麼認為吧）。。。講一下自己對於文檔這個事的認知吧。。。大學前三年都習慣了先有作品，再有文檔，而作品大多數都是來自於視頻（跟著視頻做出來那種）。。。最後就只需要按照作品寫文檔就行了。。。但是最近做畢設的時候發現，如果這個作品是一個全新的東西，你就會發現這些文檔真的很有用，就拿流程圖和順序圖來說吧，你做一個網站，究竟要通過怎樣的流程來完成一個需求或者功能，在軟體開發之前就需要定下來。這樣的好處是省了很多無用功。。。通過需求和功能做資料庫設計，就節省了你想到一個功能需要的條目再加進去，這種重複的過程。。。還有需求分析，樓主應該聽說過需求模糊導致刪代碼，重新開發，最後工期不夠的情況吧，需求分析就是在軟體開發之前就把需求明確的和用戶定下來。。。最重要的是，即使在這種情況下，就算文檔做得好，即使文檔已經幫你節省了很多彎路的情況下，你依然會遇到彎路。即使需求分析做得再好，客戶還是會變卦。。。總而言之，文檔就是規範化，流程化的東西，他不能讓你不走彎路，只能是少走彎路。。。至於你說的工作中有沒有的情況，我目前看到的情況是，我這種碼農是不用寫的，架構師，項目經理之類的經常要寫。一點淺薄之見。

我現在的崗位叫需求，一多半的時間在寫文檔，同工齡來論，工資略高於一般的程序員。當然並不是說只是寫文檔就可以，但文檔寫的好確實助益不少。

有門課叫軟體工程

那些文檔是留給你以後做功能測試等操作用的。比如你做好的需求分析文檔，你測試的時候需要測試你的軟體功能是否達到當時的需求分析的文檔所定的功能等等。

還有文檔可以讓整個團隊的人盡量對該項目有較為統一的認知。

當然文檔還有很多作用，到時你們軟體工程的課應該會講的。你再自己去帶領個團隊去做個項目就會感受到重要性了。

計算機二級考試的試題說的軟體包括文檔 XD