1. 範圍
2. 總體要求
2.1 總體功能要求
2.2 軟件開發平臺要求
2.3 軟件項目的開發實施過程管理要求
2.3.1 軟件項目實施過程總體要求
2.3.2 軟件項目實施變更要求
2.3.3 軟件項目實施里程碑控制
3. 軟件開發
3.1 軟件的需求分析
3.1.1 需求分析
3.1.2 需求分析報告的編制者
3.1.3 需求報告評審
3.1.4 需求報告格式
3.2 軟件的概要設計
3.2.1 概要設計
3.2.2 編寫概要設計的要求
3.2.3 概要設計報告的編寫者
3.2.4 概要設計和需求分析、詳細設計之間的關係和區別
3.2.5 概要設計的評審
3.2.6 概要設計格式
3.3 軟件的詳細設計
3.3.1 詳細設計
3.3.2 特例
3.3.3 詳細設計的要求
3.3.4 數據庫設計
3.3.5 詳細設計的評審
3.3.6 詳細設計格式
3.4 軟件的編碼
3.4.1 軟件編碼
3.4.2 軟件編碼的要求
3.4.3 編碼的評審
3.4.4 編程規範及要求
3.5 軟件的測試
3.5.1 軟件測試
3.5.2 測試計劃
3.6 軟件的交付準備
3.6.1 交付清單
3.7 軟件的鑑定驗收
3.7.1 軟件的鑑定驗收
3.7.2 驗收人員
3.7.3 驗收具體內容
3.7.4 軟件驗收測試大綱
3.8 培訓
3.8.1 系統應用培訓
3.8.2 系統管理的培訓（可選）
附錄A 軟件需求分析報告文檔模板
附錄B 軟件概要設計報告文檔模板
附錄C 軟件詳細設計報告文檔模板
附錄D 軟件數據庫設計報告文檔模板
附錄E 軟件測試(驗收)大綱5
1. 範圍
本指南用於指導軟件開發者爲南京市交通局開發軟件項目的過程，通過規範軟件項目承擔單位的開發過程達到提高軟件質量，降低維護成本的目的。開發者應根據本指南進行軟件開發和編制軟件開發文檔。本指南是對軟件項目承擔單位的基本要求。在本指南的附錄A至E中提供了文檔的編寫模板供開發者參考，在進行具體軟件開發時，開發者可根據實際情況採編寫，但必須提供雙方約定的文檔，文檔中約定的內容必須描述清楚。
2. 總體要求
2.1 總體功能要求
網絡應用環境以Internet/Intranet技術爲核心。
開發者應在充分分析需求的基礎上，選擇採用B/S結構或者C/S結構。
軟件系統的數據庫應依照《南京市交通局信息化數據庫建設規範》進行設計和建設。
本指南中沒有規定開發者採用何種具體的軟件工程開發方法，開發者可根據項目具體特點、自身擅長來選擇採用面向過程的方法、面向對象的方法或面向數據的方法，但建議開發 商使用面向對象軟件工程的方法，如：採用目前被廣泛使用的RUP(Rational Unified Process)方法來進行分析、設計和開發。
2.2 軟件開發平臺要求
開發者開發的軟件必須能夠在南京市交通局規定的軟件平臺上正常運行。目前軟件平臺爲：
數據庫管理系統：
Oracle 9i以上版本
中間件(應用服務器)系統：
IBM WebSphere
OA系統：
Lotus Domino/Notes
網絡架構：
完全支持TCP/IP協議
開發工具或技術體系：
爲保證軟件的上下兼容性，開發者應選擇比較通用的開發工具的較新版本進行開發，如Microsoft Visual Studio.Net，Borland Delphi，C++ Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。
2.3 軟件項目的開發實施過程管理要求
2.3.1 軟件項目實施過程總體要求
（一）開發者提交軟件開發工作大綱，交通局組織專家組對工作大綱進行評審，並提出整改意見。
（二）通過評審後，開發者根據整改意見完善工作大綱，經過交通局認可後組織項目組進行軟件開發。軟件開發工作按照需求分析、概要設計、詳細設計、編碼、測試等幾個階段進行，在開發過程中，開發者需分階段提交相關文檔。
（三）在軟件開發工作完成後，開發者應向交通局提交完整的軟件文檔，交通局組織驗收組對軟件進行驗收審查。
2.3.2 軟件項目實施變更要求
在開發過程中，需求或設計不可避免地需要發生變更，相關變更必須經過交通局書面同 意方可進行。在需求或設計發生變更時，需要對原有文檔進行修改，並提供完整的變更記錄， 以使變更處於可控制的狀態。變更單如下表所示：
表 2-1 變更單
需求變更申請
申請變更的需求文檔
輸入名稱，版本，日期等信息
變更的內客及其理由
評估需求變更將對
項目造成的影響
申請人簽字
變更申請的審批意見
項目經理簽字
審批意見：
簽字 日期
客戶簽字
(合同項目)
審批意見：
簽字 日期
更改需求文檔
變更後的
需求文檔
輸入名稱，版本，完成日期等信息
更改人簽字
重新評審需求文檔
需求評審小組簽字
評審意見：
簽字 日期
變更結束
項目經理簽字
簽字 日期
2.3.3 軟件項目實施里程碑控制
交通局將分四個階段進行把關，召開專家審查會。
（一） 需求分析（結合原型進行審查）確認；
（二） 概要設計+數據庫設計；
（三） 預驗收（試運行後）；
（四） 正式驗收（推廣使用後）。
3. 軟件開發
合同簽訂以後，項目承擔單位即可組織項目組進行軟件開發工作。軟件開發必須嚴格按照軟件工程的要求進行。開發過程包括開發者的活動和任務。此過程由軟件需求分析、概要設計、詳細設計、編碼、測試、驗收、鑑定等活動組成。
3.1 軟件的需求分析
3.1.1 需求分析
首先，開發者和交通局應共同對交通局的應用需求作充分的調研，提交完整的需求分析 報告。在需求分析報告中必須描述的基本問題是：功能、性能、強加於實現的設計限制、屬 性、外部接口。應當避免把設計或項目需求寫入需求分析報告中。它必須說明由軟件獲得的 結果，而不是獲得這些結果的手段。
軟件需求可以用若干種方法來表達，如通過輸入、輸出說明；使用代表性的例子；用規範化的模型。開發者應儘可能地使用模型的方式，因爲這是表達複雜需求的精確和有效的方法。比如用統一建模語言（UML）來描述需求。
編寫需求分析報告的要求
a．無歧義性
對最終產品的每一個特性用某一術語描述；若某一術語在某一特殊的行文中使用時具有多種含義，那麼應對該術語的每種含義做出解釋並指出其適用場合。
b．完整性
需求分析報告應該包括全部有意義的需求，無論是關係到功能的、性能的、設計約束的、還是關係到外部接口方面的需求；對所有可能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的響應做出規定；填寫全部插圖、表、圖示標記等；定義全部術語和度量單位。
c．可驗證性
需求分析報告描述的每一個需求應是可以驗證的。可以通過一個有限處理過程來檢查軟件產品是否滿足需求。
d．一致性
在需求分析報告中的各個需求的描述不能互相矛盾。
e．可修改性
需求分析報告應具有一個有條不紊、易於使用的內容組織；沒有冗餘，即同一需求不能在需求分析報告中出現多次。
f．可追蹤性
每一個需求的源流必須清晰，在進一步產生和改變文件編制時，可以方便地引證每一個需求。
g．運行和維護階段的可使用性
需求分析報告必須滿足運行和維護階段的需要。在需求分析報告要寫明功能的來源和目的。
3.1.2 需求分析報告的編制者
需求分析報告應由交通局和開發者雙方共同完成。其中：交通局負責根據實際需要提出希望軟件實現的功能；軟件開發者根據交通局提出的性能需求，結合軟件開發編寫需求分析。
3.1.3 需求報告評審
在軟件需求分析工作完成後，軟件開發者應向交通局提交《軟件需求分析報告》。交通局組織有關人員對需求進行評審，以決定軟件需求是否完善和恰當。評審完成後，就可以進入軟件的設計階段。
3.1.4 需求報告格式
《軟件需求分析報告》需按一定的格式進行編寫，具體的《軟件需求分析報告》文檔編寫模板請見附錄A。
3.2 軟件的概要設計
3.2.1 概要設計
在交通局和開發者雙方認可的《需求分析報告》基礎上，開發者進行下——步的工作。 首先，開發者需要對軟件系統進行概要設計，即系統設計。概要設計需要對軟件系統的設計 進行考慮，包括系統的基本處理流程、系統的組織結構、模塊劃分、功能分配、接口設計、 運行設計、數據結構設計和出錯處理設計等，爲軟件的詳細設計提供基礎。
3.2.2 編寫概要設計的要求
a．一致性
概要設計的要求應該與需求分析報告所描述的需求一致。同時，概要設計的各項要求之間也應該一致。
b．合理性
概要設計所提出的設計方法和標準應該是合理的、恰當的。
c．可追蹤性
對概要設計所提出的各項要求應該可以得到它的清晰的源流，即在需求分析報告客戶有明確的需求描述。
d．可行性
根據概要設計進行詳細設計、操作和維護應該是可行的。
3.2.3 概要設計報告的編寫者
概要設計報告由開發者根據需求分析報告的要求進行編寫。
3.2.4 概要設計和需求分析、詳細設計之間的關係和區別
需求分析不涉及具體的技術實現，而概要設計注重於從宏觀上和框架上來描述採用何種技術手段、方法來實現這些需求。詳細設計相對概要設計更注重於微觀上和框架內的設計， 是編碼的依據。概要設計是指導詳細設計的依據。
3.2.5 概要設計的評審
在軟件概要設計工作完成後，軟件開發者應向交通提交《軟件系統概要設計報告》。在交通局對《概要設計報告》評審通過後，即可進入詳細設計階段。
3.2.6 概要設計格式
《軟件系統概要設計報告》需按一定的格式進行編寫，具體的《軟件系統概要設計報 告》文檔編寫模板請見附錄B。
3.3 軟件的詳細設計
3.3.1 詳細設計
在概要設計的基礎上，開發者需要進行軟件系統的詳細設計。在詳細設計中，描述實 現具體模塊所涉及到的主要算法、數據結構、類的層次結構及調用關係，需要說明軟件系統各個層次中的每一個程序(每個模塊或子程序)的設計考慮，以便進行編碼和測試。應當保證 軟件的需求完全分配給整個軟件。詳細設計應當足夠詳細，能夠根據詳細設計報告進行編碼。
3.3.2 特例
如果軟件系統比較簡單，層次較少，可以不必進行專門的詳細設計，而和概要設計結合起來。
3.3.3 詳細設計的要求
a．一致性
詳細設計的要求應該與需求分析報告所描述的需求、與概要設計一致。同時，詳細設計的各項要求之間也應該是一致的。
b．合理性
詳細設計所提出的設計方法和標準應該是合理的、恰當的。
c．可追蹤性
對詳細設計所提出的各項要求應該可以得到它的清晰的源流，即可在需求分析報告、概要設計報告中有明確的需求描述。
d．可行性
根據詳細設計進行編碼、測試、操作和維護應該是可行的。
3.3.4 數據庫設計
如果軟件產品需要使用到數據庫，軟件的詳細設計應包括對數據庫的設計。數據庫設計應在軟件的需求分析、概要設計完成之後、詳細設計的其它工作之前進行。在進行數據庫設計時，應當按照交通局制定的《南京市交通局信息化數據庫建設規範》要求進行。
3.3.5 詳細設計的評審
在軟件詳細設計完成後，軟件開發者應向交通局提交《軟件系統數據庫設計報告》和《軟件系統詳細設計報告》。在交通局對《軟件系統數據庫設計報告》、《軟件系統詳細設計報告》評審通過後，即可進入軟件編碼階段。
3.3.6 詳細設計格式
《軟件系統詳細設計報告》、《軟件系統數據庫設計報告》需按一定的格式進行編寫， 具體的《軟件系統詳細設計報告》文檔編寫模板和《軟件系統數據庫設計報告》文檔編寫模 板請見附錄C、附錄D。
3.4 軟件的編碼
3.4.1 軟件編碼
在軟件編碼階段，開發者根據《軟件系統詳細設計報告》中對數據結構、算法分析和模塊實現等方面的設計要求，開始具體的編寫程序工作，分別實現各模塊的功能，從而實現對目標系統的功能、性能、接口、界面等方面的要求。
3.4.2 軟件編碼的要求
a．模塊化編碼
b．代碼可讀性
c．可維護性
d．模塊接口標準化
e．界面風格統一
e．註釋的應用
3.4.3 編碼的評審
爲了儘早發現軟件中的障礙，提高軟件產品的質量，開發者在編碼的過程中應該強調代碼評審工作。將代碼評審報告作爲文檔的一部分，提交給交通局。
3.4.4 編程規範及要求
爲了提高編程實現的質量，軟件的程序設計必須遵照國家頒佈的相關編程規範。
主要內容包括：規範化的程序內部文檔、數據結構的詳細說明、清晰的語句結構、編碼規範。編碼規範的內容包括命名規範、界面規範、提示及幫助信息規範、熱鍵定義等。
其中數據庫部分應遵守《南京市交通局信息化數據庫建設規範》的要求。
在軟件編碼的同時應進行單元測試。
3.5 軟件的測試
3.5.1 軟件測試
爲了儘早發現軟件產品中的錯誤，從而達到提高軟件質量、降低軟件維護的費用，開發者應在編碼過程中對各個模塊的程序代碼進行單元測試，系統集成時進行集成測試，系統集成完成後對整個軟件進行系統測試。單元測試是在軟件開發過程中針對程序模塊進行正確性檢驗。集成測試是在單元測試的基礎上，將所有模塊按照設計要求組裝成系統或子系統，對模塊組裝過程和模塊接口進行正確性檢驗。軟件系統測試不僅是檢測軟件的整體行爲表 現，從另一個側面看，也是對軟件開發設計的再確認。進行軟件系統測試工作時。測試主要包括界面測試、可用性測試、功能測試、穩定性(強度)測試、性能測試、強壯性(恢復)測試、邏輯性測試、破壞性測試、安全性測試等。
開發者針對單元測試，集成測試，系統測試分別制定《測試計劃》。集成測試需要根據需求分析報告和概要設計製作測試用例，並須經過評審。軟件測試按照《測試計劃》、《需求分析報告》的要求進行，最後形成《軟件測試報告》。
3.5.2 測試計劃
在軟件編碼開始之前，開發者應向交通局提交《測試計劃》，在軟件交付時，開發者應向交通局提交《軟件測試報告》，以確保開發者的軟件得到了充分的測試。開發的軟件必須經過充分的測試證明其符合設計要求、運行穩定、安全可用方可交付交通局。
3.6 軟件的交付準備
3.6.1 交付清單
在軟件測試證明軟件達到要求後，軟件開發者應向交通局提交開發的目標安裝程序、數據庫的數據字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等雙方合同約定的產物。
《用戶安裝手冊》應詳細介紹安裝軟件對運行環境的要求、安裝軟件的定義和內容、在客戶端、服務器端及中間件的具體安裝步驟、安裝後的系統配置。
《用戶使用指南》應包括軟件各項功能的使用流程、操作步驟、相應業務介紹、特殊提示和注意事項等方面的內容，在需要時還應舉例說明。
3.7 軟件的鑑定驗收
3.7.1 軟件的鑑定驗收
在軟件開發完成後，爲了確保軟件是按照需求分析的要求進行開發的，保證軟件產品的質量，需要對軟件產品進行鑑定驗收。在開發者如期交付軟件後，由交通局負責確定具體的鑑定驗收日期。
3.7.2 驗收人員
由交通局聘請具有一定的分析、設計、編程和軟件測試經驗的驗收組長和其他專業人員組成。驗收組設組長一名(可設有副組長)，負責整個驗收的計劃、組織工作。
3.7.3 驗收具體內容
驗收內容應該包括：合法性檢查、文檔檢查、軟件一致性檢查、軟件系統測試與測試結果評審等幾項工作。
合法性檢查檢查軟件開發工具是否合法、使用的函數庫、控件、組件是否有合法的發佈許可。
文檔檢查檢查開發者提交的文檔必須齊全，質量是否過關。需要開發者提供的文檔包括：
項目實施計劃；
詳細技術方案；
軟件需求規格說明書(STP)(含數據字典)；
概要設計說明書(PDD)；
詳細設計說明書(DDD)(含數據庫設計說明書)；
軟件測試計劃(STP)(含測試用例)；
軟件測試報告(STR)；
用戶手冊(SUM)(含操作、使用、維護、應急處理手冊)；
源程序(SCL)(不可修改的電子文檔)；
項目實施計劃(PIP)；
項目開發總結(PDS)；
軟件質量保證計劃(SQAP)；
此外，驗收組可以根據需要對其它文檔(如軟件配置計劃、項目進展報表、階段評審報 表等)進行檢查。
文檔的質量根據完備性、正確性、簡明性、可追蹤性、自說明性、規範件等方面進行蹤合評定。
驗收需要對軟件代碼進行檢查，以確保其符合規範，並檢查其一致性。
3.7.4 軟件驗收測試大綱
在軟件進行鑑定驗收前，開發者需按照一定的格式編寫《軟件驗收測試大綱》，具體的格式請見附錄E。
3.8 培訓
3.8.1 系統應用培訓
主要培訓內容包括：系統操作使用、業務管理流程。
培訓對象：應用操作人員。
3.8.2 系統管理的培訓（可選）
主要培訓內容包括：系統安裝、調試、維護；系統管理。
培訓對象：系統管理人員。
開發者應詳細列出培訓計劃，包括培訓內容、教材、時間和人員等。
附錄A 軟件需求分析報告文檔模板
1. 引言
1.1 編寫目的
1.2 項目風險
1.3 文檔約定
1.4 預期讀者和閱讀建議
1.5 產品範圍
1.6 參考文獻
2. 綜合描述
2.1 產品的狀況
2.2 產品的功能
2.3 用戶類和特性
2.4 運行環境
2.5 設計和實現上的限制
2.6 假設和約束(依賴)
3. 外部接口需求
3.1 用戶界面
3.2 硬件接口
3.3 軟件接口
3.4 通訊接口
4. 系統功能需求
4.1 說明和優先級
4.2 激勵／響應序列
4.3 輸入／輸出數據
5. 其它非功能需求
5.1 性能需求
5.2 安全措施需求
5.3 安全性需求
5.4 軟件質量屬性
5.5 業務規則
5.6 用戶文檔
6. 詞彙表
7. 數據定義
8. 分析模型
9. 待定問題列表
1. 引言
引言是對這份軟件產品需求分析報告的概覽，是爲了幫助閱讀者瞭解這份文檔是如何編寫的，並且應該如何閱讀、理解和解釋這份文檔。
1.1 編寫目的
說明這份軟件產品需求分析報告是爲哪個軟件產品編寫的，開發這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件產品需求分析報告詳盡說明了該軟件產品的需求規格，包括修正和(或)發行版本號，從而對該軟件產品進行準確的定義。
如果這份軟件產品需求分析報告只與整個系統的某一部分有關係，那麼只定義軟件產品需求分析報告中說明的那個部分或子系統。
1.2 項目風險
具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：
● 任務提出者；
● 軟件開發者；
● 產品使用者。
1.3 文檔約定
描述編寫文檔時所採用的標準(如果有標準的話)，或者各種排版約定。排版約定應該包括：
● 正文風格；
● 提示方式；
● 重要符號；
也應該說明高層次需求是否可以被其所有細化的需求所繼承，或者每個需求陳述是否都有其自己的優先級。
1.4 預期讀者和閱讀建議
列舉本軟件產品需求分析報告所針對的各種不同的預期讀者，例如，可能包括：
● 用戶；
● 開發人員；
● 項目經理；
● 營銷人員；
● 測試人員；
● 文檔編寫入員。
並且描述了文檔中，其餘部分的內容及其組織結構，並且針對每一類讀者提出最適合的文檔閱讀建議。
1.5 產品範圍
說明該軟件產品及其開發目的的簡短描述，包括利益和目標。把軟件產品開發與企業目標，或者業務策略相聯繫。
描述產品範圍時需注意，可以參考項目視圖和範圍文檔，但是不能將其內容複製到這裏。
1.6 參考文獻
列舉編寫軟件產品需求分析報告時所用到的參考文獻及資料，可能包括：
● 本項目的合同書；
● 上級機關有關本項目的批文；
● 本項目已經批准的計劃任務書；
● 用戶界面風格指導；
● 開發本項目時所要用到的標淮；
● 系統規格需求說明；
● 使用實例文檔；
● 屬於本項目的其它己發表文件；
● 本軟件產品需求分析報告中所引用的文件、資料；
● 相關軟件產品需求分析報告；
爲了方便讀者查閱，所有參考資料應該按一定順序排列。如果可能，每份資料都應該給出：
● 標題名稱；
● 作者或者合同簽約者；
● 文件編號或者版本號；
● 發表日期或者簽約日期；
● 出版單位或者資料來源。
2. 綜合描述
這一部分概述了正在定義的軟件產品的作用範圍以及該軟件產品所運行的環境、使用該軟件產品的用戶、對該軟件產品己知的限制、有關該軟件產品的假設和依賴。
2.1 產品的狀況
描述了在軟件產品需求分析報告中所定義的軟件產品的背景和起源。說明了該軟件產品是否屬於下列情況：
● 是否是產品系列中的下一成員；
● 是否是成熟產品所改進的下一代產品；
● 是否是現有應用軟件的替代品(升級產品)；
● 是否是一個新型的、自主型的產品。
如果該軟件產品需求分析報告定義的軟件系統是：
● 大系統的一個組成部分；
● 與其它系統和其它機構之間存在基本的相互關係。
那麼必須說明軟件產品需求分析報告定義的這部分軟件是怎樣與整個大系統相關聯的，或者（同時）說明相互關係的存在形式，並且要定義出兩者之間的全部接口。
2.2 產品的功能
因爲將在需求分析報告的第4部分中詳細描述軟件產品的功能，所以在此只需要概略地總結。僅從業務層面陳述本軟件產品所應具有的主要功能，在描述功能時應該針對每一項需求準確地描述其各項規格說明。如果存在引起誤解的可能，在陳述本軟件產品主要功能的作用領域時，也需要對應陳述本軟件產品的非作用領域，以利讀者理解本軟件產品。
爲了很好地組織產品功能，使每個讀者都容易理解，可以採用列表的方法給出。也可以採用圖形方式，將主要的需求分組以及它們之間的聯繫使用數據流程圖的頂層圖或類圖進行表示，這種表示方法是很有用的。
參考用戶當前管理組織構架，瞭解各個機構的主要職能，將有助於陳述軟件產品的主要功能。
2.3 用戶類和特性
確定有可能使用該軟件產品的不同用戶類，並且描述它們相關的特徵。往往有一些軟件需求，只與特定的用戶類有關。描述時，應該將該軟件產品的重要用戶類與非重要用戶類區分開。
用戶不一定是軟件產品的直接使用者，通過報表、應用程序接口、系統硬件接口得到軟件產品的數據和服務的人、或者機構也有他們的需求。所以，應該將這些外部需求視爲通過報表、應用程序接口、系統硬件接口附加給軟件產品的附加用戶類。
2.4 運行環境
描述了本軟件的運行環境，一般包括：
● 硬件平臺；
● 操作系統和版本；
● 支撐環境(例如：數據庫等)和版本；
● 其它與該軟件有關的軟件組件；
● 與該軟件共存的應用程序。
2.5 設計和實現上的限制
確定影響開發人員自由選擇的問題，並且說明這些問題爲什麼成爲一種限制。可能的限制包括下列內容：
● 必須使用的特定技術、工具、編程語言和數據庫；
● 避免使用的特定技術、工具、編程語言和數據庫；
● 要求遵循的開發規範和標準
例如，如果由客戶的公司或者第三方公司負責軟件維護，就必須定義轉包者所使用的設計符號表示和編碼標準；
● 企業策略的限制；
● 政府法規的限制；
● 工業標準的限制；
● 硬件的限制
例如，定時需求或存儲器限制；
● 數據轉換格式標淮的限制。
2.6 假設和約束(依賴)
列舉出對軟件產品需求分析報告中，影響需求陳述的假設因素(與己知因素相對立)。如果這些假設因素不正確、不一致或者被修改，就會使軟件產品開發項目受到影響。這些假設的因素可能包括：
● 計劃使用的商業組件，或者其它軟件中的某個部件；
● 假定產品中某個用戶界面將符合一個特殊的設計約定；
● 有關本軟件用戶的若干假定(例如：假定用戶會熟練使用SQL語言。)；
● 有關本軟件開發工作的若干假定(例如：用戶承諾的優惠、方便、上級部門給予的特殊政策和支持等。)；
● 有關本軟件運行環境的一些問題；
此外，確定本軟件開發項目對外部約束因素所存在的依賴。有關的約束可能包括：
● 工期約束；
● 經費約束；
● 人員約束；
● 設備約束；
● 地理位置約束；
● 其它有關項目約束；
3. 外部接口需求
通過本節描述可以確定，保證軟件產品能和外部組件正確連接的需求。關聯圖僅能表示高層抽象的外部接口，必須對接口數據和外部組件進行詳細描述，並且寫入數據定義中。如果產品的不同部分有不同的外部接口，那麼應該把這些外部接口的全部詳細需求併入到這一部分實例中。
注意：必須將附加用戶類的特徵與外部接口需求加以區分，附加用戶類的特徵描述的是通過接口取得軟件產品的數據和服務的人的需求；而外部接口需求描述的是接口本身的需求。
3.1 用戶界面
陳述需要使用在用戶界面上的軟件組件，描述每一個用戶界面的邏輯特徵。必須注意，這裏需要描述的是用戶界面的邏輯特徵，而不是用戶界面。以下是可能包括的一些特徵：
● 將要採用的圖形用戶界面(GUl)標準或者產品系列的風格；
● 有關屏幕布局或者解決方案的限制；
● 將要使用在每一個屏幕(圖形用戶界面)上的軟件組件，可能包括：
n 選單；
n 標準按鈕；
n 導航鏈接；
n 各種功能組件；
n 消息欄；
● 快捷鍵；
● 各種顯示格式的規定，可能包括：
n 不同情況下文字的對齊方式；
n 不同情況下數字的表現格式與對齊方式
n 日期的表現方法與格式；
n 計時方法與時間格式；
n 等等。
● 錯誤信息顯示標準；
對於用戶界面的細節，例如：一個特定對話框的佈局，應該寫入具體的用戶界面設計說明中，而不能寫入軟件需求規格說明中。
如果採用現成的、合適的用戶界面設計規範(標準)，或者另文描述，可以在這裏直接說明，並且將其加入參考文獻。
3.2 硬件接口
描述待開發的軟件產品與系統硬件接口的特徵，若有多個硬件接口，則必須全都描述。接口特徵的描述內容可能包括：
● 支持的硬件類型；
● 軟、硬件之間交流的數據；
● 控制信息的性質；
● 使用的通訊協議；
3.3 軟件接口
描述該軟件產品與其它外部組件的連接，這些外部組件必須明確它們的名稱和版本號以資識別，可能的外部組件包括：
● 操作系統；
● 數據庫；
● 工具；
● 函數庫；
● 集成的商業組件
說明：這裏所說的“集成的商業組件”，是指與系統集成的商業組件，而不是與軟件產品集成的商業組件。例如：中間件、消息服務，等等。
描述並且明確軟件產品與軟件組件之間交換數據或者消息的目的。描述所需要的服務，以及與內部組件通訊的性質。確定軟件產品將與組件之間共享的數據。如果必須使用一種特殊的方法來實現數據共享機制，例如：在多用戶系統中的一個全局數據區，那麼就必須把它定義爲一種實現上的限制。
3.4 通訊接口
描述與軟件產品所使用的通訊功能相關的需求，包括：
● 電子郵件；
● WEB瀏覽器；
● 網絡通訊標準或者協議；
● 數據交互用電子表格；
必須定義相關的：
● 消息格式；
● 通訊安全或加密問題；
● 數據傳輸速率；
● 同步和異步通訊機制；
4. 系統功能需求
需要進行詳細的需求記錄，詳細列出與該系統功能相關的詳細功能需求，並且，唯一地標識每一項需求。這是必須提交給用戶的軟件功能，使得用戶可以使用所提供的功能執行服務或者使用所指定的使用實例執行任務。描述軟件產品如何響應己知的出錯條件、非法輸入、非法動作。
如果每一項功能需求都能用一項，也只需要用一項測試用例就能進行驗證，那麼就可以認爲功能需求已經適當地進行描述了。如果某項功能需求找不到合適的測試用例，或者必須使用多項測試用例才能驗證，那麼該項功能需求的描述必然存在某些問題。
功能需求是根據系統功能，即軟件產品所提供的主要服務來組織的。可以通過使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內容，也可以便用這些元素的組合。總而言之，必須選擇一種是讀者容易理解預期產品的組織方案。
用簡短的語句說明功能的名稱，例如：“4.1系統參數管理”。按照服務組織的順序，逐條闡述系統功能。無論說明的是何種功能，都應該針對該系統功能重複敘述4.1~ 4.3這三個部分。
可以通過各種方式來組織這一部分內容，例如採用：使用實例、運行模式、用戶類、對象類、功能等級等，也可以採用它們的組合。其最終目的是，讓讀者容易理解即將開發的軟件產品。一般來說，每個使用實例都對應一個系統功能，因而按照使用實例來組織內容比較容易讓用戶理解。
對應一些被共享的獨立使用實例，可以定義一些公用系統功能。
必須特別注意的是，在2.2節“產品的功能”中描述的全部需求，以及它們的規格說明；必須在某個系統功能描述中有所反映，而且不應重複。
4.1 說明和優先級
對該系統功能進行簡短的說明，並且指出該系統功能的優先級是：高、中、還是低。需要的話，還可以包括對特定優先級部分的評價，例如：利益、損失、費用和風險，其相對優先等級可以從1(低)到9(高)。
4.2 激勵／響應序列
列出輸入激勵(用戶動作、來自外部設備的信號或者其它觸發)並且定義針對這——功能行爲的系統響應序列，這些序列將與使用實例中相關的對話元素相對應。
描述激勵／響應序列時，不僅需要描述基本過程，而且應該描述可選(擴充)過程，包括例外(引起任務不能順序完成的情況稱爲例外)。疏忽了可選過程，有可能影響軟件產品的功能；如果遺漏例外過程，則有可能會引發系統崩潰。
如果採用流程圖來描述激勵／響應序列，比較容易讓用戶理解。
4.3 輸入／輸出數據
列出輸入數據(用戶輸入、來自外部接口的輸入或者其它輸入)並且定義針對這些輸入數據的處理(計算)方法，以及相應地輸出數據，描述對應區別：輸入數據和輸出數據。
當有大量數據需要描述時，也可以分類描述數據，並且註明各項數據的輸入、輸出屬性。
對於每一項數據，均需要描述：
● 數據名稱；
● 實際含義；
● 數據類型；
● 數據格式；
● 數據約束；
對於複雜的處理方法，僅僅給出算法原理是不夠的，必須描述詳細的計算過程，並且列出每一步具體使用的實際算式；如果計算過程中涉及查表、判斷、迭代等處理方法，應該給出處理依據和相關數據。如果計算方法很簡單，也可以將其從略，不加描述。
5. 其它非功能需求
在這裏列舉出所有非功能需求，主要包括可靠性、安全性、可維護性、可擴展性、可測試性等。
5.1 性能需求
闡述不同應用領域對軟件產品性能的需求，並且說明提出需求的原理或者依據，以幫助開發人員做出合理的設計選擇。儘可能詳細地描述性能需求，如果需要，可以針對每個功能需求或者特徵分別陳述其性能需求。在這裏確定：
● 相互合作的用戶數量；
● 系統支持的併發操作數量；
● 響應時間；
● 與實時系統的時間關係：
● 容量需求
n 存儲器；
n 磁盤空間；
n 數據庫中表的最大行數。
5.2 安全措施需求
詳盡陳述與軟件產品使用過程中可能發生的損失、破壞、危害相關的需求。定義必須採取的安全保護或動作，以及必須預防的潛在危險動作。明確軟件產品必須遵從的安全標準、策略、或規則。
5.3 安全性需求
詳盡陳述與系統安全性、完整性問題相關的需求，或者與個人隱私問題相關的需求。這些問題將會影響到軟件產品的使用，和軟件產品所創建或者使用的數據的保護。定義用戶身份認證，或備授權需求。明確軟件產品必須滿足的安全性或者保密性策略。也可以通過稱爲完整性的質量屬性來闡述這些需求。一個典型的軟件系統安全需求範例如下：“每個用戶在第一次登錄後，必須更改他的系統預置登錄密碼，系統預置的登錄密碼不能重用。”
5.4 軟件質量屬性
詳盡陳述對客戶和開發人員至關重要的在軟件產品其它方面表現出來的質量功能。這些功能必須是確定的、定量的、在需要時是可以驗證的。至少也應該指明不同屬性的相對側重點，例如：易用性優於易學性，或者可移植性優於有效性。
5.5 業務規則
列舉出有關軟件產品的所有操作規則，例如：那些人在特定環境下可以進行何種操作。這些本身不是功能需求，但是他們可以暗示某些功能需求執行這些規則。一個業務規則的範例如下：“進行達到或者超過10，000，00元人民幣的儲蓄業務時，必須通過附加的管理員認證。”
列舉業務規則時，可以根據規則的數量，選取合適的編目方式。
5.6 用戶文檔
列舉出將與軟件產品一同交付的用戶文檔，並且明確所有己知用戶文檔的交付格式或標準，例如：
● 安裝指南
紙質文檔，16開本；
● 用戶手冊
紙質文檔，16開本；
● 在線幫助
● 電子文檔，與軟件產品一同分發、配置；
● 使用教程電子文檔，與軟件產品一同分發、配置。
6. 詞彙表
列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的外文原詞)。爲了便於非軟件專業或者非計算機專業人士閱讀軟件產品需求分析報告，要求使用非軟件專業或者非計算機專業的術語描述軟件需求。所以這裏所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術語。但是，對於無法迴避的軟件專業或者計算機專業術語，也應該列入詞彙表並且加以準確定義。
7. 數據定義
數據定義是一個定義了應用程序中使用的所有數據元素和結構的共享文檔，其中對每個數據元素和結構都準確描述：含義、類型、數據大小、格式、計量單位、精度以及取值範圍。數據定義的維護獨立於軟件需求規格說明，並且在軟件產品開發和維護的任何階段，均向風險承擔者開放。
如果爲軟件開發項目創建一個獨立的數據定義，而不是爲每一項特性描述有關的數據項，有利於避免冗餘和不一致性。但是卻不利於多人協同編寫需求分析報告，容易遺漏數據，也不方便閱讀。因此還是建議爲每個特性描述有關的數據項，彙總數據項創建數據定義，再根據數據定義複覈全部數據，使得它們的名稱和含義完全一致。必須注意的是，爲了避免二義性，在彙總數據項時應該根據數據項所代表的實際意義彙總，而不是根據數據項的名稱彙總。
在數據定義中，每個數據項除了有一箇中文名稱外，還應該爲它取一個簡短的英文名稱，該英文名稱應該符合命名規範，因爲在軟件開發時將沿用該英文名稱。可以使用等號表示數據項，名稱寫在左邊，定義寫在右邊。常見數據項的描述方式如下：
● 原數據元素
一個原數據元素是不可分解的，可以將一個數量值賦給它。定義原數據元素必須確定其
含義、類型、數據大小、格式、計量單位、精度以及取值範圍。採用以星號爲界的一行
註釋文本，描述原數據元素的定義。
● 選擇項
選擇項是一種只可以取有限離散值的特殊原數據元素，描述時一一枚舉這些值，並用方
括號括起來寫在原數據元素的定義前。在兩項離散值之間，使用管道符分隔。
● 組合項
組合項是一個數據結構或者記錄，其中包含了多個數據項。這些數據項可以是原數據元
素，也可以是組合數據項，各數據項之間用加號連接。其中每個數據項都必須是數據定
義中定義過的，結構中也可以包括其它結構，但是絕對不允許遞歸。如果數據結構中有
可選項，使用圓括號把該項括起來。
● 重複項
重複項是組合項的一種特例，其中有一項將有多個實例出現在數據結構中，使用花括號
把該項括起來。如果知道該項可能允許的範圍，就按“最小值：最大值”的形式寫在花
括號前。
8. 分析模型
這是一個可選部分，包括或涉及到相關的分析模型，例如：
● 數據流程圖；
● 類圖；
● 狀態轉換圖；
● 實體-關係圖。
9. 待定問題列表
編輯一張在軟件產品需求分析報告中待確定問題時的列表，把每一個表項都編上號，以便跟蹤調查。
附錄B 軟件概要設計報告文檔模板
1. 引言
1.1 編寫目的
1.2 項目風險
1.3 預期讀者和閱讀建議
1.4 參考資料
2. 設計概述
2.1 限制和約束
2.2 設計原則和設計要求
3. 系統邏輯設計
3.1 系統組織設計
3.2 系統結構設計
3.2.1 系統特性表
3.2.2 系統特性結構圖
3.3 系統接口設計
3.3.1 系統接口表
3.3.2 系統接口傳輸協議說明
3.4 系統完整性設計
4. 系統出錯處理設計
4.1 系統出錯處理表
4.2 維護處理過程表
5. 技術設計
5.1 系統開發技術說明表
5.2 開發技術應用說明
6. 數據庫設計
7. 詞彙表
8. 進度計劃
1. 引言
引言是對這份軟件系統概要設計報告的概覽，是爲了幫助閱讀者瞭解這份文檔是如何編寫的，並且應該如何閱讀、理解和解釋這份文檔。
1.1 編寫目的
說明這份軟件系統概要設計報告是基於哪份軟件產品需求規格說明書編寫的，開發這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件系統概要設計報告詳盡說明了該軟件產品的軟件結構，包括數據庫結構和出錯處理，從而對該軟件產品的結構的描述。
如果這份軟件系統概要設計報告只與整個系統的某一部分有關係，那麼只定義軟件系統概要設計報告中說明的那個部分或子系統。
1.2 項目風險
具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：
● 任務提出者；
● 軟件開發者；
● 產品使用者。
1.3 預期讀者和閱讀建議
列舉本軟件系統概要設計報告所針對的各種不同的預期讀者，例如，可能的讀者包括：
● 用戶；
● 開發人員；
● 項目經理；
● 營銷人員；
● 測試人員；
● 文檔編寫人員；
● 等等。
描述文檔中，其餘部分的內容及其組織結構，並且針對每一類讀者提出最適合的文檔閱讀建議。
1.4 參考資料
列舉編寫軟件產品概要設計報告時所用到的參考文獻及資料，可能包括：
● 本項目的合同書；
● 上級機關有關本項目的批文；
● 本項目已經批准的計劃任務書；
● 用戶界面風格指導；
● 開發本項目時所要用到的標準；
● 系統規格需求說明；
● 使用實例文檔；
● 屬於本項目的其它已發表文件；
● 本軟件系統概要設計報告中所引用的文件、資料：
● 相關軟件系統概要設計報告：
● 等等。
爲了方便讀者查閱，所有參考資料應該按一定順排列。如果可能，每份資料都應該給出：
● 標題名稱；
● 作者或者合同簽約者；
● 文件編號或者版本號；
● 發表日期或者簽約日期；
● 出版單位或者資料來源。
2. 設計概述
本節描述現有開發條件和需要實現的目標，說明進行概要設計時應該遵循的設計原則和必須採用的設計方法。
2.1 限制和約束
簡要描述起到限制和約束作用的各種可能存在的條件，例如：
● 技術條件；
● 資金狀況；
● 開發環境(包括：工具和平臺)；
● 時間限制；
● 等等。
並且說明在上述條件下，應該實現的系統目標，
2.2 設計原則和設計要求
描述對本軟件系統進行概要設計的原則，通常可以考慮以下幾方面的內容：
● 命名規則；
● 模塊獨立性原則：
● 邊界設計原則；
● 數據庫設計規則；
● 必須的安全措施；
● 安全性和保密原則；
● 系統靈活性要求；
● 系統易操作性要求；
● 系統可維護性要求；
● 等等。
3. 系統邏輯設計
本節內容主要根據軟件產品需求規格說明書和軟件產品數據字典建立系統的邏輯模型。此種模型暫時與系統的物理因素(例如：計算機、數據庫管理系統)無關。它是系統需求與物理實現的中間結構，它的主要結果是建立：系統結構圖、系統界面結構圖、系統出錯處理、以及系統開發技術說明。
說明：如果進行系統設計時尚未編寫軟件數據字典：應首先參照附錄B說明，編寫軟件數據字典。在完成軟件數據字典後，再進行系統設計。
3.1 系統組織設計
系統組織設計通過系統組織表描述本系統由哪些子系統(模塊)組成，這些子系統與業務職能之間的關係，以及各個子系統的安裝地點。系統組織表的格式如下：
子系統編號
英文名稱
中文名稱
業務職能
安裝地點
備註
其中：
● 子系統編號
給出本系統中指定子系統的順序編號。如果本系統末劃分爲多個子系統，僅由一
個運行模塊組成；則本項內容仍需要描述，但是本表內容只有一行。
說明：在一個系統中有可能安裝若干個相同的子系統，在這種情況下，應該視爲
一個子系統，並且對多個安裝地點分別進行描述。如果相同的子系統通過系統設
置，實現的業務職能具有明顯差異時，應該採用多行進行分別描述，並且在備註
中說明其差異所在。
● 子系統英文名稱
給出本子系統的英文名稱，該名稱是在應用軟件中實際使用的可執行文件名稱，
必須能夠說明該子系統的特點。
若本系統中只有一個子系統，則本項內容仍需要描述，但是本表內容只有一行。
● 子系統中文名稱
給出本子系統的中文名稱，該名稱必須能夠說明該子系統的特點。
若本系統中只有一個子系統，則本項內容仍需要描述，但是本表內容只有一行。
● 業務職能
描述該子系統完成的核心業務。
● 安裝地點
描述該子系統實際安裝的部門、或者某個具體地點。
● 備註
針對該子系統，需要說明的其它有關問題。
3.2 系統結構設計
本節將對系統特性作較爲詳細的描述，並給出系統特性結構圖。
3.2.1 系統特性表
系統特性是系統中完成某項具體操作的基本單元，它由入口參數，出口參數以及處理過程三部分組成。
系統特性可以具有操作界面，也可以沒有操作界面；可以被其它操作界面、或者系統特性調用，也可以調用其它操作界面、非操作界面、或者系統特性；但是不允許遞歸調用(調用自己)，包括間接遞歸調用。
當系統由多個子系統(模塊)組成時，每個子系統分別使用一張系統特性表進行描述。系統特性表的格式如下：
子系統編號：
子系統英文名稱：
子系統中文名稱：
特性編號
系統特徵
英文名稱
系統特徵
中文名稱
操作功能
調用對象
被調用
對象
備註
說明：
其中
● 子系統編號
含義同上。
● 子系統英文名稱
含義同上。
● 子系統中文名稱
含義同上。
● 特性編號
整個系統所有特性的統一編號。
● 系統特性英文名稱
系統特性的英文正式名稱，將來用於軟件開發中，必須符合命名規範。
● 系統特性中文名稱
系統特性的中文正式名稱，來源於需求規格說明書中，系統特性一節中的有關描
述。
● 操作功能
是指該特性實際完成的操作說明。
● 調用對象
是指調用該系統特性的系統對象，這裏的系統對象可以是系統特性、也可以是操作界面。
● 被調用對象
是指被該系統特性調用的系統對象，這裏的系統對象可以是系統特性、也可以是操作界面。
說明：某些較低層的系統特性，可能不存在被調用對象。
● 備註
描述與該系統特性有關的其它注意事項。
● 說明
描述與該系統特性表有關的其它注意事項。
3.2.2 系統特性結構圖
系統特性結構圖給出系統特性在邏輯層面上相互之間的關係，其主要依據來源於需求規格說明書中，系統特性一節中的有關描述。
如果系統劃分爲多個子系統，應分別給出系統與子系統、以及各個子系統與系統特性的結構圖。
繪製系統與子系統結構圖時，一般不需要描繪出系統特性，如果確有必要，儘可能只畫出第一層系統特性。繪製子系統與系統特性結構圖時，通常也不需要描繪出第二層系統特性，如果確有必要可以畫出，但是儘可能不要畫出第三層系統特性。
3.3 系統接口設計
系統接口是一種非可視的系統界面，在多數情況下，它對用戶是透明的。
本節將對系統接口作較爲詳細的描述，並給出接口說明清單。
3.3.1 系統接口表
接口作爲系統的一種輸入／輸出形式，分爲網絡接口、數據庫接口、RS-232串行通訊接口、IEEE—485串行總線接口、並行I/O接口等等多種類型。
對於一些爲可視界面服務的接口，例如：打印機接口、顯示器接口等，因爲這類接口對應用軟件是透明的，所以不在本節描述範圍內。
當系統由多個子系統(模塊)組成時，每個子系統分別使用一張系統接口表進行描述。系統接口表的格式如下：
子系統編號
子系統英文名稱
子系統中文名稱
接口
編號
接口
名稱
接口
類型
接口
性質
接口
速率
接口
協議
備註
說明：
其中：
● 子系統編號
含義同上。
● 子系統英文名稱
含義同上。
● 子系統中文名稱
含義同上。
● 接口編號
整個系統所有接口的統一編號。
● 接口名稱
系統接口的正式名稱，必須符合通常習慣。
● 接口類型
指出該接口所傳輸的數據在該模塊中起到的作用。
● 接口性質
指出該接口在通訊中起到的作用，這裏的作用可以是：
n 輸入；
n 輸出；
n 雙向。
● 接口速率
指出該接口的傳輸速率。如果該接口依賴於其它通訊方式，那麼傳輸速率將不高於它所依賴的其它通訊方式的速率。
● 接口協議
給出該接口實際使用的通訊協議。
● 相關對象
給出直接使用本接口的系統對象，這裏的系統對象，可以是操作界面，也可以是系統特性。
● 備註
描述與該系統接口有關的其它注意事項。
● 說明
描述與該系統接口表有關的其它注意事項。
3.3.2 系統接口傳輸協議說明
逐項詳細描述系統接口表中所列出各個系統接口使用的傳輸協議，以及其它相關內容，例如：驅動程序、動態連接庫、等等。
3.4 系統完整性設計
描述系統對象(數據元、數據類)，所受到的邏輯約束關係。
當系統由多個子系統(模塊)組成時，每個子系統應分別使用一張系統完整性約束表進行描述。系統完整性約束表的格式如下：
子系統編號
子系統英文名稱
子系統中文名稱
約束編號
完整性名稱
相對對象名
約束表達式
備註
說明：
其中：
● 子系統編號
含義同上。
● 子系統英文名稱
含義同上。
● 子系統中文名稱
含義同上。
● 約束編號
整個系統所有約束的統一編號。
● 完整性名稱
系統完整性約束的正式名稱，必須符合通常習慣。
● 相對對象名
完整性約束中的相關對象(數據元和數據類)。
● 約束表達式
用一階邏輯表達式表達的約束方程式。
● 備註
描述與該系統完整性約束有關的其它注意事項。
● 說明
描述與該系統完整性約束表有關的其它注意事項。
4. 系統出錯處理設計
本節描述系統發生外界及內在錯誤時，所提供的錯誤信息及處理方法，它包括系統出錯處理表及維護處理過程表。
4.1 系統出錯處理表
本表給出有關出錯處理的產生原因、提示信息、以及建議處理方法。
當系統由多個子系統(模塊)組成時，每個子系統分別使用一張系統出錯處理表進行描述。系統出錯處理表的格式如下：
子系統編號：
子系統英文名稱：
子系統中文名稱：
錯誤編號
錯誤名稱
錯誤原因
錯誤信息
處理方式
備註
說明：
其中：
● 子系統編號
含義同上。
● 子系統英文名稱
含義同上。
● 子系統中文名稱
含義同上。
● 錯誤編號
整個系統所有錯誤的統一編號。
● 錯誤名稱
錯誤的正式名稱，該名稱應該是常用的，並且爲人們所普遍接受的。
● 錯誤原因
對該錯誤產生原因的解釋與說明。
● 錯誤信息
產生該錯誤時，向用戶發出的提示信息。
● 處理方式
對該錯誤處理的一種建議，此項允許缺省。
● 備註
描述與該系統錯誤有關的其它注意事項。
● 說明
描述與該系統錯誤表有關的其它注意事項。
4.2 維護處理過程表
系統出錯時，將調用維護處理過程對錯誤進行處理，有關維護處理過程的各項內容由維護處理過程表進行描述。
當系統有多個子系統(模塊)組成時，每個子系統分別使用一張維護處理過程表進行描述。維護處理過程表的格式如下：
子系統編號：
子系統英文名稱：
子系統中文名稱：
錯誤編號
處理過程
處理過程
處理功能
入口參數
出口參數
備註
英文名稱
中文名稱
說明：
其中：
● 子系統編號
含義同上。
● 子系統英文名稱
含義同上。
● 子系統中文名稱
含義同上。
● 錯誤編號
含義同上。
● 處理過程英文名稱
系統維護處理過程的英文正式名稱，將來用於軟件開發中，必須符合命名規範。
● 處理過程中文名稱
系統維護處理過程的中文正式名稱，是系統維護處理過程英文名稱的中文說明。
● 處理功能
描述本維護處理過程對錯誤的處理方式。
由於一個維護處理過程有可能具有對多個錯誤進行處理的能力，因此該處理功能
必須是針對本項錯誤編號的。
● 入口參數
進行本項錯誤處理時，賦給維護處理過程的入口參數。
● 出口參數
進行本項錯誤處理時，維護處理過程返回的出口參數。
● 備註
描述與該系統錯誤有關的其它注意事項。
● 說明
描述與該系統錯誤表有關的其它注意事項。
5. 技術設計
系統技術設計描述系統各個特性實際使用的開發技術，以及具體開發技術使用時應該注意的事項。
5.1 系統開發技術說明表
本表描述系統各個特性開發時實際使用的具體技術，只有一些不太常用的技術需要在這裏描述。一些常用技術，例如：通過數據庫接口調用存儲過程，則不必冗述。
當系統由多個子系統(模塊)組成時，每個子系統分別使用一張系統開發技術說明表進行描述。系統開發技術說明表的格式如下：
子系統編號：
子系統英文名稱：
子系統中文名稱：
技術編號
開發技術
開發技術
處理功能
系統特性編號
備註
英文名稱
中文名稱
說明：
其中：
● 子系統編號
含義同上。
● 子系統英文名稱
含義同上。
● 子系統中文名稱
含義同上。
● 技術編號
這個系統所使用各種技術的統一編號。
● 開發技術英文名稱
該開發技術的英文正式名稱，可以便用縮寫。
該名稱應該是常用的，並且爲人們所普遍接受的。
● 開發技術中文名稱
該開發技術的中文正式名稱，是該開發技術英文名稱的中文說明。
該名稱應該是常用的，並且爲人們所普遍接受的。
● 處理功能
描述本開發技術的處理目的。
● 系統特性編號
含義同上。
由於一項開發技術可能在多處使用，因此針對一項開發技術，有可能存在多個系
統特性編號，在此必須一一列出。
● 備註
描述與該系統開發技術相關的其它注意事項。
● 說明
描述與該系統開發技術說明表有關的其它注意事項。
5.2 開發技術應用說明
逐項詳細描述系統開發技術說明表中所列出各項系統開發技術使用的技術要點，以及其它相關內容，例如：所需的服務、使用的動態連接庫、調用的組件、等等。
6. 數據庫設計
如果該軟件產品需要使用數據庫，不論是使用數據庫平臺支撐的，還是採用由軟件產品開發者自行定義的；都應該在完成軟件產品需求分析報告後，開始進行軟件產品詳細設計之前，按照軟件產品數據庫設計說明文檔模板完成數據庫設計工作。
7. 詞彙表
列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的外文原向)。爲了便於非軟件專業或者非計算機專業人士閱讀軟件系統概要設計報告，要求使用非軟件專業或者非計算機專業的術語進行描述。所以這裏所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術語。但是，對於無法迴避的軟件專業或者計算機專業術語，也應該列入詞彙表，並且加以準確定義。
8. 進度計劃
列出進度計劃，包括各子系統、各子模塊完成進度計劃，人員配備計劃等。
附錄C 軟件詳細設計報告文檔模板
1. 引言
1.1 編寫目的
1.2 項目風險
1.3 文檔約定
1.4 預期讀者和閱讀建議
1.5 參考資料
2. 支撐環境
2.1 數據庫管理系統
2.2 開發工具、中間件以及數據庫接口
2.3 硬件環境
2.4 網絡環境
2.5 多種支撐環境開發要點
3. 部件詳細設計
4. 詞彙表
5. 部件表格式
6. 界面表格式
1. 引言
引言是對這份軟件系統詳細設計報告的概覽，是爲了幫助閱讀者瞭解這份文檔如何編寫的，並且應該如何閱讀、理解和解釋這份文檔。
1.1 編寫目的
說明這份軟件系統詳細設計報告是基於哪份軟件產品需求分析報告、哪份軟件產品概要設計報告和哪份軟件產品數據庫設計說明書(如果該軟件產品需要數據庫支持)編寫的，開發這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件系統詳細設計報告詳盡說明了該軟件產品的編碼結構，從而對該軟件產品的物理組成進行準確的描述。
如果這份軟件系統詳細設計報告只與整個系統的某一部分有關係，那麼只定義軟件系統詳細設計報告中說明的那個部分或子系統。
1.2 項目風險
具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：
● 任務提出者；
● 軟件開發者；
● 產品使用者。
1.3 文檔約定
描述編寫文檔時所採用的標準(如果有標準的話)，或者各種編寫約定。編寫約定應該包括：
● 部件編號方式；
● 界面編號方式；
● 命名規範：
● 等等。
1.4 預期讀者和閱讀建議
列舉本軟件系統詳細設計報告所針對的各種不同的預期讀者，例如，可能的讀者包括：
● 開發人員；
● 項目經理；
● 測試人員；
● 文檔編寫人員；
● 等等。
描述文檔中，其餘部分的內容及其組織結構，並且針對每一類讀者提出最適合的文檔閱讀建議。
1.5 參考資料
列舉編寫軟件系統詳細設計報告時所用到的參考文獻及資料，可能包括：
● 本項目的合同書；
● 上級機關有關本項目的批文；
● 本項目已經批准的計劃任務書；
● 用戶界面風格指導；
● 開發本項目時所要用到的標難；
● 系統規格需求說明；
● 使用實例文檔；
● 屬於本項目的其它己發表文件；
● 本軟件系統詳細設計報告中所引用的文件、資料；
● 相關軟件系統詳細設計報告；
● 等等。
爲了方便讀者查閱，所有參考資料應該按一定順序排列。如果可能，每份資料都應該給出：
● 標題名稱；
● 作者或者合同簽約者；
● 文件編號或者版本號；
● 發表日期或者簽約日期；
● 出版單位或者資料來源。
2. 支撐環境
2.1 數據庫管理系統
描述數據庫管理系統、以及安裝配置情況，需要描述的內容可能包括：
● 產品名稱以及發行廠商
這裏的產品名稱指的是數據庫發行廠商發佈產品時公佈的正式商品名稱，不應該
使用別名、簡稱、研發代號等非正式名稱，以免混淆；同樣的道理，發行廠商的
名稱也應該使用正式名稱。
● 版本號
數據庫管理系統的準確版本號，必須按產品的實際情況描述到最細節的版本號。
● 補丁包版本號
描述實際上將要使用的數據庫管理系統補丁包的版本號，必須注意，在某些情況
下該版本號不一定是最新的版本號。
● 語言或代碼集
對於只支持一種語言或者一個代碼集的數據庫管理系統來說，該項描述不具意
義。對於支持多種語言或者多個代碼集的數據庫管理系統來說，該項描述指的是
實際使用的語言或者代碼集。
● 安裝位置
描述數據庫管理系統的實際安裝位置，應該分別對管理系統安缺位置和數據存放
位置進行描述，應該指明服務器名和安裝卷號(盤號)。對於分佈式數據庫，必須
分別描述每一個數據庫管理系統。
● 配置參數
描述數據庫管理系統在實際安裝時應該配置的各個參數，對於分佈式數據庫，必
須分別描述每一個數據庫管理系統的配置參數。
● 等等
同時參照《南京市交通局信息化數據庫建設規範》。
2.2 開發工具、中間件以及數據庫接口
描述所選用的工具軟件和中間件的名稱、版本號，以及開發工具與數據庫或者中間件接口的情況。如果使用了多種開發工具、輔助開發工具、第三方軟件部件、多種中間件、多種接口、等答應該逐項分別描述，並且說明每一項的適用範圍。需要描述的內容可能包括：
● 產品名稱以及發行廠商
同2.1中產品名稱以及發行廠商。
● 版本號
同2.1中版本號。
● 補丁包版本號
同2.1中補丁包版本號。
● 語言或代碼集
同2.1中語言或代碼集。
● 數據庫接口名稱
描述數據庫接口的名稱，如果使用別名時，應同時描述使用的別名。
● 數據庫接口方式
描述與數據庫接口的方式，並說明該接口方式的特點；如果需要，還應該說明使
用時的注意事項。
● 數據庫接口設置
描述各種接口設置，包括：協議、端口號等等。
同時參照《南京市交通局信息化數據庫建設規範》。
2.3 硬件環境
描述所選用的硬件環境，各種機型，例如：服務器、工作站，應該分別描述。需要描述的內容可能包括：
● 機型；
● 主頻；
● 內存容量；
● 磁盤容量；
● 特殊部件；
● 操作系統；
● 使用位置；
● 等等。
2.4 網絡環境
描述可能影響應用軟件訪問數據庫的各種網絡環境，如果存在加密傳輸、VPN鏈路等情況，也必須描述。對於結構複雜的網絡，還應該提供網絡拓撲圖和數據流向示意圖。需要描述的內容可能包括：
● 網絡結構；
● 網絡操作系統；
● 網絡帶寬；
● 路由組織；
● 加密傳輸方式；
● VPN鏈路連接方式；
● 等等。
2.5 多種支撐環境開發要點
當軟件產品將來可能遇到的多種運行環境時，應該分別按照3.1節至3.4節的內容列表描述。如果軟件產品各個子系統的運行環境不完全一樣時，應該分子系統按照3.1節至3.4節的內容列表描述。
遇到上述情況時，不僅需要詳細描述各種軟件開發、調試、測試的環境，爲了確實保證軟件產品將來能夠在各種可能的運行環境中正常運行，還需要對軟件產品進行嚴格的配置管理。
3. 部件詳細設計
這裏所提及的軟件部件，係指能夠完成特定功能、相對獨立的一些代碼集合，它們可以是插件、組件、控件、函數、過程、子程序、動態連接庫、等等。具體呈何種形態，取決於實際採用的開發工具和將要實現的軟件結構。
按照合適的順序，逐個描述軟件部件的詳細情況。描述的順序可以是按層次橫向進行描述，也可以是按模塊縱向進行描述，總之描述的方式必須有利於讀者理解軟件結構。
每個部件採用一張軟件部件表進行描述，軟件部件表的格式見附表一，其中；
● 部件編號
軟件部件的統一順序編號；對於實行配置管理的軟件開發項目來說，該編號必須
與該部件在配置管理中的編號相同。
● 部件名稱
軟件部件的正式英文名稱，該名稱是程序中使用的實際名稱，必須符合國家相關軟件命名標準。
● 所屬子系統
指該部件所屬的子系統；
對於不分爲多個子系統的軟件來說，不必填寫該欄。
● 部件調用者
指調用該部件的部件(或界面參數)的編號和名稱。
● 部件被調用者
指被該部件所調用的部件的編號和名稱。
● 部件入口參數
指該部件入口數據類名稱或者數據名稱，以及對這些數據的描述；
如果部件沒有入口參數，該欄爲空。
● 部件出口參數
指該部件出口數據類名稱或者數據名稱，以及對這些數據的描述；
如果部件沒有出口參數，該欄爲空。
● 算法
指該部件的算法形式表示，如果很簡單、或者不存在，也可以爲空。
● 流程描述
指該部件的處理流程的詳細表示或描述。
● 部件表示形式
指該部件完成開發後的最終表示形式，具體形式取決於開發工具和軟件結構，表
示形式可能是：
n 插件、組件、控件，
n 函數、過程、子程序，
n 存儲過程，
n 動態連接庫，
n 等等。
● 運行環境
描述該部件所適合的運行環境，即說明該部件是針對何種運行環境所開發的；
可以直接描述運行環境，也可以描述運行環境的編號；
對於實行配置管理的軟件開發項目來說，該描述必須與該部件在配置管理中的描
相同。
● 性能要求
指開發該部件時必須滿足的專門要求，這些要求可以是：
n 精度
n 靈活性
n 響應時間
n 可重用性
n 等等。
提出的要求一般不宜超過3項，以排列的先後順序表示優先級。
4. 詞彙表
列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的外文原詞)。爲了便於非軟件專業或者非計算機專業人士也能夠在一定的範圍內，讀懂軟件系統詳細設計報告，要求儘可能使用非軟件專業或者非計算機專業的術語進行描述。所以這裏所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術語。但是，對於無法迴避的軟件專業或者計算機專業術語，也應該列入詞彙表，並且加以準確定義。
5. 部件表格式
部件編號
部件名稱
所屬子系統
部件調用者
部件被調用者
部件入口參數
部件入口參數
算法：
流程描述：
表示性能
運行環境
性能要求
說明：如果軟件不見使用一張表表述不完時，可以採用續表描述，但是必須註明是那張表的續表。
6. 界面表格式
界面編號
部件名稱
界面性質
界面介質
表示形式：
界面參數
參數名
內容
說明
說明：如果軟件不見使用一張表表述不完時，可以採用續表描述，但是必須註明是那張表的續表。
附錄D 軟件數據庫設計報告文檔模板
1. 引言
1.1 編寫目的
1.2 項目來源
1.3 文檔約定
1.4 預期讀者和閱讀建議
1.5 參考資料
2. 數據庫命名規則
3. 數據庫設計說明
3.1 數據庫邏輯設計
3.2 數據庫物理設計
3.3 數據庫分佈
3.4 基表設計
3.5 視圖設計
3.6 索引設計
3.7 完整性約束
3.8 授權設計
3.9 觸發器設計
3.10 存儲過程設計
3.11 數據複製設計
4. 詞彙表
5. 歷史數據處理
1. 引言
引言是對這份數據庫設計說明書的概覽，是爲了幫助閱讀者瞭解這份文檔是如何編寫的，並且應該如何閱讀、理解和解釋這份文檔。
1.1 編寫目的
說明這份數據庫設計說明書是爲哪份軟件產品編寫的，開發這個軟件產品意義、作用以及最終要達到的意圖。通過這份數據庫設計說明書詳盡準確地描述了該軟件產品的數據庫結構。如果這份數據庫設計說明書只與整個系統的某一部分有關係，那麼只定義數據庫設計說明書中說明的那個部分或子系統。
1.2 項目來源
具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：
● 任務提出者；
● 軟件開發者；
● 產品使用者。
1.3 文檔約定
描述編寫文檔時所採用的各種排版約定。排版約定應該包括：
● 命名方法；
● 提示方式；
● 通配符號：
● 等等。
1.4 預期讀者和閱讀建議
列舉本數據庫設計說明書所針對的各種不同的預期讀者，例如，可能包括：
● 開發人員；
● 項目經理；
● 測試人員；
● 文檔編寫人員。
並且描述了文檔中，其餘部分的內容及其組織結構，並且針對每一類讀者提出最適合的文檔閱讀建議。
1.5 參考資料
列舉編寫需求規格說明書時所用到的參考文獻及資料，可能包括；
● 本項目的合同書；
● 上級機關有關本項目的批文；
● 本項目已經批准的計劃任務書；
● 用戶界面風格指導；
● 開發本項目時所要用到的標準；
● 系統規格需求說明；
● 使用實例文檔；
● 屬於本項目的其它已發表文件；
● 本數據庫設計說明書中所引用的文件、資料；
● 相關軟件產品數據庫設計說明書；
● 等等。
爲了方便讀者查閱，所有參考資料應該按一定順序排列。如果可能，每份資料都應該給出：
● 標題名稱；
● 作者或者合同簽約者；
● 文件編號或者版本號；
● 發表日期或者簽約日期；
● 出版單位或者資料來源。
2. 數據庫命名規則
完整並且清楚的說明本數據庫的命名規則，在《南京市交通局信息化數據庫建設規範》中已經給出了一個完整的數據庫命名規則，開發者應遵守執行，如果本數據庫的命名規則與該規範不完全一致，應作出解釋。
3. 數據庫設計說明
3.1 數據庫邏輯設計
數據庫設計人員根據《軟件需求分析報告》，創建與數據庫相關的實體關係圖(E-R圖)。如採用面對對象的分析和設計方法，則此處的實體相當於類。
在此處，應給出邏輯設計的完整的E-R圖。
3.2 數據庫物理設計
在此處應給出完整的數據庫物理結構E-R圖。開發者應根據邏輯設計的結果，進行數據庫的物理設計，並對錶結構進行規範化處理(第一範式，第二範式，第三範式)。
3.3 數據庫分佈
數據庫分佈採用一張表格進行描述，其格式如下：
數據庫
編號
數據庫
管理系統
名稱
數據庫
管理系統
版本號
數據庫
英文名稱
數據庫
中文名稱
數據庫
安裝
物理位置
其中：
● 數據庫編號
給出本系統中指定數據庫的順序編號。
若本系統中只有一個數據庫，則本項內容不需要描述，本表內容也只有一行。
說明： 在一個系統中可能安裝若干個相同的或者不同的數據庫管理系統，
一個數據庫管理系統也可能安裝一個或者多個數據庫。
● 數據庫管理系統名稱
給出本系統中指定數據庫管理系統的商品名稱。
若本系統中只有一種數據庫管理系統，則本項內容不需要描述。
● 數據庫管理系統版本號
給出本系統中指定數據庫管理系統的版本號。
若本系統中只有一個版本的數據庫管理系統，則本項內容不需要描述。
● 數據庫英文名稱
給出本數據庫的英文名稱，該名稱是在應用軟件中實際使用的名稱，必須符合《南京市交通局信息化數據庫建設規範》中相關命名規範。
● 數據庫中文名稱
給出本數據庫的中文名稱，該名稱是本數據庫英文名稱的說明。
● 數據庫安裝物理位置
給出本數據庫安裝的實際位置，必須描述清楚該位置是在那個物理設備的哪一
個邏輯存儲設備上，以及存儲文件的名稱。
3.4 基表設計
每個基表採用一張表格進行描述，其格式如下：
數據庫編號：
基表編號：
基表英文名稱：
基表中文名稱：
字段編號
英文字段名
中文字段名
字段類型
備註
說明：
其中
● 數據庫編號
含義同上。
● 基表編號
給出本基表的順序編號。
● 基表英文名稱
給出本基表的英文名稱，該名稱是在應用軟件中實際使用的名稱，必須符合命
名規範。
● 基表中文名稱
給出本基表的中文名稱，該名稱是本基表英文名稱的說明。
● 字段編號
該基表中，各個字段的順序編號。
● 英文字段名
該基表中，各個字段的英文名稱，該名稱必須符合《南京市交通局信息化數據庫建設規範》中相關命名規範。
● 中文字段名
該基表中，各個字段的中文名稱，該名稱是英文字段名的說明。
● 字段類型
該基表中，各個字段的類型；如果需要，在說明類型時，還需要說明字段長度。
● 備註
該基表中，各個字段有關的限制性說明，需要描述的內容可能包括：
n 值域；
n 缺省值；
n 空字段限制；
n 顯示格式與小數位數；
n 有效性規則與約束；
n 標題；
n 等等
● 說明
說明一些有關本表的、必須描述清楚的問題，需要描述的內容可能包括：
n 主關鍵字；
n 索引、排序方式和類型；
n 觸發器；
n 數據複製；
n 等等
3.5 視圖設計
每個視圖採用一張表格進行描述，其格式如下：
數據庫編號：
視圖編號：
視圖英文名稱：
視圖中文名稱：
相關基表和視圖：
字段編號
英文字段名
中文字段名
字段類型
字段源
備註
說明：
其中：
● 數據庫編號
含義同上。
● 視圖編號
給出本視圖的順序編號。
● 視圖英文名稱
給出本視圖的英文名稱，該名稱是在應用軟件中實際使用的名稱，必須符合
命名規範。
● 視圖中文名稱
給出本視圖的中文名稱，該名稱是本視圖英文名稱的說明。
● 相關基表和視圖
列出建立該視圖時，所用到的基表和視圖。
● 字段編號
該視圖中，各個字段的順序編號。
● 英文字段名
該視圖中，各個字段的英文名稱，該名稱必須符合《南京市交通局信息化數據庫建設規範》中相關命名規範。
● 中文字段名
該視圖中，各個字段的中文名稱，該名稱是英文字段名的說明。
● 字段類型
該視圖中，各個字段的類型；如果需要，在說明類型時，還需要說明字段長度。
● 字段源
該視圖中，各個字段的來源，即該字段原來是那個表或者那個視圖中的那個字
段；在某些情況下，字段可能來自一個特定的表達式。
● 備註
該視圖中，各個字段有關的限制性說明，包括：
n 值域；
n 缺省值；
n 空字段限制；
n 顯示格式與小數位數；
n 有效性規則與約束；
n 標題；
n 等等。
● 說明
說明一些有關本視圖的、必須描述清楚的問題，需要描述的內容可能包括：
n 索引；
n 權限；
n 等等
3.6 索引設計
每個數據庫的所有采用一張表格進行描述，其格式如下：
數據庫編號：
索引編號
基表名稱
索引名稱
字段集名稱
備註
其中：
● 數據庫編號
含義同上。
● 索引編號
給出本項索引的順序編號。
● 基表名稱
給出本項索引所在的基表名稱。
● 索引名稱
給出本項索引的名稱。
● 字段集名稱
給出本項索引所在的字段名稱或者字段集名稱。
● 備註
描述有關本項索引中，其它需要說明的事項，例如：排序方式、等等。
3.7 完整性約束
每個數據庫的完整性約束採用一張表格進行描述，其格式如下：
數據庫編號：
索引編號
基表名稱
索引名稱
字段集名稱
備註
其中：
● 數據庫編號
含義同上。
● 約束編號
給出本項完整性約束的順序編號。
● 完整性約束名
給出本項完整性約束的名稱。
● 基表名
給出本項完整性約束所在的基表名稱。
● 字段名
給出本項完整性約束所在的字段名稱。
● 約束表達式
給出本項完整性約束的邏輯表達式。
● 備註
描述有關本項完整性約束中，其它需要說明的事項。
3.8 授權設計
每個數據庫的授權採用一張表格進行描述，其格式如下：
數據庫編號：
授權編號
用戶名稱
對象名稱
權限
備註
其中：
● 數據庫編號
含義同上。
● 授權編號
給出本項授權的順序編號。
● 用戶名稱
給出本項授權的用戶名稱，這裏的用戶不一定是具體用戶，也可以是用戶組。
● 對象名稱
給出本項授權的對象名稱，例如：基表、字段、等等。
必須注意到，一個用戶可能存在多項授權，應該逐項描述。
● 權限
被授權用戶在該對象上擁有的訪問權限，例如：查詢權、修改權、等等。
● 備註
描述有關本項授權中，其它需要說明的事項。
3.9 觸發器設計
● 數據庫編號
含義同上。
● 觸發器編號
給出本觸發器的順序編號。
● 觸發器英文名稱
給出本觸發器的英文名稱，必須符合《南京市交通局信息化數據庫建設規範》中相關命名規範。
● 觸發器中文名稱
給出本觸發器的中文名稱，該名稱是本觸發器英文名稱的說明。
● 觸發器條件
給出該觸發器產生觸發的條件。
● 觸發器結果
給出該觸發器被觸發後所執行的動作內容。
3.10 存儲過程設計
每個數據庫的授權採用一張表格進行描述，其格式如下：
數據庫編號：
存儲過程編號：
存儲過程英文名稱：
存儲過程中文名稱：
存儲過程內容：
說明：
其中：
● 數據庫編號
含義同上。
● 存儲過程編號
給出本存儲過程的順序編號。
● 存儲過程英文名稱
給出本存儲過程的英文名稱，該名稱是在應用軟件中實際使用的名稱，必須符
合命名規範。
● 存儲過程中文名稱
給出本存儲過程的中文名稱，該名稱是本存儲過程英文名稱的說明。
● 存儲過程內容
給出該存儲過程算法或者描述詳細內容，如果需要，應該輔以流程圖說明。
● 說明
描述本存儲過程需要說明的一些事項。
3.11 數據複製設計
每項數據複製採用一張表格進行描述，其格式如下：
數據複製編號：
複製英文名稱：
複製中文名稱：
源數據庫編號：
目標數據庫編號：
複製說明：
執行方式：
源數據庫名稱
目標數據庫名稱
基表名稱
字段名稱
基表名稱
字段名稱
備註：
其中：
● 數據複製編號
給出本數據複製的順序編哥
● 數據複製英文名稱
給出本數據複製的英文名稱，該名稱是在應用軟件中實際使用的名稱，必須符
合命名規範。
● 數據複製中文名稱
給出本數據複製的中文名稱，該名稱是本數據複製英文名稱的說明。
● 源數據庫編號
作爲複製數據源的數據庫編號，編號含義同上。
● 目標數據庫編號
作爲複製目標的數據庫編號，編號含義同上。
● 複製說明
給出該複製的詳細描述，如果需要，應該輔以示意圖說明。
● 執行方式
給出該複製的執行方式，描述時應該說明：
● 自動執行
必須說明執行週期或者執行條件。
● 調用執行
必須說明被那個模塊調用，以及是手動調用，還是條件調用。
● 源數據庫名稱
給出對應源數據庫編號的源數據庫名稱。
● 目標數據庫名稱
給出對應目標數據庫編號的目標數據庫名稱。
● 基表名稱
分別給出源數據庫和目標數據庫中，進行對應複製的源基表名稱和目標基表名
事例。
● 字段名稱
分別給出源基表和目標基表中，進行對應複製的源字段名稱和目標字段名稱。
● 備註
描述本複製中需要說明的一些特殊事項。
4. 詞彙表
列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的
外文原詞)。爲了便於非軟件專業或者非計算機專業人士(例如：文檔編寫人員等等。)
閱讀數據庫設計說明書，要求使用非軟件專業或者非計算機專業的術語進行描述。所以這裏所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術語。但是，對於無法迴避的軟件專業或者計算機專業術語，也應該列入詞彙表，並且加以準確定義。
5. 歷史數據處理
嚴格說來，歷史數據處理並不屬於數據庫設計範疇。但是對於大多數數據庫來說，如果歷史數據處理不當，少則數月、多則數年，最終將使數據庫無法正常運行。這段時間的長短取決於數據庫設計容量大小，以及數據流強度(即在單位時間內進入數據庫的數據記錄數量)高低。因此應該設計專門的歸檔數據庫，並根據歷史數據需要保存備查的時間長短，定期將歷史數據轉移到歸檔數據庫中。
設計歸檔數據庫時，需要根據具體情況進行考慮，下面列出一些可能需要考慮的內容：
● 歷史數據需要備查的時間長短。
● 數據轉移週期的時間單位
例如：日、周、旬、月、季、年、等等。
● 數據轉移的方式
例如：手動、自動、條件、等等。
● 歷史數據保存的細節
多數情況下，歸檔的歷史數據並不需要保存全部細節，可以去掉部分細節，採
用壓縮歸檔處理的方法減少歸檔數據庫的佔用空間。
注意：如果壓縮數據時，去掉了不該去掉的細節，將是無可挽回的。
● 其它需要說明的問題
附錄E 軟件測試（驗收）大綱
1. 引言
1.1 目的
1.2 術語
1.3 參照標準
2. 測試日期安排
3. 測試小組及成員
4. 測試具體內容
4.1 合法性檢查
4.2 軟件文檔檢查
4.2.1 必須提供檢查的文檔
4.2.2 其他可能需要檢查的文檔
4.2.3 由業主確定必須檢查的其他文檔
4.2.4 文檔質量的度量準則
4.3 軟件代碼測試
4.3.1 源代碼一般性檢查
4.3.2 軟件一致性檢查
4.4 軟件系統測試
4.4.1 界面(外觀)測試
4.4.2 可用性測試
4.4.3 功能測試
4.4.4 穩定性(強度)測試
4.4.5 性能測試
4.4.6 強壯性(恢復)測試
4.4.7 邏輯性測試
4.4.8 破壞性測試
4.4.9 安全性測試
5. 測試結果交付方式
1. 引言
1.1 目的
爲了儘可能的找出軟件的不足，提高軟件的質量，促進軟件的成功驗收，專門制定了本大綱。其主要目的在於爲所要進行的測試工作制定各種必要的準則和規範，以及在有關方面協議的基礎上對測試工作進行合理組織與管理。
1.2 術語
本大綱所提及的術語，其定義遵照GB/T 11457標準。
1.3 參照標準
● GB/T 11457—1995
軟件工程術語
● GB 8566—1995；
信息技術軟件生存期過程
● OGB 8567—1988*
計算機軟件產品開發文件編制指南
● GB 9385*
計算機軟件需求說明編制指南
● GB 9386—1988*
計算機軟件測試文件編制指南
● GB/T 12504—1990
計算機軟件質量保證計劃規範
● OGB/T 12505—1990
計算機軟件配置管理計劃規範
● OGB/T 14079—1993
軟件維護指南
● OGB/T 14394—1993
計算機軟件可靠性和可維護性管理
● GB/T 16680一1996
軟件文檔管理指南
● 開發者企業規範
軟件開發者有關軟件工程的規範
● 其它文件
例如：合同書等，法律文件中的有關規定。
說明：（1）應該遵循自頂而下、就嚴不就寬的原則，除非合同書等法律文件中另有規定。
（2）標記（*）號的標準爲推薦標準。
2. 測試日期安排
開發方如期交付軟件的基礎上，由業主審覈確定具體日期安排。
3. 測試小組及成員
由業主聘請具有一定的分析、設計、編程和軟件測試經驗的測試組長和其他專業人員組成。測試組設組長一名(可設有副組長)，負責整個測試的計劃、組織工作。
或委託具有國家認可測試資質的第三方進行測試。
4. 測試具體內容
測試內容應該包括：合法性檢查、文檔檢查、軟件一致性檢查、軟件系統測試與測試結果評審等幾項工作。
4.1 合法性檢查
檢查開發者在開發本軟件時，使用的開發工具是否合法。對在編程中使用的一些非本單位自己開發的，也不是由開發工具提供的控件、組件、函數庫等，檢查其是否有合法的發佈許可。
4.2 軟件文檔檢查
4.2.1 必須提供檢查的文檔
● 項目實施計劃；
● 詳細技術方案；
● 軟件需求規格說明書(STP)(含數據字典)；
● 概要設計說明書(PDD)；
● 詳細設計說明書(DDD)(含數據庫設計說明書)；
● 軟件測試計劃(STP)(含測試用例)；
● 軟件測試報告(STR)；
● 用戶手冊(SUM)(含操作、使用、維護、應急處理手冊)；
● 源程序(SCL)(不可修改的電子文檔)；
● 項目實施計劃(PIP)；
● 項目開發總結(PDS)；
● 軟件質量保證計劃(SQAP)；
4.2.2 其他可能需要檢查的文檔
● 軟件配置計劃(SCMPP)；
● 項目進展報表(PPR)；
● 階段評審報表(PRR)；
4.2.3 由業主確定必須檢查的其他文檔
說明：如果業主認爲4.1.1節和4.1.2節所列文檔之外，還需要檢查其它文檔，則在此列出文檔名稱；如果業主認爲不需要進行額外的文檔檢查，則本部分無內容。
4.2.4 文檔質量的度量準則
文檔是軟件的重要組成都分，是軟件生存週期各個不同階段的產品描述。文檔質量的度量準則就是要評審各階段文檔的合適性。主要有以下六條：
● 完備性
開發方必須按照GB 8567(計算機軟件產品開發文件編制指南)的規定編制相應的
文檔，以保證在開發階段結束時其文檔是齊全的。
● 正確性
在軟件開發各個階段所編寫的文檔的內容，必須真實的反映階段的工作且與該階
段的需求相一致。
● 簡明性
在軟件開發各個階段所編寫的各種文檔的語言表達應該清晰、準確簡練，適合各
種文檔的特定讀者。
● 可追蹤性
在軟件開發各個階段所編寫的各種文檔應該具有良好的可追蹤性。文檔的可追蹤
性包括橫向可追蹤性和縱向可追蹤性兩個方面。前者是指在不同的文檔的相關內
容之間相互檢索的難易程序；後者是指確定同一文檔某一內容在本文檔範圍中檢
索的難易程度。
● 自說明性
在軟件開發各個階段所編寫的各種文檔應該具有較好的自說明性。文檔的自說明
性是指在軟件開發各個階段中，不同文檔能夠獨立表達，該軟件在其相應階段的
階段成果的能力。
● 規範性
在軟件開發各個階段所編寫的各種文檔應該具有良好的規範性。文檔的規範性是
指文檔的封面、大綱、術語的含義以及圖示符號等符合有關規範的規定。
4.3 軟件代碼測試
4.3.1 源代碼一般性檢查
僅對系統關鍵模塊的源代碼進行抽查，檢查模塊代碼編寫的規範性，批註的準確性，是否存在潛在性錯誤，以及代碼的可維護性。
● 命名規範檢查
檢查源代碼中的變量、函數、對象、過程等的命名是否符合約定規範，該規範可
以由開發方在軟件工程文檔規範中單方面約定。
● 註釋檢查
檢查程序中的註釋是否規範，註釋量是否達到約定要求，例如：要求註釋量達到
30％左右。
● 接口檢查
檢查數據庫接口等外部接口是否符合要求，各程序模塊使用的接口方式是否一
致，特定的外部接口協議是否符合。
● 數據類型檢查
源代碼中涉及的金額的常量、變量及數據集和數據庫中涉及金額的數據類型是否
採用貨幣類型，以防止在特定條件下產生較大的誤差而影響統計結果。
● 限制性檢查
對一些程序中使用到的、具有使用限制的命令、事件、方法、過程、函數、對象、
控件等進行檢查。檢查在長時間運行時，有無可能接近或者達到限制條件，
這裏考慮的系統運行時間可能長達數年。
4.3.2 軟件一致性檢查
● 編譯檢查
要求提交的源代碼在其規定的編譯環境中，能夠重新編譯無錯誤，並且能夠完成
相應的功能，從而確定移交的確實是正確的源代碼。
● 安裝／卸載檢查
在新系統上用交付的軟件安裝盤重新安裝各個模塊，並且通過運行這些軟件模
塊，能否完成相應的功能，從而確定移交的確實是正確的軟件安裝盤。
在安裝後立即卸載所安裝的模塊，並且檢查是否能夠做到徹底卸載。
● 運行模塊檢查
將新安裝的軟件模塊與現場運行模塊用軟件工具抽樣比較，確認交付的軟件安裝
盤與現場運行軟件一致。
抽查數處現場運行模塊用軟件工具比較，確認現場運行軟件一致。
4.4 軟件系統測試
軟件系統測試不僅是檢測軟件的整體行爲表現，從另一個側面看，也是對軟件開發設計的再確認。
進行軟件系統測試工作時，具體的測試用例是由開發方提供，並由測試方和用戶共同補充制定的。在開發方做完功能演示後，可以進行下列測試：
● 界面(外觀)測試；
● 可用性測試；
● 功能測試；
● 穩定性(強度)測試；
● 性能測試；
● 強壯性(恢復)測試；
● 邏輯性測試；
● 破壞性測試；
● 安全性測試。
說明：實際進行的測試內容有測試方法和業主根據具體情況共同確定，並非文中所列測試內容都必須進行測試。
4.4.1 界面(外觀)測試
對照界面規範(在軟件需求規格說明書中規定，或者由軟件工程規範中給出)和界面表(在概要設計中給出)，檢查各界面設計是否規範，包括：界面風格、表現形式、組件用法、字體選擇、字號選擇、色彩搭配、日期表現、計時方法、時間格式、對齊方式等等，是否符合規範、是否協調一致、是否便於操作。
4.4.2 可用性測試
測試操作是否方便，用戶界面是否友好等。測試系統是否有影響操作流程的界面Bug和功能Bug，紀錄具體Bug的數量、出現頻率和嚴重程度。
4.4.3 功能測試
檢查數據在流程中各個階段的準確性。對系統中每一模塊利用實際數據運行，將其結果與同樣數據環境下應該得出的結果相比較，或與軟件需求規格說明書中要求的結果進行比較，如有偏差，則功能測試不能通過。
檢查軟件需求規格說明書中描述的需求是否都得到滿足；系統是否缺乏軟件需求規格說明書中規定的重要功能；以及系統實際使用中不可缺少而軟件需求規格說明書中沒有規定的功能。
如果存在遺產數據，應該檢查遺產數據轉換是否正確。
4.4.4 穩定性(強度)測試
測試系統的能力最高實際限度，即檢查軟件在一些超負荷情況下，功能實現的情況。例如：要求軟件進行某一行爲的大量重複、輸入大量的數據或大數值數據、對數據庫進行大量複雜的查詢等。
利用邊界測試(最大值、最小值、N次循環)對系統進行模擬運行測試，觀察其是否處於穩定狀態。
4.4.5 性能測試
根據系統設計指標，或者對被測軟件提出的性能指標，測試軟件的運行性能，例如：傳輸連接最長時限、傳輸錯誤率、計算精度、記錄精度、響應時限和恢復時限等。
4.4.6 強壯性(恢復)測試
採用人工的干擾使應用軟件、平臺軟件或者系統硬件出錯，中斷正常使用，檢測系統的恢復能力。進行強壯性測試時，應該參考性能測試相關的測試指標。
4.4.7 邏輯性測試
根據系統的功能邏輯圖，測試軟件是否按規定的邏輯路徑運行，選擇一些極限數據判斷軟件運行是否存在錯誤或非法路徑，從而發現系統的邏輯錯誤或非法後門。
4.4.8 破壞性測試
輸入錯誤的或非法的數據(類型)，檢查系統的報錯糾錯的能力及穩定性。並測試可連續使用多長時間而系統不崩潰。
4.4.9 安全性測試
驗證安裝在系統內的保護機構確實能夠對系統進行保護，使之不受各種非常的干擾，安全測試時需要設計一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密的漏洞。
說明：進行安全測試時，必須遵循相關的安全規定，並且有業主派員參加。
5. 測試結果交付方式
測試結束後，由測試組填寫軟件測試報告，並將測試報告與全部測試材料一併交給業主。具體交付方式，由業主和測試方雙方協商確定。測試報告包括下列內容：
● 軟件測試計劃
● 軟件測試日誌
● 軟件文檔檢查報告
● 軟件代碼測試報告
● 軟件系統測試報告
● 測試總結報告
● 測試人員簽字登記表
————————————————
原文鏈接：https://blog.csdn.net/eaglewood2005/article/details/4076494