軟體設計書五花八門，根據不同的專案選址一種吧。呵呵！
物件導向軟體設計說明書
1概述
1.1系統簡述
對系統要完成什麼，所面向的使用者以及系統執行的環境的簡短描述，這部分主要**於需求說明書的開始部分。
1.2軟體設計目標
這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如效能、可用性等，亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文件部分，將解釋設計是怎麼來實現這些的。
1.3參考資料
1.4修訂版本記錄
列出本文件修改的歷史紀錄。必須指明修改的內容、日期以及修改人。
2術語表
3用例
此處要求系統用用例圖表述（uml），對每個用例（正常處理的情況）要有中文敘述。
4設計概述
4.1簡述
這部分要求突出整個設計所採用的方法（是物件導向設計還是結構化設計）、系統的體系結構（例如客戶/伺服器結構）以及使用到的相應技術和工具（例如omt、rose）
4.2系統結構設計
這部分要求提供高層系統結構的描述，使用方框圖來顯示主要的元件及元件間的互動。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
4.2.1頂層系統結構
4.2.2子系統1結構
4.2.3子系統2結構
4.3系統介面
各種提供給使用者的介面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對使用者介面有了敘述，此處不用再重複，可以指引讀者參考需求說明。如果系統提供了對其它系統的介面，比如說從其它軟體系統匯入/匯出資料，必須在此說明。
4.4約束和假定
描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。
另外如果本系統跟其它外部系統互動或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有互動的軟體型別（比如某某某資料庫軟體，某某某email軟體）以及這樣導致的約束（比如只允許純文字的email）。
實現的語言和平台也會對系統有約束，同樣在此予以說明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。
5物件模型
5.1系統物件模型
提供整個系統的物件模型，如果模型過大，按照可行的標準把它劃分成小塊，例如可以把客戶端和伺服器端的物件模型分開成兩個圖表述。
物件圖應該包含什麼呢？
在其中應該包含所有的系統物件。這些物件都是從理解需求後得到的。要明確哪些應該、哪些不應該被放進圖中。
所有物件之間的關聯必須被確定並且必須指明聯絡的基數（一對
一、一對多還是多對多，0..1，*，1..*）。聚合和繼承關係必須清楚地確定下來。每個圖必須附有簡單的說明。
可能經過多次反覆之後才能得到系統的正確的物件模型。
6物件描述
在這個部分敘述每個物件的細節，它的屬性、它的方法。在這之前必須從邏輯上對物件進行組織。你可能需要用結構圖把物件按子系統劃分好。
為每個物件做乙個條目。在系統物件模型中簡要的描述它的用途、約束（如只能有乙個例項），列出它的屬性和方法。如果物件是儲存在持久的資料容器中，標明它是持久物件，否則說明它是個臨時物件（transient object）。
對每個物件的每個屬性詳細說明：名字、型別，如果屬性不是很直觀或者有約束（例如，每個物件的該屬性必須有乙個唯一的值或者值域是有限正整數等）。
對每個物件的每個方法詳細說明：方法名，返回型別，返回值，引數，用途以及使用的演算法的簡要說明（如果不是特別簡單的話）。如果對變數或者返回值由什麼假定的話，pre-conditions和post-conditions必須在此說明。列出它或者被它呼叫的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
6.1子系統1中的物件
6.1.1物件：物件1
用途：約束：永續性：
6.1.1.1屬性描述：
1. 屬性：屬性1
型別：描述：
約束：2. 屬性：屬性2
6.1.1.2方法描述：
1. 方法：方法1
返回型別：
引數：返回值：
pre-condition：
post-condition：
讀取/修改的屬性：
呼叫的方法：
處理邏輯：
測試例：用什麼引數呼叫該方法，期望的輸出是什麼……
7動態模型
這部分的作用是描述系統如何響應各種事件。例如，可以建立系統的行為模型。一般使用順序圖和狀態圖。
確定不同的場景（scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
7.1場景（scenarios）
對每個場景做一則條目，包括以下內容：
場景名：給它乙個可以望文生義的名字
場景描述：簡要敘述場景是幹什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的相對時間順序。
7.1.1場景：場景1
描述：動作1動作2
7.2狀態圖
這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個物件畫乙個狀態圖，但事實上會導致太多不期望的細節資訊，只需要確定系統中一些重要的物件並為之提供狀態圖即可。
7.2.1狀態圖1：
8 非功能性需求
在這個部分，必須說明如何處理需求文件中指定的非功能性需求。盡可能客觀地評估系統應付每乙個非功能性的需求的能力程度。如果某些非功能性需求沒有完全在設計的系統中實現，請務必在此說明。另外，你也需要對系統將來的進化作乙個估計並描述本設計如何使系統能夠適應這些可預見的變化。
9輔助文件
提供能幫助理解設計的相應文件。
10詞彙索引
概要設計的作用 軟體產品設計方法
1.專案啟動會 專案啟動會的目標是明確該產品開發專案的目標。目標不是孤立存在的，目標與計畫相輔相成，目標指導計畫，計畫的有效性影響著目標的達成。2.使用者需求 軟體開始開發前需要確定代價和所獲得價值的對比，也一旦確定需要建立，就需要安排一系列的資源來支撐這個軟體的生存。這是需求的最原始描述。為什麼既...
金字塔結構與軟體產品設計
這是乙個由金字塔構成的世界 在我們的思維世界中，通常認為世界是由金字塔結構所構成的，在世界中，只存在著兩個金字塔，乙個金字塔叫做 事 另乙個金字塔叫做 物 我們將所有的一切，都歸納於事或物之中。無論是蘋果還是飛彈，無論是汽車還是房子等，我們都可以將它們歸入 金字塔物 之中，這個 金字塔物 是由原子所...
12 軟體專案的目錄設計規範
為什麼要設計好目錄結構 可讀性高 可維護性高 目錄組織方式 假設專案名為foo，比較好的最方便快捷目錄結構如下 foo bin 啟動檔案 管理指令碼 foo foo 核心 tests 測試 init py test main.py init py main.py conf 配置檔案目錄 docs a...