【導讀】本文檔是軟件立項書，目的是代替可行性分析。對軟件組織內(nèi)部和外部有關的行業(yè)術語、專用名詞進行定義。對書寫該立項書所用到的有關資料進行說明。當該文檔變更時，可能對其他文檔產(chǎn)生影響，受影響的文檔叫做相關文檔，需將它們一一列出。任何一次版本創(chuàng)建或維護更新，都要追加一條記錄。記錄格式，如表3-2所示。宏觀上說明該項目是什么、能干什么、要求干得怎么樣。并說明結構具體詳細的運行平臺：硬件的要求、操作系統(tǒng)的要求、數(shù)據(jù)庫管理系統(tǒng)的要求、對外接口的要求。單機結構、C/S結構、B/S結構對應哪三種客戶群，每種客戶群的數(shù)量、素質(zhì)、市場前景等。當前客戶群是指已簽訂合作協(xié)議或?qū)⒁炗喓献鲄f(xié)議的客戶群，分析他們的數(shù)量、素質(zhì)、市場前景等?；ヂ?lián)網(wǎng)絡版功能，如表3-5所示。C/S結構、B/S結構兩種架構的并發(fā)處理最大終端（用戶）負載數(shù)量分析。以上性能要求，最好也用列表的形式給出。

　　

【正文】 局、打印格式等。 接口需求點列表（接口模型）（ Interface Requirement）（ Interface Model） （ 1）與其他系統(tǒng)的接口，如監(jiān)控系統(tǒng)、控制系統(tǒng)、銀行結算系統(tǒng)、稅控系統(tǒng)、財務系統(tǒng)、政府網(wǎng)絡系統(tǒng)及其他系統(tǒng)等。 （ 2）與系統(tǒng)特殊外設的接口，如 CT 機、磁共振、柜員機（ ATM）、 IC 卡、盤點機等。 （ 3）與中間件的接口，要列出接口規(guī)范、入口參數(shù)、出口參數(shù)、傳輸頻率等。 應在此列舉出所有的外部接口名稱、接口標準、規(guī)范。外部接口列表，如表 526 所示。 表 526 接口需求點列表 編號 接口名稱 接口規(guī)范 接口標準 入口參數(shù) 出口參數(shù) 傳輸頻率 1 2 3 6．目標系統(tǒng)其他需求 （ Oher Requirement of Target System） 安全性（ Security） 可靠性（ Dependability） 靈活性（ Agility） 特殊需求（ Special Requirement） 如： （ 1）進度需求：系統(tǒng)的階段進度要求。 （ 2）資金需求：投資額度。 （ 3）運行環(huán)境需求：平臺、體系結構、設備要求。 （ 4）培訓需求：用戶對培訓的需求，是否提供多媒體教學光盤。 （ 5）推廣需求 ：推廣的要求，如在上百個遠程的部門推廣該系統(tǒng)，是否要有推廣的支持軟件。 7．目標系統(tǒng)假設與約束條件 （ Suppose and Restriction of Target System） 假設與約定條件是對預計的系統(tǒng)風險的描述 ,如： （ 1）法律、法規(guī)和政策方面的限制。 （ 2）硬件、軟件、運行環(huán)境和開發(fā)環(huán)境方面的條件和限制。 （ 3）可利用的信息和資源。 （ 4）系統(tǒng)投入使用的最晚時間。 （ 5）需求中的風險分析：技術風險、技能風險、時間風險、資源風險。 7《需求報告 / 需求規(guī)格說明書評審記錄表》 《用戶需求報告 / 需求規(guī)格說明書評審記錄表》 （ Review Table of Requirements） 項目名稱 項目經(jīng)理 評審階段 用戶需求報告 /需求規(guī)格說明書 第 次評審 評審組組長 評審時間 評審地點 評審組成員 不符合項跟蹤記錄（ Check list of nonpliance items） 不符合項名稱 不 符合 項內(nèi)容 限 期改 正時間 實際改正時間 測試合格時間 測試員簽字 審計員簽字 評審意見 評審結論 評審組長簽字： 評審組成員簽字： 表 528 《需求變更管理表》 （ Modification Table of Requirements） 項目名稱 申請日期 用戶名稱 審批日期 變更原因 實際變更日期 原來需求 變更內(nèi)容 審批意見 申請人： 審批人： 8“圖書館信息系統(tǒng)” “圖書館信息系統(tǒng)”數(shù)據(jù)模型設計案例 “圖書館信息系統(tǒng)”的概念數(shù)據(jù)模型 CDM（見圖 610）和物理數(shù)據(jù)模型 PDM（見圖 611）分析。 首先，介紹一下在 ER 圖中實體的表示法，如圖 610 所示。 一個矩形框表示一個實體，框內(nèi)第一部分（第一行）的文字表示該實體的名稱，如“圖書”。第二部分表示該實體的多個屬性，每個屬性占一行，如“圖書號、書名、單價、作者”等。帶下劃線的屬性為主關鍵字，即主鍵 PK（或主碼），如“ 圖書號 ”。兩個實體之間的關系，用一條連線表示。關系有三種：一對一關系，就是一條連線；一對多關系，多的一端是一個三叉線（ ERwin 工具中為一個黑色小圓球）；多對多關系，兩端都是三叉線 。連線的一端若有一個小圓圈，則表示非強制型的關系；連線的一端若有一個小十字架，則表示強制型的關系。 圖 610 “圖書館信息系統(tǒng)”的概念數(shù)據(jù)模型 CDM 系統(tǒng)的 ER 圖又稱為系統(tǒng)的概念數(shù)據(jù)模型 CDM，有了它以后，利用 PowerDesigner 工具，就能自動生成物 理數(shù)據(jù)模型 PDM。 首先分析“圖書館信息系統(tǒng)”的概念數(shù)據(jù)模型 CDM，如圖 610 所示。因為圖書館的主要功能不外乎兩點，藏書與為讀者服務。其他許多功能都是圍繞這兩項功能而展開的。所以“圖書館信息系統(tǒng)”的主要實體是“圖書”和“讀者”。 “圖書”的屬性 有圖書號、書名、作者、出版社、單價等，“讀者”的屬性有讀者號、姓名、電話等。 由于一本圖書可以被多個讀者在不同時間借閱，一名讀者又可以一次或多次借閱多本圖書，所以該兩個實體之間是多對多的關系。為了消除這個多對多關系，在兩者之間插入第 3 個實體，該實體取名為“借還書”?！敖柽€書”至少有兩個屬性：借書還書時間、借書還書標志。另外，它還有兩個外鍵，圖書號和讀者號。當增加“借還書”這個實體之后，原來一個多對多的關系，現(xiàn)在變?yōu)閮蓚€一對多的關系：“圖書”對“借還書”，“讀者”對“借還書”。 “圖書館信息系統(tǒng)”中還有許多其 他實體，它們都是圍繞這 3 個主要實體及其關系而展開的。這 3 個實體是“圖書館信息系統(tǒng)”的核心。例如，“書庫”和“單位”這兩個實體，就是分別圍繞“圖書”和“讀者”而展開的?！皶鴰臁北硎緢D書存放在什么地方，以及該書是否借出，即該本書的架位號、架位地址，以及借出標志位的狀態(tài)。由于一個架位號上可放多本書，所以“書庫”和“圖書”是一對多的關系。同樣，“單位”表示讀者在什么單位，即該讀者的單位名稱、單位地址和單位電話等，由于一個單位可有多個讀者，所以“單位”和“讀者”是一對多的關系。以上實體、屬性、關系如圖 610 所示。 圖 611 “圖書館信息系統(tǒng)” 的物理數(shù)據(jù)模型 PDM 再來分析“圖書館信息系統(tǒng)”的物理數(shù)據(jù)模型 PDM，如圖 611 所示。此 PDM 是由 CDM 生成的。不 難發(fā)現(xiàn)：在生成 PDM 的過程中，凡是 CDM 中的一對多的關系，主表中的主鍵 PK 都自動拷貝到子表中去，作為子表的外鍵 FK，這就是數(shù)據(jù)庫設計工具 PowerDesigner 的一項功能。該 PDM 比較整齊規(guī)范，那是因為在生成之后進行了手工調(diào)整。 9《概要設計說明書》 《概要設計說明書》編寫參考指南 1．導言 （ Introduction） 本章對該文檔的目的、功能范圍、術語 、相關文檔、參考資料、版本更新進行說明。 目的（ Purpose） 本文檔的目旨在推動軟件工程的規(guī)范化，使設計人員遵循統(tǒng)一的概要設計書寫規(guī)范，節(jié)省制作文檔的時間，降低系統(tǒng)實現(xiàn)的風險，做到系統(tǒng)設計資料的規(guī)范性與全面性，以利于系統(tǒng)的實現(xiàn)、測試、維護、版本升級等。 范圍（ Scope） 本文檔用于軟件設計階段的概要設計，它的上游（依據(jù)的基線）是《需求分析規(guī)格書》，它的下游是《詳細設計說明書》，并為《詳細設計說明書》提供測試的依據(jù)。 軟件概要設計的范圍是：軟件系統(tǒng)總體結構設計、全局數(shù)據(jù)庫和數(shù)據(jù)結構設計、外部接口設計、主要部件功能分配設計、部件之間的接口設計等方面的內(nèi)容。該范圍應覆蓋《需求規(guī)格說明書》中的功能點列表、性能點列表、接口列表。 命名規(guī)則（ Naming Rule） 變量對象命名規(guī)則：申明全局變量、局部變量對象的命名規(guī)則。 數(shù)據(jù)庫對象命名規(guī)則：申明數(shù)據(jù)庫表名、字段名、索引名、視圖名等對象的命名規(guī)則。 術語定義（ Terms Glossary） 術語定義或解釋一般用表格形式給出，如表 65 所示。 表 65 術語定義或 解釋表 序 號 術 語 名 稱 術 語 定 義 1 總體結構 軟件系統(tǒng)的總體邏輯結構。按照不同的設計方法，有不同的總體邏輯結構。若采用面向功能或面向數(shù)據(jù)的設計方法，則總體邏輯結構為一樹形的功能模塊結構圖。若采用面向?qū)ο蠡蛎嫦虿考嫾┑脑O計方法，則總體邏輯結構為部件（構件）的組裝圖 2 外部接口 本軟件系統(tǒng)與其他軟件系統(tǒng)之間的接口，接口設施可以是中間件。接口描述包括：傳輸方式、帶寬、數(shù)據(jù)結構、傳輸頻率、傳輸量、傳輸協(xié)議 3 數(shù)據(jù)結構 數(shù)據(jù)結構包括：數(shù)據(jù)庫表的結構、其他數(shù)據(jù)結構等 4 概念數(shù)據(jù) 模型 CDM 關系數(shù)據(jù)庫的邏輯設計模型，叫做概念數(shù)據(jù)模型。主要內(nèi)容包括一張邏輯 ER 圖及其相應的數(shù)據(jù)字典 5 物理數(shù)據(jù) 模型 PDM 關系數(shù)據(jù)庫的物理設計模型，叫做物理數(shù)據(jù)模型。主要內(nèi)容包括一張物理表關系圖及其相應的數(shù)據(jù)字典 6 視圖 在基表或其他視圖之上建立的一張?zhí)摫恚凶鲆晥D，它具有物理表的許多性質(zhì)，在數(shù)據(jù)處理和授權上很有用 7 角色 數(shù)據(jù)庫中享有某些特權操作的用戶，叫做角色。角色的權利通過授權來實現(xiàn) 8 子系統(tǒng) 具有相對獨立功能的小系統(tǒng)叫做子系統(tǒng)。一個大的軟件系統(tǒng) 可以劃分為多個子系統(tǒng)，每個子系統(tǒng)可由多個模塊或多個部件組成 9 模塊 具有功能獨立、能被調(diào)用的信息單元叫做模塊。模塊是結構化設計中的概念 10 內(nèi)部接口 軟件系統(tǒng)內(nèi)部各子系統(tǒng)之間、各部件之間、各模板之間的接口，叫做內(nèi)部接口。接口描述包括：調(diào)用方式、入口信息、出口信息等 11 相關文件 相關文件是指當本文件內(nèi)容變更后，可能引起變更的其他文件。如需求分析報告、詳細設計說明書、測試計劃、用戶手冊 12 參考資料 參考資料是指本文件書寫時用到的其他資料。如各種有關規(guī)范、模板、標準、準則 參考資料（ References） [1] 用戶需求報告 [2] 軟件開發(fā)合同 [3] 數(shù)據(jù)庫設計規(guī)范 [4] 命名規(guī)范 相關文檔（ Related Documents） [1] 《詳細設計說明書》 [2] 源程序清單 [3] 測試計劃及報告 [4] 《用戶使用手冊》 版本更新記錄（ Version Updated Record） 版本更新記錄格式，如表 66 所示。 表 66 版本更新記錄 版本號 創(chuàng)建者 創(chuàng)建日期 維護者 維護日期 維護紀要 王大林 2001/02/18 — — — — — 王小林 2001/02/26 ER 圖維護 2．總體設計 （ Design of Collective） 總體結構設計（ Design of Collective Structure） 軟件系統(tǒng)的總體邏輯結構，按照不同的設計方法，有不同的總體邏輯結構。本指南以結構化設計方法為主，畫出系統(tǒng)總體結構圖，列出系統(tǒng)的功能模塊清單編號、名稱、功能，并盡可能描繪出功能模塊之間的關系。若用面向?qū)ο蟮?Rose 工具進行分析和設計，則遵照 Rose 的要求進行。 總體結構示意圖 ， 如圖 613 所示。 圖 613 總體結構示意圖 運行環(huán)境設計（ Design of Running Environment） 該軟件系統(tǒng)的運行環(huán)境： 硬件平臺： （ 1）服務器的最低配置要求 （ 2）工作站的最低配置要求 （ 3）外設的要求 軟件平臺： （ 1）服務器操作系統(tǒng) （ 2）數(shù)據(jù)庫管理系統(tǒng) （ 3）中間件 （ 4）客戶端的操作系統(tǒng) （ 5）客戶端的平臺軟件 網(wǎng)絡平臺： （ 1）通信協(xié)議 （ 2）通信帶寬 子系統(tǒng)清單（ Subsystem List） 子系統(tǒng)清單，如表 67 所示。 XX 系統(tǒng) 總體結構圖 子系統(tǒng) 1 子系統(tǒng) 2 子系統(tǒng) N 子系統(tǒng) 21 子系統(tǒng) 22程序 2) 目標程序 3) 用戶指南 子系統(tǒng) 2M 表 67 子系統(tǒng)清單 子系統(tǒng)編號 子系統(tǒng)英文名 子系統(tǒng)功能簡述 子系統(tǒng)之間的關系 SS1 SS2 SS3 功能模塊清單（ Function Module List） 功能模塊清單，如表 68 所示。 表 68 功能模塊清單 模 塊 編 號 模塊英文名 模塊功能簡述 模塊的接口簡述 M 11 M 12 M 21 M 22 3．模塊（部件）功能分配 （ Functional Distribution of Module） 具有功能獨立、能被調(diào) 用的信息單元叫做模塊。模塊是結構化設計中的概念，部件是面向?qū)ο笤O計中的概念。 模塊功能分配的目的，就是為了將具有相同功能的模塊合并，從中提取公用模塊，形成公用部件，按照構件或中間件的方式加以實現(xiàn)，作為本系統(tǒng)的公用資源，甚至作為公司級組織的公用資源，從而充實公司級的構件庫或中間件庫，優(yōu)化系統(tǒng)設計，加快開發(fā)速度，提高開發(fā)質(zhì)量。 專用模塊功能分配（ Functional Distribution of Expert Module） 專用