撰寫的設計文件主要分為：總體概要設計文件 + 詳細設計文件，後簡稱為“概設”+“詳設”。

總設和詳設都應該包含的部分：

（1） 需求：一般以產品的語言描述，這一塊可以拷貝產品需求文件中的story list部分；

（2） 名詞解釋（可選）：非相關領域內的同學需要看到文件需要提前瞭解的一些概念性質的東西；

（3） 設計目標：又分為功能目標和效能目標，功能目標一般是對產品需求的技術描述，效能目標是根據產品給出的資料對效能進行的評估。一般來說，新服務必須要有效能目標一項，效能目標可能會影響設計方案。

除了都應該包含的部分，總體概要設計一般還包含：

（1） 系統架構：一般來說會有個簡單的架構圖，並配以文字對架構進行簡要說明；

（2） 模組簡介：架構圖中如果有很多模組，需要對各個模組的功能進行簡要介紹；

（3） 設計與折衷：設計與折衷是總體概要設計中最重要的部分；

（4） 潛在風險（可選）；

輸出總體概要設計的時候，很多方案還是不確定的，需要在設計評審會議上確認。

總體概要設計重點在“方案折衷”，總體概要設計評審完畢之後，此時應該是所有方案都確認了，需要輸出各模組的詳細設計，詳細設計重點在“詳細”：

（1）總體概要設計結論彙總（可選）：達成一致的結論有個簡要概述，說明詳設是對這些結論的實現；

（2）互動流程：簡要的互動可用文字說明，複雜的互動建議使用流程圖，互動圖或其他圖形進行說明；

（3）資料庫設計

（4）介面形式：有了資料庫+介面+流程，別的同學拿到詳設文件，基本也能夠搞定了；

（5）其他細節：例如公式等；

理論上輸出了詳細設計之後，無論誰拿到了這個詳設文件，都是能夠完成該專案的。

個人實踐分享：

一、 大圖

（1） 大系統或複雜流程，其架構圖或者流程圖會非常大，經常比A4紙或word的一頁大很多，此時不宜在word中直接貼圖形，貼了也看不清，建議將圖放在wiki上，文件中直接貼連結；

（2） 一定要儲存viso或者其他圖形的原始檔，否則今後改動起來要重畫，代價可想而知；

二、 設計與折衷

（1） 設計與折衷是總設中最重要的內容，總設評審中，主要就是討論這些折衷的優劣；

（2） 評審過後，不但要郵件周知結論，還要在總設中進行更新，說明最終決定使用了哪種方案，為什麼使用這種方案；根據自己的經驗，接手別人的模組、專案，拿到程式碼和文件，設計方案對我來說完全是個謎！！！

（3） 有時候因為排期或者其他原因，不一定採用了最優的設計方案，此時更應該在總設中記錄決策的過程與原因；

（4） 最後，設計折衷是一個很好的自我辯解的機會：因為專案進度，或者歷史遺留問題，我不得不採取了一個這樣的設計，不要再罵我了。

三、 效能目標

效能目標是新模組文件必不可少的一部分，很多專案對效能影響較大的話，也必須撰寫效能目標，效能一般來說可能包含以下部分：

（1） 日平均請求：一般來自產品人員的評估；

（2） 平均QPS：日平均請求 除以 4w秒得出，為什麼是4w秒呢，24小時化為86400秒，取使用者活躍時間為白天算，除2得4w秒；

（3） 峰值QPS：一般可以以QPS的2~4倍計算；

網際網路公司，產品迭代塊，專案週期長，基本沒有“文件”一說，但其實寫好文件，對系統和專案未來的維護是非常有幫助的。