軟件設計文檔說明書(IEEE標準)

軟件設計文檔說明書

 

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

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章