1.1 編寫目的
說明編寫詳細設計方案的主要目的。
說明書編制的目的是說明乙個軟體系統各個層次中的每個程式（每個模組或子程式）和資料庫系統的設計考慮，為程式設計師編碼提供依據。
如果乙個軟體系統比較簡單，層次很少，本檔案可以不單獨編寫，和概要設計說明書中不重複部分合併編寫。
方案重點是模組的執行流程和資料庫系統詳細設計的描述。
1.2 背景
應包含以下幾個方面的內容：
a. 待開發軟體系統名稱；
b. 該系統基本概念， 如該系統的型別、從屬地位等；
c. 開發專案組名稱。
1.3 參考資料
列出詳細設計報告引用的文獻或資料，資料的作者、標題、出版單位和出版日期等資訊，必要時說明如何得到這些資料。
1.4 術語定義及說明
列出本文件中用到的可能會引起混淆的專門術語、定義和縮寫詞的原文。
2.1 任務和目標
說明詳細設計的任務及詳細設計所要達到的目標 。
2.1.1 需求概述
對所開發軟體的概要描述, 包括主要的業務需求、輸入、輸出、主要功能、效能等，尤其需要描述系統效能需求。
2.1.2 執行環境概述
對本系統所依賴於執行的硬體，包括作業系統、資料庫系統、中介軟體、介面軟體、可能的效能監控與分析等軟體環境的描述，及配置要求。
2.1.3 條件與限制
詳細描述系統所受的內部和外部條件的約束和限制說明。包括業務和技術方面的條件與限制以及進度、管理等方面的限制。
2.1.4 詳細設計方法和工具
簡要說明詳細設計所採用的方法和使用的工具。如hipo圖方法、idef（i2def）方法、e－r圖，資料流程圖、業務流程圖、選用的case工具等，盡量採用標準規範和輔助工具。
主要對系統級的需求進行分析。首先應對需求分析提出的企業需求進一步確認，並對由於情況變化而帶來的需求變化進行較為詳細的分析。
3.1 詳細需求分析
包括：3.2 詳細系統執行環境及限制條件分析介面需求分析
包括：著重解決系統總體結構確認及介面劃分問題。
4.1 系統總體結構確認
對系統組成、邏輯結構及層次進行確認，對應用系統、支撐系統及各自實現的功能進行確認，細化整合設計及系統工作流程，特別要注意因軟體的引進造成的系統本身結構和公司其他系統的結構變化。包括：
ÿ 系統組成、邏輯結構及層次確認
ÿ 應用系統結構確認
ÿ 支撐系統結構確認
ÿ 系統整合確認
ÿ 系統工作流程確認
4.2 系統詳細介面劃分
4.2.1 應用系統與支撐系統的詳細介面劃分
應用系統與支撐系統之間的介面包括系統主伺服器與其他伺服器的服務範圍及訪問方式，網路及資料庫對應用系統的支撐方式，全域性資料的管理與訪問方式等。
4.2.2 系統內部詳細介面劃分
系統各功能之間的介面包括覆蓋範圍，模組間功能呼叫涉及到的系統模組及方法，全域性資料格式，系統效能要求等。
5.1 系統結構設計及子系統劃分
對系統的組成及邏輯結構進行設計前確認。
劃分系統功能模組或子系統（如果有或者有必要，特別是大型的軟體系統）。
5.2 系統功能模組詳細設計
按結構化設計方法，在系統功能逐層分解的基礎上，對系統各功能模組或子系統進行設計。此為詳細設計的主要部分之一。
用層次圖描述系統的總體結構、功能分解及各個模組之間的相互呼叫關係和資訊互動，用ipo圖或其他方法描述各模組完成的功能。 以上建議採用hipo圖進行功能分解與模組描述，更高的要求建議採用idef0方法進行功能模型設計。
詳細設計應用系統的各個構成模組完成的功能及其相互之間的關係，用ipo或結構圖描述各模組的組成結構、演算法、模組間的介面關係，以及需求、功能和模組三者之間的交叉參照關係。
每個模組的描述說明可參照以下格式：
模組編號：
模組名稱：
輸入：處理：
演算法描述：
輸出：其中處理和演算法描述部分主要採用偽碼或具體的程式語言完成。
對詳細設計更高的要求建議用idef0圖進行各功能模組的設計。
如果對軟體需進行二次開發（包括功能擴充套件、功能改造、使用者介面改造等），則相應的設計工作應該設立子課題完成。
5.3 系統介面詳細設計
系統介面說明應用系統軟體的各種介面。整個系統的其他介面（如系統硬體介面、通訊介面等）在相應的部分說明。
5.3.1 外部介面設計
根據系統介面劃分進行系統外部介面設計，對系統的所有外部介面（包括功能和資料介面）進行設計。
5.3.2 內部介面設計
設計系統內部各功能模組間的呼叫關係和資料介面。
5.3.3 使用者介面設計
規定人機介面的內容、介面風格、呼叫方式等，包括所謂的表單設計、報表設計和使用者需要的列印輸出等設計。此部分內容可能比較多。
此資料庫設計可單獨成冊，尤其對大型的資料庫應用系統，即有乙個單獨的《資料庫設計說明書》。
6.1設計要求
6.2 資訊模型設計
確定系統資訊的型別（實體或檢視），確定系統資訊實體的屬性、關鍵字及實體之間的聯絡，詳細描述資料庫和結構設計，資料元素及屬性定義，資料關係模式，資料約束和限制。
6.3 資料庫設計
6.3.1 設計依據
說明資料被訪問的頻度和流量，最大資料儲存量，資料增長量，儲存時間等資料庫設計依據。
6.3.2 資料庫種類及特點
說明系統內應用的資料庫種類、各自的特點、數量及如何實現互聯，資料如何傳遞。
6.3.3 資料庫邏輯結構
說明資料庫概念模式向邏輯模式轉換所採用的方**及工具，完成資料庫概念模式向邏輯模式的轉換。詳細列出所使用的資料結構中每個資料項、記錄和檔案的標識、定義、長度及它們之間的相互關係。此節內容為資料庫設計的主要部分。
6.3.4 物理結構設計
列出所使用的資料結構中每個資料項的儲存要求、訪問方法、訪問單位和訪問物理關係等。建立系統程式設計師檢視，包括：
ÿ 資料在記憶體中的安排，包括對索引區、緩衝區的設計；
ÿ 所使用的外存裝置及外存空間的組織，包括索引區、資料塊的組織與劃分；
ÿ 訪問資料的方式方法。
6.3.5 資料庫安全
說明資料的共享方式，如何保證資料的安全性及保密性。
6.3.6 資料字典
編寫詳細的資料字典。 對資料庫設計中涉及到的各種專案，如資料項、記錄、系、文捲模式、子模式等一般要建立起資料字典，以說明它們的識別符號、同義名及有關資訊。
7.3 **結構設計
確認資訊分類編碼總體方案，進行分類**結構設計。
7.4 **編制
按**結構編制資訊**
rd如何撰寫總體設計文件和詳細設計文件
rd需要撰寫的設計文件主要分為 總體設計文件 詳細設計文件，後簡稱為 總設 詳設 總設和詳設都應該包含的部分 1 需求 一般以產品的語言描述，這一塊可以拷貝產品需求文件中的story list部分 2 名詞解釋 可選 非相關領域內的同學需要看到文件需要提前了解的一些概念性質的東西 3 設計目標 又分...
軟體詳細設計模板
1 引言 1.1 編寫目的 闡明編寫詳細設計說明書的目的，指明讀者物件。1.2 專案背景 應包括專案的 和主管部門等。1.3 定義 列出本文件中所用到的專門術語的定義和縮寫詞的願意。1.4 參考資料 列出有關資料的作者 標題 編號 發表日期 出版單位或資料 專案經核准的計畫任務書 合同或上級機關的批...
軟體開發 詳細設計如何寫
police 11 59 54 到底應不應該寫詳細設計文件呢，怎麼使詳細設計文件起到他應有的作用呢 青潤 12 02 21 肯定要有詳細設計文件，只是表現形式未必是文字文字的形式。比如在全程建模的方式下，詳細設計文件就是類圖和時序圖 也就是uml模型檔案中的一部分。police 12 04 28 詳...