寫完文檔後，本來想寫一篇具體的文檔的總結的，後來看大家都寫的具體文檔總結，於是我就想：我還是寫一些跟大家不一樣的東西吧。

所以，我就說說我對各個文檔的宏觀理解吧。

老規矩，先來一張圖：

這是我們的文檔，也可以說這是軟件的前半生。它包括了我們的軟件的從計劃——設計——實現——測試的過程，至於之後的維護，估計是沒有算在軟件開發的文檔裏面，不過可以肯定的是絕對會有文檔的。

文檔是一種交流的方式，也是一種工作的證據，往好了說，文檔便於團隊去開發軟件；往壞了說，軟件就是一種證據，人家需求上寫了，你的軟件上沒有實現該功能，那就是你軟件開發的問題。

那麽，各個文檔主要到底都寫了些啥呢？又是寫給誰看的呢？

先是計劃階段，這個階段總共會產生兩個比較重要的文檔：可行性分析和軟件需求說明書。

先說可行性分析，這個文檔的作用是判斷你的開發項目是否可以開發，由項目開發人員，或者是專門的做可行性調查的公司來寫的一個文檔。可行性分析報告一般寫給公司的領導，由領導批準後，才可以開始項目。

這個文檔主要通過軟件的投資、收益、風險、法律等方面研究本項目開發會不會獲得利潤，最後給出一個該軟件是否可以開發的報告。ps：說白了，這個文檔的作用就是給老板寫個開發本軟件有啥好處的文檔。便於老板做決定是否開發該軟件。

老板決定要開發軟件後，就需要進一步的研究即將開發的軟件：這個軟件都需要實現一些啥功能呢？客戶對軟件有啥要求呢？

這就是需求說明書需要解決的主要問題了。軟件的計劃階段的最後的產物就是需求說明書了，特別容易理解，需求說明書，肯定是說軟件的需求的。

需求說明書一般應該由系統分析員和客戶一起寫，如果分工細一些，就應該由需求分析員來寫，通常是系統分析員寫後讓客戶確定。需求說明書即是寫給用戶看的，又是寫給團隊看的。客戶、領導、項目組成員以及合作公司等等和項目相關的人幾乎都需要知道項目的需求。ps:需求說明書其實就是問下客戶，你需要個什麽樣的東西，然後將用戶的需要記下來，留著以後需要的時候看。

好，系統分析結束後就該軟件的設計階段了，設計又分為概要設計、詳細設計和數據庫設計。

概要設計：概要設計是依據需求說明書，將軟件的結構、軟件的模塊、模塊的層次、模塊的關系、每個模塊的大概功能描述出來的文檔，應該是由系統分析員（歸設計組組長管理）去寫這個文檔，作為軟件整體的大概描述。PS：感覺就像是問路一樣，概要設計給出的回答是：XX家在XX村，而XX村是屬於XX鎮的。

詳細設計：詳細設計說的是具體的功能實現，說出了軟件都有哪些具體的功能。是對概要設計的一個細化，就是詳細設計每個模塊實現算法，所需的局部結構。ps：詳細設計給出的回答是：去XX家的話，你要先左拐，到路口右拐，到下一個路口再左拐、、、

考慮到篇幅問題，接下來的文檔說明請看軟工總結文檔（二）。

文檔總結（一）——文檔的概述