當今，電腦已經走進了千家萬戶。而用360清理電腦，好像已經是每家每戶經常乾的事情。而我的一個遠親更為誇張，家裡電腦上裝滿了360的套裝。從瀏覽器到安全衛士再到防毒軟體。清理電腦清理的頻繁極了，而且人家還非常關注360軟體的更新，雖然他不知道是怎麼回事兒，軟體一有更新，就更上癮似的去更新。

       下面我們想一個問題：為什麼360能夠通過不斷的升級程式，達到程式的更新，而有的程式一有新的業務，就非得推倒重來呢？

       當然，初期軟體的架構非常重要了。然而無論在軟體設計之初，還是在軟體的使用過程中，維護過程中，專案經理級別的人物交流等等，等等都離不開的，就是文件。

       說到文件，就必須得說需求、概要、詳細三大文件。俗話說：萬事開頭難，這需求分析文件

       個人認為，需求分析文件中可以有用例描述。用例描述，是使用者與開發人員之間最好的語言，一般情況下，開發人員很難向聽出來使用者想要什麼系統，而使用者用自己的語言描述半天也表述不清自己要的是啥。而用例圖能夠使他們兩者達成共識。

需求分析裡面，還應該放置使用者特點。俗話說：知己知彼，百戰百勝。只有知道了使用者的特點，才能對症下藥，制定出符合他們的需求系統。

       當然需求裡面也需要放一些其他的東西，比如關於效能描述，非功能性要求等等，這裡不多少說，大家可以去百科裡面查。下面說概要。

       那麼，什麼是概要設計文件，寫完之後又要給誰看呢？

       個人認為，概要設計文件的編寫就是要根據需求文件的要求，把系統具體化。將系統的功能進行模組劃分，建立模組的層次結構呼叫關係、確定模組之間的介面和人機介面等等。

        那麼概要設計文件完成後要給誰看呢？經過昨天激勵的討論，大家一定都知道了。首先，概要設計首先要給專案經理級別的人看的，他通過該文件能夠了解該系統的全域性以及該系統的特色和亮點。然後，概要設計也可以拿給使用者看，使用者經過簡單的培訓，大體上讀懂文件應該沒有問題，他們能夠通過該文件瞭解到這的系統是不是他們所需要的系統；再然後，概要設計還可以起到唬人的作用。比如公司之間外包專案，可以拿概要設計文件對自己專案的兩點和難點吹噓一番，給人眼前以震驚的感覺。

       我們知道了概要設計文件要給誰看，那我們的概要設計要包含哪些內容呢？

       概要設計文件需要有該系統的功能介紹，但是不是功能的具體實現。當然，我們可以在裡面放用例圖。我們可以將我們建模的用例圖放到概要設計裡面，使參看該文件的人能夠對系統的功能一目瞭然。

       另外，我們更可以把系統的主要功能介面放在該文件中，閱讀者多圖的吸收能力遠遠大於文字，簡單的幾幅功能圖片，能夠將你係統的主要功能概述出來。

       此外，我們也可以將資料庫的框架設計、表設計以及系統的整體架構體（也就是包圖），放在概要設計裡面。目的還是一樣，讓使用者能夠從全域性瞭解該系統。

        同時，我們也可以將我們的程式設計規範統一在概要設計文件中。

       個人認為，概要設計就好像人的臉一樣，它就是系統的臉。通過這張臉，我們能夠看到這個系統到底漂亮不漂亮，到底值多少錢，到底有沒有面子，能不能唬人。

        有了概要設計，下面我們來看詳細設計。

        詳細設計文件一定要細緻。因為它主要是給程式設計開發人員看的，大家要嚴格根據詳細設計文件來編寫程式碼，所以該文件的準確性一定要高，可以說該文件出問題，那麼系統就一定會有問題。

        詳細設計文件中，要包含各個層次之間的介面。比如我寫UI層的程式碼，那麼我就必須知道BLL有哪些類，有哪些方法、及其它的引數，返回值等。那麼這些就都必須在詳細設計文件中有詳細的中文說明、英文名稱。

        這是介面，那麼詳細設計中還需要放寫什麼呢？我們還可以將時序圖放在裡面。我都知道，時序圖是對指定功能的具體實現，將該系統的主要功能的時序圖放在詳細設計文件中，使開發人員對層與層之間的呼叫關係，方法名、引數、返回值等更加了解。

        另外，系統的其他方面的具體細節，也應該在詳細設計文件中宣告。比如系統的精度問題、程式必要的功能、效能的描述等。

        概要設計文件給系統分了模組，而詳細設計就要把這各個模組逐步細化，直到開發人員能夠較輕鬆的看懂為止。