轉自：http://www.habadog.com/2012/10/18/rd-how-to-write-document/
rd需要撰寫的設計文檔主要分爲：總體設計文檔 + 詳細設計文檔，後簡稱爲“總設”+“詳設”。
總設和詳設都應該包含的部分：
（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倍計算；
我們在做壓力測試時，需要關注壓力達到“峯值QPS”時，服務器的cpu，內存，io，net等等服務器性能參數。
