當今，電腦已經走進了千家萬戶。而用360清理電腦，好像已經是每家每戶經常干的事情。而我的一個遠親更為誇張，家里電腦上裝滿了360的套裝。從瀏覽器 到安全衛士再到殺毒軟件。清理電腦清理的頻繁極了，而且人家還非常關注360軟件的更新，雖然他不知道是怎么回事兒，軟件一有更新，就更上癮似的去更新。
下面我們想一個問題：為什么360能夠通過不斷的升級程序，達到程序的更新，而有的程序一有新的業務，就非得推倒重來呢？
當然，初期軟件的架構非常重要了。然而無論在軟件設計之初，還是在軟件的使用過程中，維護過程中，項目經理級別的人物交流等等，等等都離不開的，就是文檔。
說到文檔，就必須得說需求、概要、詳細三大文檔。俗話說：萬事開頭難，這需求分析文檔，就是該系統的頭兒，它主要解決“做什么”的問題。需求分析時，系統分析員和軟件工程師對客戶的需求進行充分理解，然后把業務需求理解整理成文檔。該文檔便供架構師對該系統進行架構，包括后續的畫UML圖，編寫概要設計文檔和詳細設計文檔。
個人認為，需求分析文檔中可以有用例描述。用例描述，是用戶與開發人員之間最好的語言，一般情況下，開發人員很難向聽出來用戶想要什么系統，而用戶用自己的語言描述半天也表述不清自己要的是啥。而用例圖能夠使他們兩者達成共識。
需求分析里面，還應該放置用戶特點。俗話說：知己知彼，百戰百勝。只有知道了用戶的特點，才能對症下葯，制定出符合他們的需求系統。
當然需求里面也需要放一些其他的東西，比如關於性能描述，非功能性要求等等，這里不多少說，大家可以去百科里面查。下面說概要。
那么，什么是概要設計文檔，寫完之后又要給誰看呢？
個人認為，概要設計文檔的編寫就是要根據需求文檔的要求，把系統具體化。將系統的功能進行模塊划分，建立模塊的層次結構調用關系、確定模塊之間的接口和人機界面等等。
那么概要設計文檔完成后要給誰看呢？經過昨天激勵的討論，大家一定都知道了。首先，概要設計首先要給項目經理級別的人看的，他通過該文檔能夠了解該系統的 全局以及該系統的特色和亮點。然后，概要設計也可以拿給用戶看，用戶經過簡單的培訓，大體上讀懂文檔應該沒有問題，他們能夠通過該文檔了解到這的系統是不 是他們所需要的系統；再然后，概要設計還可以起到唬人的作用。比如公司之間外包項目，可以拿概要設計文檔對自己項目的兩點和難點吹噓一番，給人眼前以震驚 的感覺。
我們知道了概要設計文檔要給誰看，那我們的概要設計要包含哪些內容呢？
概要設計文檔需要有該系統的功能介紹，但是不是功能的具體實現。當然，我們可以在里面放用例圖。我們可以將我們建模的用例圖放到概要設計里面，使參看該文檔的人能夠對系統的功能一目了然。
另外，我們更可以把系統的主要功能界面放在該文檔中，閱讀者多圖的吸收能力遠遠大於文字，簡單的幾幅功能圖片，能夠將你系統的主要功能概述出來。
此外，我們也可以將數據庫的框架設計、表設計以及系統的整體架構體（也就是包圖），放在概要設計里面。目的還是一樣，讓用戶能夠從全局了解該系統。
同時，我們也可以將我們的編程規范統一在概要設計文檔中。
個人認為，概要設計就好像人的臉一樣，它就是系統的臉。通過這張臉，我們能夠看到這個系統到底漂亮不漂亮，到底值多少錢，到底有沒有面子，能不能唬人。
有了概要設計，下面我們來看詳細設計。
詳細設計文檔一定要細致。因為它主要是給編程開發人員看的，大家要嚴格根據詳細設計文檔來編寫代碼，所以該文檔的准確性一定要高，可以說該文檔出問題，那么系統就一定會有問題。
詳細設計文檔中，要包含各個層次之間的接口。比如我寫UI層的代碼，那么我就必須知道BLL有哪些類，有哪些方法、及其它的參數，返回值等。那么這些就都必須在詳細設計文檔中有詳細的中文說明、英文名稱。
這是接口，那么詳細設計中還需要放寫什么呢？我們還可以將時序圖放在里面。我都知道，時序圖是對指定功能的具體實現，將該系統的主要功能的時序圖放在詳細設計文檔中，使開發人員對層與層之間的調用關系，方法名、參數、返回值等更加了解。
另外，系統的其他方面的具體細節，也應該在詳細設計文檔中聲明。比如系統的精度問題、程序必要的功能、性能的描述等。
概要設計文檔給系統分了模塊，而詳細設計就要把這各個模塊逐步細化，直到開發人員能夠較輕松的看懂為止。