1. 演算法文檔怎麼寫
雞數=輸入雞數*2-輸入免數/2免數=輸入兔數/2-輸入雞數
2. 做軟體項目設計文檔怎麼寫啊
按照以下格式填就好了，不過是我自己寫的，有不好的地方大家互相學習修改一下~
詳細設計文檔規范
1.0概述
這部分提供對整個設計文檔的概述。描述了所有數據，結構，介面和軟體構件級別的設計。
1.1 目標和對象
描述軟體對象的所有目標。
1.2 陳述范圍
軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。
1.3 軟體內容
軟體被置於商業或者產品線中，討論相關的戰略問題。目的是讓讀者能夠對「宏圖」有所了解。
1.4 主要系統參數
任何商務軟體或者產品線都包含軟體規定、設計、實現和測試的說明和規范。
2.0 數據設計
描述所有數據結構包括內部變數，全局變數和臨時數據結構。
2.1 內部軟體數據結構
描述軟體內部的構件之間的數據傳輸的結構。
2.2 全局數據結構
描述主要部分的數據結構。
2.3 臨時數據結構
為臨時應用而生成的文件的描述。
2.4 資料庫描述
作為應用程序的一部分，描述資料庫結構。
3.0 結構化和構件級別設計
描述程序結構。
3.1 程序結構
詳細描述應用程序所選定的程序結構。
3.1.1 結構圖
圖形化描述結構。
3.1.2 選擇性
討論其它可供考慮的結構。選定3.1.1中結構類型的原因。
3.2 構件描述
詳細描述結構中的每個軟體構件。
3.2.1 構件過程敘述(PSPEC)
描述構件的過程。
3.2.2 構件介面描述
詳細描述構件的輸入和輸出。
3.2.3 構件執行細節
每個構件的詳細演算描述。
3.2.3.1 介面描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 規范/限制
]3.2.3.4 本地數據結構
3.2.3.5 在3.2.3.6設計中包含的執行結果
3.3 軟體介面描述
軟體對外界的介面描述
3.3.1機器對外介面
與其他機器或者設備的介面描述。
3.3.2系統對外介面
對其它系統、產品和網路的介面描述。
3.3.3與人的介面
概述軟體與任何人的界面。
4.0 用戶界面設計
描述軟體的用戶界面設計。
4.1 描述用戶界面
詳細描述用戶界面，包括屏幕顯示圖標、圖片或者類型。
4.1.1 屏幕圖片
從用戶角度描述界面。
4.1.2 對象和操作
所有屏幕對象和操作的定義。
4.2 界面設計規范
用戶界面的設計和實現的規范和標准。
4.3 可見構件
實現的GUI可見構件說明。
4.4 UIDS描述
用戶界面開發系統描述。
5.0約束、限制和系統參數
會影響軟體的規格說明、設計和實現的特殊事件。
6.0測試標准
測試策略和預備測試用例描述。
6.1 測試的類別
規定實施測試的類別，包括盡量詳細的描述。這里是針對黑盒測試現象的描述。
6.2期待軟體反饋
測試期待的結果描述。
6.3執行界線
特殊執行需要的說明。
6.4 重要構件確認
決定性構件或者需要特殊注意的構件的測試確認。
7.0附錄
設計說明的補充信息。
7.1系統可跟蹤矩陣
一個定期回歸系統規格跟蹤軟體需求的矩陣。
7.2 產品戰略
如果規格說明書是為一個產品設計的，描述相關的產品戰略。
7.3 使用分析演算法
描述所有分析活動所使用到的分析演算法。
7.4 補充信息 (如果有需要特別說明的)
3. 計算機類論文怎麼寫
作為一個著重研究信息系統開發、應用的專業，計算機畢業論文的寫作應該更貼合實際出來，可能有很多剛拿到題目的學生不知道改如何著手，下面我們就來了解一下計算機畢業論文怎麼寫？
一、計算機畢業論文的寫作方法
1、前言部分
前言部分也常用"引論"、"概論"、"問題背景"等做標題，在這部分中，主要介紹論文的選題。
首先要闡明選題的背景和選題的意義。選題需強調實際背景，說明在計算機研究中或部門信息化建設、企業管理現代化等工作中引發該問題的原因，問題出現的環境和條件，解決該問題後能起什麼作用。結合問題背景的闡述，要使讀者感受到此選題確有實用價值和學術價值，因而有研究和開發的必要性。
前言部分常起到畫龍點睛的作用。選題實際又有新意，表明作者的研究方向正確，設計開發工作有價值。對一篇論文來說，前言寫好了，就會吸引讀者，使他們對作者的選題感興趣，願意進一步了解作者的工作成果。
2、綜述部分
任何一個課題的研究或開發都是有學科基礎或技術基礎的。綜述部分主要闡述選題在相應學科領域中的發展進程和研究方向，特別是近年來的發展趨勢和最新成果。通過與中外研究成果的比較和評論，說明自己的選題是符合當前的研究方向並有所進展，或採用了當前的最新技術並有所改進，目的是使讀者進一步了解選題的意義。
綜述部分能反映出畢業設計學生多方面的能力。首先是結合課題任務獨立查閱中外文獻資料的能力，通過查閱文獻資料，收集各種信息，了解同行的研究水平，在工作和論文中有效地運用文獻，這不僅能避免簡單的重復研究，而且也能使論文工作有一個高起點。
其次，還能反映出綜合分析的能力。從大量的文獻中找到可以借鑒和參考的信息，這不僅要有一定的專業知識水平，還要有一定的綜合能力。對同行研究成果是否能抓住要點，優缺點的評述是否符合實際，恰到好處，這和一個人的分析理解能力是有關的。
值得注意的是，要做好一篇畢業論文，必須閱讀一定量（2~3篇）的近期外文資料，這不僅反映自己的外文閱讀能力，而且有助於體現論文的先進性。
3、方案論證
在明確了所要解決的問題和課題綜述後，很自然地就要提出自己解決問題的思路和方案。在寫作方法上，一是要通過比較，顯示自己方案的價值，二是讓讀者了解方案的獨到之處或有創新點的思路、演算法和關鍵技術。
在與文獻資料中的方案進行比較時，首先要闡述自己的設計方案，說明為什麼要選擇或設計這樣的方案，前面評述的優點在此方案中如何體現，不足之處又是如何得到了克服，最後完成的工作能達到什麼性能水平，有什麼創新之處（或有新意）。如果自己的題目是總方案的一部分，一定要明確說明自己承擔的部分，以及對整個任務的貢獻。
4、論文主體
在這部分中，要將整個研究開發工作的內容，包括理論分析、總體設計、模塊劃分、實現方法等進行詳細的論述。論文主體部分要佔4/5左右。主體部分的寫法，視選題的不同可以多樣，研究型論文和應用開發型論文的寫法就有明顯的不同。
研究型的論文，主體部分一般應包括：理論基礎，數學模型，演算法推導，形式化描述，求解方法，軟硬體系統的實現及調試，測試數據的分析及結論。
要強調的是，研究型論文絕不是從推理到推理的空洞文章。研究型論文也應有實際背景，也應有到企業和實際部門調研的過程，並在實際調查研究中獲取信息，發現問題，收集數據和資料。在研究分析的基礎上，提出解決實際問題的、富有創建性的結論。
應用開發型的論文，主體部分應包括：總體設計，模塊劃分，演算法描述，編程模型，數據結構，實現技術，實例測試及性能分析。
以上內容根據任務所處的階段不同，可以有所側重。在整個任務初期的論文，可側重於研究與設計，在任務後期的論文可側重於實現與應用。但作為一篇完整的論文應讓讀者從課題的原理設計，問題的解決方法，關鍵技術以及性能測試都有全面的了解，以便能准確地評判論文的質量。
論文主體部分的內容一般要分成幾個章節來描述。在寫作上，除了用文字描述外，還要善於利用各種原理圖、流程圖、表格、曲線等來說明問題，一篇條理清晰，圖文並茂的論文才是一篇好的論文。
5、測試及性能分析
對理工專業的畢業設計論文，測試數據是性能評價的基礎，必須真實可靠。通過測試數據，論文工作的成效可一目瞭然。根據課題的要求，可以在實驗室環境下測試，也可以在工作現場測試。
在論文中，要將測試時的環境和條件列出，因為任何測試數據都與測試環境和條件相關，不說明測試條件的數據是不可比的，因此也是無意義的。
測試一般包括功能測試和性能測試。功能測試是將課題完成的計算機軟硬體系統（子系統）或應用系統所要求達到的功能逐一進行測試。性能測試一般是在系統（子系統）的運行狀態下，記錄實例運行的數據，然後，歸納和計算這些數據，以此來分析系統運行的性能。
測試實例可以自己設計編寫，也可以選擇學科領域內公認的、有一定權威性的測試實例或測試集。原則是通過所選擇（設計）的實例的運行，既能准確反映系統運行的功能和性能，與同類系統又有可比性。只有這樣，論文最後為自己工作所做的結論才有說服力。
6、結束語
這一節篇幅不大，首先對整個論文工作做一個簡單小結，然後將自己在研究開發工作中所做的貢獻，或獨立研究的成果列舉出來，再對自己工作的進展、水平做一個實事求是的評論。但在用"首次提出"、"重大突破"、"重要價值"等自我評語時要慎重。
7、後記
在後記中，主要表達對導師和其他有關教師和同學的感謝之意。對此，仍要實事求是，過分的頌揚反而會帶來消極影響。這一節也可用"致謝"做標題。
8、參考文獻
中外文的參考文獻應按照規范列舉在論文最後。這一部分的編寫反映作者的學術作風。編寫參考文獻要注意：（1）要嚴格按照規范編寫，特別是外文文獻，不要漏寫、錯寫；（2）論文內容和參考文獻要前後對應，正文中凡引用參考文獻的地方應加註；（3）列出的文獻資料應與論文課題相關，無關的文獻只會使讀者感到作者的研究目標很分散；（4）選擇的參考文獻應主要是近期的。
二、計算機寫作注意事項
1、設計（論文）題目：按照小題目。封面XXXXX學院畢業設計（論文）、 屆 分院（系）
2、摘要：不要主語，英文中無法表達時可用被動語態
3、關鍵詞：體現設計（論文）主要工作的詞語
4、目錄：自動生成，1.1.1的格式，最多到1.1.1.1 5、正文中文獻引用要客觀，別人的成果要說明，不要據為己有；自己的成果要突出。不清楚的圖必須修改（可用word畫或者AutoCAD畫），表格盡量採用三線表
6、參考文獻：至少要有兩篇英文文獻
7、致謝（不是致辭）
8、附錄（若多於一個附錄，可用附錄一、附錄二，……）
9、各部分格式要求，嚴格按照畢業設計手冊執行
三、計算機論文編輯技巧
1、文檔結構圖的妙用 格式修改時可先將全文設置為正文格式（新羅馬與宋體的博弈），然後將三級標題以上標題按照三級標題提出來，再將二級標題以上標題按照二級標題提出來，最後將一級標題提出來。提出標題時注意使用大綱級別。 提出大綱級別後，可用文檔結構圖輕松導航文檔。還可自動生成目錄（插入-引用-索引和目錄-目錄）。
2、圖的裁剪與組合（建議採用浮於文字上方的方式）、文本框的妙用、公式的編輯（變數用斜體、下標用的i、j、k用斜體，其餘用正體。公式中出現漢字怎麼辦？用拼音加加輸入法輸入漢字）
3、表格的編輯
4、上下標的使用（自定義word菜單）
5、分節符的使用
6、目錄自動生成（頁碼的問題），目錄可單獨取文件名（寫字板的運用），也可放到正文前面
7、樣式與格式的自動更新功能
8、頁眉設置（去掉橫線）
9、文檔的備份（防止病毒感染、U盤丟失、計算機故障）
4. 急！！求二十一個演算法的文檔，要求寫出： 1 輸入什麼，輸出什麼， 2 形式化定義，即用數學符號表示
隨便什麼演算法都可以嗎
5. 對已有演算法進行研究的小論文怎麼寫
本科使用知網論文抄襲檢測系統（PMLC）價格略貴等校統安排面些查重技巧望採納：
論文抄襲檢測算
1.論文段落與格式：論文檢測基本都整篇文章傳傳論文檢測軟體首先進行部劃交終稿件格式抄襲率影響同段落劃能造幾十欄位落檢測我通劃段落降低抄襲率
2.資料庫：論文檢測半針已發表畢業論文期刊文章議論文進行匹配資料庫包含網路些文章給家透露書籍沒包含檢測資料庫前朋友本研究性著作摘抄量文字沒查能看效
3.章節變換：同改變章節順序或者同文章抽取同章節拼接文章抄襲檢測結影響幾乎零所論文抄襲檢測師建議家要抄襲幾篇文章或者幾十篇文章能關
4.標注參考文獻：參考別文章抄襲別文章檢測軟體何界定其實簡單我論文加參考文獻引用符號抄襲檢測軟體都統看待軟體閥值般設定1%例篇文章5000字,文章1%50字抄襲於50即使加參考文獻判定抄襲
5.字數匹配：論文抄襲檢測系統相比較嚴格要於20單位字數匹配致認定抄襲前提滿足第4點參考文獻標注
論文查重修改技巧全：
：外文文獻翻譯
查閱研究領域外文文獻特別高水平期刊文獻比ScienceNatureWaterRes等其理論講解翻譯文放自論文
優點：1、每語言習慣同翻譯漢語必同即使同段文字同翻譯現抄襲情況2、外文文獻閱讀提升自身英語水平拓展專業領域視野
缺點：英文特別專業英文同實施起比較費勁
二：變化措辭
別論文文字或按照意思重寫或變換句式結構更改主語態或更換關鍵詞或通增減卻屬於經典名句按照經典加引用
優點：1.文字修改按照知網程序算要現連續13字重復及關鍵詞重復標紅2.論文每字每句都指掌爛熟於答辯亦魚水
缺點：逐字逐句改費費力
三：減尾間換語序
別論文文字尾換掉間留留部改句句式結構發改變再自行修改語病即順利躲論文查重
優點：便快捷段段修改
缺點文沒費勁要想半
四：轉換圖片
別論文文字截圖片放自論文知網論文查重系統目前能查文字能查圖片表格躲論文查重
優點：比改句序更加便快捷
缺點：用順手容易現整頁都圖片情況影響整論文字數統計
五：插入文檔
某些參考引用文字通word文檔形式插入論文
優點：比四更甚籌該所插入文檔進行重新編輯圖片轉換便於再修改
缺點：沒發現
六：插入空格
文章所字間插入空格空格字間距調論文查重根據詞基礎空格切斷詞語自略論文查重系統
優點：論文查重系統原理發靠性高
缺點：工作量極課考慮通宏完宏編制需要研究
七：自原創
自手寫論文寫作要原文復制粘貼;要確加引用
優點：基本絕擔論文查重通哪怕查重系統閾值調再低
缺點：說優缺點寫完篇畢業論文能死掉更腦細胞
論文查重修改規律：
論文查重匹配程句單位句重復容易判定重復所：
1)確經典句用標章節附註式參考文獻表達
2)般引用採用羅嗦原句省略主語、謂語、等等添加全反哪怕字勝利
3)採用橫刀些句除用些代詞替代
4)或者用洋鬼原文洋名文直接用英文英文直接用文或文全姓名用文名文名找齊替換文姓名
5)故意些縮寫英文邊加(注釋)(畫蛇添足)總每句都變化哪怕增加字或減少字都勝利
6)引用引用標號要輕易使用句號寫句號句號面剽竊(盡管自已認引用)所引用沒結束前盡量使用號些引用標放句號面應該句號前
7)文字轉換表格、表格基本論文查重文字變圖形、表格變圖形目絕檢查重復剽竊
6. 數據結構演算法前面的頭文件該如何寫主函數該如何寫
一、頭文件
頭文件一般包含類、子程序、變數和其他標識符的前置聲明。需要在一個以上源文件中被聲明的標識符可以被放在一個頭文件中，並在需要的地方包含這個頭文件。
頭文件用於讓編譯器持有正確的標識符詞典。頭文件不正確的時候，最常出現的錯誤是「標識符未定義」（identifier undefined）。要修正這些問題，事實上應該去查詢你所使用的標識符（函數、變數等）的文檔。
以VC為代表的Windows系列的IDE中，快捷鍵Ctrl+F1可以讓你查詢游標所在標識符的文檔，一般來說其中都會有所需的頭文件信息。而Linux系，可以直接在shell（ash、bash、csh、zsh等）中使用man，比如你想查詢strstr函數，可以在shell中輸入man strstr 並回車。
二、主函數
主函數是程序的執行入口函數。其函數名為 main，返回值為 int 。包含全部輸入參數的完整形式是：
intmain(intargc,char*argv[],char*envp[])
特別地，對於蘋果家的東西，它還會傳給你第四個參數：
intmain(intargc,char*argv[],char*envp[],char*apple[])
當然，因為C/C++語言的設計規范，所有編譯器都支持不給出全部參數的寫法。所以你可以只寫兩個參數又或者不寫參數。更進一步，如果對於所生成程序，你不關心它的命令行如何寫的，那你可以自己隨意定義參數類型和個數（對此你可以在IOCCC常式中找到範本）。
三、參考
需要更多信息可以在網上查找，比如搜索「wiki 主函數」可以看到相應的網路頁。
7. 軟體開發文檔應該如何寫
如果我們知道軟體文檔的價值，那麼為什麼不經常使用它呢？對於新手，大多數軟體文檔都存在很多下面提到的這些問題：
· 糟糕的語法和/或拼寫錯誤的詞語
· 不完整
· 過期或不準確
· 篇幅太長
http://www.mscto.com
· 首字母縮寫沒有解釋或術語不專業
http://www.mscto.com
· 難於找到信息或在文檔中定位 軟體開發網
存在這些問題的主要原因是軟體文檔通常沒有被給予足夠的重視。項目預算被迫將主要活動花在了開發工作上，在那裡管理層很容易看到他們的收益。值得投入成本的文檔工作通常都是主觀的，而且通常被刻畫為需要避免的成本，因為它們被認為不能產生投資回報（ROI）。很多項目經理將客戶所需要的最少文檔看作是「鍍金」。
軟體開發網
軟體文檔的另外一個麻煩來源是文檔的作者。很多應用程序開發經理覺得軟體文檔是開發工作的一個標准部分，因此，要求他們的開發人員在編碼時也編寫軟體文檔。
雖然這在理論上是說得過去的，但是不應該將開發人員看成文檔作者。很簡單，技術人員只被培訓如何開發，而沒有被培訓如何寫文檔。為了解決這一問題，很多應用程序開發經理嘗試通過聘請一些技術性寫手或商業分析人員來提高他們的軟體文檔的質量。這就導致出現了一個相反的問題：技術寫手和商業分析人員通常只有有限的技術技能。
解決方案依賴於文檔，文檔應該迎合其潛在讀者的口味。這方面的通用規則是要求使用一個協同工作方法來編寫文檔，這種方法允許開發人員和寫手發揮他們的長處。例如，如果潛在的讀者是系統設計人員，那麼開發人員應該提供詳細的輸入，但是允許技術寫手去組織和編輯內容以使文檔符合語法。
不管潛在的讀者還是被選中的讀者，軟體文檔的質量與其可使用性相關，以下六個屬性可以用來測量軟體文檔的可使用性：
· 適用性：文檔提供了相關的信息嗎？
· 合時性：文檔所提供的是當時的信息嗎？
· 正確性：文檔所提供的信息正確嗎？
· 完整性：文檔是不是足夠詳細？
· 可用性：文檔隨手可用嗎？
· 可使用性：能夠快速直觀地找
希望能助你一臂之力
8. 如何學習寫程序設計文檔
寫程序設計文檔，要注意簡潔和邏輯性，需要明確的是：文檔並不是進行設計的目標，也不是設計過程中額外的工作。具體模塊和步驟為：
1.需求分析
需求分析的結果通常需要使用需求說明文檔來描述，目前主流的需求描述方法包括：用戶例圖、用戶故事等方式。這些方式有所不同的側重，其核心思想就是描述清楚用戶的使用場景。
2.功能設計
對於主要是用戶界面的軟體項目來說，功能設計可以看作是畫出原型界面，描述使用場景，獲得用戶認可的過程。而對於沒有界面的軟體項目來說，則功能設計與需求分析的區分更為模糊。
3.系統架構設計
系統架構設計是一個非常依賴於經驗的設計過程。需要根據軟體項目的特定功能需求和非功能性需求進行取捨，最終獲得一個滿足各方要求的系統架構。系統架構的不同，將很大程度上決定系統開發和維護是否能夠較為容易的適應需求變化，以及適應業務規模擴張。
4.模塊/子系統概要設計
模塊/子系統的概要設計，由架構師參與，核心設計和開發人員負責的方式進行。
在概要設計工作中，需要在架構確定的開發路線的指導下，完成模塊功能實現的關鍵設計工作。在概要設計階段，需要關注於模塊的核心功能和難點進行設計。
5.模塊詳細設計
在瀑布式開發模型中，模塊的詳細設計會要求比較嚴格，將所有類進行詳細設計。除了一些對於系統健壯性要求非常嚴格的軟體項目，如國防項目，金融項目還要求有詳細設計文檔之外。其他的項目大多採用其他方式來處理這樣的工作，如自動化測試等。
綜上所述，軟體設計文檔作為軟體開發團隊的溝通、理解、知識共享的手段，具有非常重要的意義。
9. 如何寫詳細設計文檔
在大多數軟體項目中，要末不作詳細設計，要麼開發完成後再補詳細設計文檔，質量也不容樂觀，文檔與系統往往不能同步，使詳細設計文檔完全流於形式，對工作沒有起到實際的幫助。
·
詳細設計是相對概要設計而言的，是瀑布開發流程的一個重要環節，在概要設計的高層設計的基礎上，從邏輯上實現了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現。
詳細設計文檔的內容包括各個模塊的演算法設計，
介面設計，
數據結構設計，交互設計等。必須寫清楚各個模塊/介面/公共對象的定義，列明各個模塊程序的
各種執行條件與期望的運行效果，還要正確處理各種可能的異常。
·
在開發過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟體系統的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，
詳細設計實際上是對系統的一次邏輯構建，可以有效驗證需求的完整性及正確性。
如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發人員所能參考的資料就是需求規格說明書及頁面原型、資料庫設計等，不能直接進行開發，需要進行信息的溝通，把頁面原型不能體現的設計講清楚，這樣既容易遺忘，也容易發生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發人員的溝通工具，把靜態頁面無法體現的設計體現出來，包含整體設計對模塊設計的規范，體現對設計上的一些決策，例如選用的演算法，對一些關鍵問題的設計考慮等等，使開發人員能快速進入開發，提高溝通效率，減少溝通問題。
對於系統功能的調整，後期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關系、模塊所引用的資料庫設計、重要操作的處理流程、重要的業務規則實現設計等等信息，提供了對模塊設計的概述性信息，闡明了模塊設計上的決策，配合代碼注釋，可以相對輕松讀懂原有設計。
·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發人員無事可作。對於現在一般的以資料庫為中心的管理系統而言，這個工作始終是要作的，區別只不過是不是形成專門文檔，形成文檔可能會多花一兩周時間，但相對於規避的風險和問題來說，也是值得的，另外由於現在高級語言的流行，所以更詳細的設計應該直接體現在代碼的設計上，而文檔則只體現設計上的一些決策，協調整體設計與模塊設計的關系，把頁面原型所不能體現的設計情況文檔化，所以所花費的時間是有限的。
設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。
對於這個問題，一個對策是上邊所提到的，文檔只體現設計上的決策，頁面原型所不能反映的信息，詳細設計只體現總體設計對模塊設計的一些考慮，例如對功能的資料庫設計等等，而具體的實現實現，則到代碼中再去實現，相關的設計也僅體現在代碼中。
需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統的同步就很難得到保障了，且造成多餘的工作量。文檔的內容易流於形勢，質量糟糕，不能成為開發人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，後作開發，從工作流程上切實保障文檔與系統的同步，二是要規範文檔質量，對文檔該寫什麼，不該寫什麼，標準是什麼，粒度是什麼，語法應該如何組織，有明確的標准和考慮，同時，建立審計文檔評審、審核制度，充分保障系統的使用。·
首先是文檔的內容，根據項目和團隊的不同，詳細設計文檔的內容也有所不同，一般說來，粒度不宜過細，不能代替開發人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模塊、整體設計的關系、操作的處理流程，對業務規則的設計考慮等，有一個標准為，凡是頁面原型、需求規格說明書所不能反映的設計決策，而開發人員又需要了解的，都要寫入文檔。
其次是文檔所面向的讀者，主要為模塊開發人員、後期維護人員，模塊開發人員通過詳細設計文檔和頁面原型來了解所開發的功能，後期維護人員通過實際系統、模塊代碼、詳細設計文檔來了解一個功能。
再有就是誰來寫文檔，因為文檔主要考慮的是設計上的決策，所以寫文檔的人應該為負責、參加設計的技術經理、資深程序員，根據團隊情況和項目規模、復雜度的不同，也有所不同。
還需要保證文檔的可讀性、准確性、一致性，要建立嚴格的文檔模板及標准，保證文檔的可讀性及准確性，同時建立審核及設計評審制度，來保障設計及文檔的質量，另外在工作流程中要強調，要先設計、先寫文檔，再進行開發。