軟體設計文件說明書

　　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 詞彙索引