軟件分析報告模板

目錄范圍.............................................................................................................................................總體要求.....................................................................................................................................2.1總體功能要求.......................................................................................................................2.2軟件開發(fā)平臺要求...............................................................................................................2.3軟件項目的開發(fā)實施過程管理要求....................................................................................2.3.1軟件項目實施過程總體要求........................................................................................2.3.2軟件項目實施變更要求................................................................................................2.3.3軟件項目實施里程碑控制............................................................................................3.軟件開發(fā) .....................................................................................................................................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概要設計和需求分析、詳細設計之間的關(guān)系和區(qū)別................................................3.2.5概要設計的評審............................................................................................................3.2.6概要設計格式................................................................................................................3.3軟件的詳細設計...................................................................................................................3.3.1詳細設計........................................................................................................................3.3.2特例................................................................................................................................3.3.3詳細設計的要求............................................................................................................3.3.4數(shù)據(jù)庫設計....................................................................................................................3.3.5詳細設計的評審............................................................................................................3.3.6詳細設計格式................................................................................................................3.4軟件的編碼...........................................................................................................................3.4.1軟件編碼........................................................................................................................3.4.2軟件編碼的要求............................................................................................................3.4.3編碼的評審....................................................................................................................3.4.4編程規(guī)范及要求............................................................................................................3.5軟件的測試...........................................................................................................................3.5.1軟件測試........................................................................................................................3.5.2測試計劃........................................................................................................................3.6軟件的交付準備...................................................................................................................3.6.1交付清單........................................................................................................................

11112222333444444444455555555556666666I3.7軟件的鑒定驗收 7 軟件的鑒定驗收 7 驗收人員 7 驗收具體內(nèi)容 7 軟件驗收測試大綱 73.8培訓 7 系統(tǒng)應用培訓 7 系統(tǒng)管理的培訓（可選） 8附錄 A 軟件需求分析報告文檔模板 9附錄 B 軟件概要設計報告文檔模板 21附錄 C 軟件詳細設計報告文檔模板 33附錄 D 軟件數(shù)據(jù)庫設計報告文檔模板 43附錄 E 軟件測試 (驗收)大綱 錯誤！未定義書簽。 5II范圍本指南用于指導軟件開發(fā)者為南京市交通局開發(fā)軟件項目的過程， 通過規(guī)范軟件項目承擔單位的開發(fā)過程達到提高軟件質(zhì)量， 降低維護成本的目的。 開發(fā)者應根據(jù)本指南進行軟件開發(fā)和編制軟件開發(fā)文檔。本指南是對軟件項目承擔單位的基本要求。在本指南的附錄 A至E中提供了文檔的編寫模板供開發(fā)者參考，在進行具體軟件開發(fā)時，開發(fā)者可根據(jù)實際情況采編寫，但必須提供雙方約定的文檔，文檔中約定的內(nèi)容必須描述清楚。總體要求2.1 總體功能要求網(wǎng)絡應用環(huán)境以 Internet/Intranet 技術(shù)為核心。開發(fā)者應在充分分析需求的基礎上，選擇采用 B/S結(jié)構(gòu)或者 C/S結(jié)構(gòu)。軟件系統(tǒng)的數(shù)據(jù)庫應依照《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》進行設計和建設。本指南中沒有規(guī)定開發(fā)者采用何種具體的軟件工程開發(fā)方法， 開發(fā)者可根據(jù)項目具體特點、自身擅長來選擇采用面向過程的方法、 面向?qū)ο蟮姆椒ɑ蛎嫦驍?shù)據(jù)的方法， 但建議開發(fā)商使用面向?qū)ο筌浖こ痰姆椒ǎ?如：采用目前被廣泛使用的 RUP(RationalUnifiedProcess)方法來進行分析、設計和開發(fā)。2.2 軟件開發(fā)平臺要求開發(fā)者開發(fā)的軟件必須能夠在南京市交通局規(guī)定的軟件平臺上正常運行。 目前軟件平臺為：數(shù)據(jù)庫管理系統(tǒng)：Oracle9i 以上版本中間件(應用服務器 )系統(tǒng)：IBMWebSphereOA系統(tǒng)：LotusDomino/Notes網(wǎng)絡架構(gòu)：完全支持 TCP/IP協(xié)議開發(fā)工具或技術(shù)體系：為保證軟件的上下兼容性，開發(fā)者應選擇比較通用的開發(fā)工具的較新版本進行開發(fā)，如MicrosoftVisualStudio.Net ，BorlandDelphi ，C++Builder, 或J2EE(Java2P1atformEnterpriseEdition) 等。12.3 軟件項目的開發(fā)實施過程管理要求 軟件項目實施過程總體要求（一）開發(fā)者提交軟件開發(fā)工作大綱，交通局組織專家組對工作大綱進行評審，并提出整改意見。（二）通過評審后，開發(fā)者根據(jù)整改意見完善工作大綱，經(jīng)過交通局認可后組織項目組進行軟件開發(fā)。軟件開發(fā)工作按照需求分析、概要設計、詳細設計、編碼、測試等幾個階段進行，在開發(fā)過程中，開發(fā)者需分階段提交相關(guān)文檔。（三）在軟件開發(fā)工作完成后，開發(fā)者應向交通局提交完整的軟件文檔，交通局組織驗收組對軟件進行驗收審查。 軟件項目實施變更要求在開發(fā)過程中， 需求或設計不可避免地需要發(fā)生變更， 相關(guān)變更必須經(jīng)過交通局書面同意方可進行。 在需求或設計發(fā)生變更時， 需要對原有文檔進行修改， 并提供完整的變更記錄，以使變更處于可控制的狀態(tài)。變更單如下表所示：申請變更的需求文檔變更的內(nèi)客及其理由評估需求變更將對項目造成的影響申請人簽字項目經(jīng)理簽字客戶簽字(合同項目 )

表2-1變更單需求變更申請輸入名稱，版本，日期等信息變更申請的審批意見審批意見：簽字 日期審批意見：簽字 日期更改需求文檔變更后的輸入名稱，版本，完成日期等信息需求文檔更改人簽字重新評審需求文檔評審意見：需求評審小組簽字簽字 日期變更結(jié)束項目經(jīng)理簽字 簽字 日期 軟件項目實施里程碑控制交通局將分四個階段進行把關(guān)，召開專家審查會。（一） 需求分析（結(jié)合原型進行審查）確認；（二） 概要設計 +數(shù)據(jù)庫設計；2（三） 預驗收（試運行后） ；（四） 正式驗收（推廣使用后） 。軟件開發(fā)合同簽訂以后， 項目承擔單位即可組織項目組進行軟件開發(fā)工作。 軟件開發(fā)必須嚴格按照軟件工程的要求進行。 開發(fā)過程包括開發(fā)者的活動和任務。 此過程由軟件需求分析、 概要設計、詳細設計、編碼、測試、驗收、鑒定等活動組成。3.1 軟件的需求分析 需求分析首先，開發(fā)者和交通局應共同對交通局的應用需求作充分的調(diào)研， 提交完整的需求分析報告。在需求分析報告中必須描述的基本問題是：功能、性能、強加于實現(xiàn)的設計限制、屬性、外部接口。 應當避免把設計或項目需求寫入需求分析報告中。 它必須說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果的手段。軟件需求可以用若干種方法來表達， 如通過輸入、 輸出說明； 使用代表性的例子； 用規(guī)范化的模型。 開發(fā)者應盡可能地使用模型的方式， 因為這是表達復雜需求的精確和有效的方法。比如用統(tǒng)一建模語言（ UML）來描述需求。編寫需求分析報告的要求a．無歧義性對最終產(chǎn)品的每一個特性用某一術(shù)語描述； 若某一術(shù)語在某一特殊的行文中使用時具有多種含義，那么應對該術(shù)語的每種含義做出解釋并指出其適用場合。b．完整性需求分析報告應該包括全部有意義的需求， 無論是關(guān)系到功能的、 性能的、設計約束的、還是關(guān)系到外部接口方面的需求； 對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應予以定義， 要對合法和非合法的輸入值的響應做出規(guī)定；填寫全部插圖、 表、圖示標記等；定義全部術(shù)語和度量單位。c．可驗證性需求分析報告描述的每一個需求應是可以驗證的。 可以通過一個有限處理過程來檢查軟件產(chǎn)品是否滿足需求。d．一致性在需求分析報告中的各個需求的描述不能互相矛盾。e．可修改性需求分析報告應具有一個有條不紊、 易于使用的內(nèi)容組織； 沒有冗余， 即同一需求不能在需求分析報告中出現(xiàn)多次。f．可追蹤性每一個需求的源流必須清晰， 在進一步產(chǎn)生和改變文件編制時， 可以方便地引證每一個需求。g．運行和維護階段的可使用性需求分析報告必須滿足運行和維護階段的需要。 在需求分析報告要寫明功能的來源和目的。3 需求分析報告的編制者需求分析報告應由交通局和開發(fā)者雙方共同完成。 其中：交通局負責根據(jù)實際需要提出希望軟件實現(xiàn)的功能； 軟件開發(fā)者根據(jù)交通局提出的性能需求， 結(jié)合軟件開發(fā)編寫需求分析。 需求報告評審在軟件需求分析工作完成后，軟件開發(fā)者應向交通局提交《軟件需求分析報告》 。交通局組織有關(guān)人員對需求進行評審， 以決定軟件需求是否完善和恰當。 評審完成后， 就可以進入軟件的設計階段。 需求報告格式《軟件需求分析報告》需按一定的格式進行編寫， 具體的《軟件需求分析報告》文檔編寫模板請見附錄 A。3.2 軟件的概要設計 概要設計在交通局和開發(fā)者雙方認可的《需求分析報告》基礎上，開發(fā)者進行下——步的工作。首先，開發(fā)者需要對軟件系統(tǒng)進行概要設計， 即系統(tǒng)設計。 概要設計需要對軟件系統(tǒng)的設計進行考慮，包括系統(tǒng)的基本處理流程、系統(tǒng)的組織結(jié)構(gòu)、模塊劃分、功能分配、接口設計、運行設計、數(shù)據(jù)結(jié)構(gòu)設計和出錯處理設計等，為軟件的詳細設計提供基礎。 編寫概要設計的要求a．一致性概要設計的要求應該與需求分析報告所描述的需求一致。 同時，概要設計的各項要求之間也應該一致。b．合理性概要設計所提出的設計方法和標準應該是合理的、恰當?shù)摹．可追蹤性對概要設計所提出的各項要求應該可以得到它的清晰的源流， 即在需求分析報告客戶有明確的需求描述。d．可行性根據(jù)概要設計進行詳細設計、操作和維護應該是可行的。 概要設計報告的編寫者概要設計報告由開發(fā)者根據(jù)需求分析報告的要求進行編寫。 概要設計和需求分析、詳細設計之間的關(guān)系和區(qū)別需求分析不涉及具體的技術(shù)實現(xiàn)，而概要設計注重于從宏觀上和框架上來描述采用何種技術(shù)手段、 方法來實現(xiàn)這些需求。 詳細設計相對概要設計更注重于微觀上和框架內(nèi)的設計，是編碼的依據(jù)。概要設計是指導詳細設計的依據(jù)。 概要設計的評審在軟件概要設計工作完成后，軟件開發(fā)者應向交通提交《軟件系統(tǒng)概要設計報告》 。在交通局對《概要設計報告》評審通過后，即可進入詳細設計階段。 概要設計格式《軟件系統(tǒng)概要設計報告》需按一定的格式進行編寫，具體的《軟件系統(tǒng)概要設計報告》文檔編寫模板請見附錄 B。43.3 軟件的詳細設計 詳細設計在概要設計的基礎上，開發(fā)者需要進行軟件系統(tǒng)的詳細設計。在詳細設計中，描述實現(xiàn)具體模塊所涉及到的主要算法、 數(shù)據(jù)結(jié)構(gòu)、 類的層次結(jié)構(gòu)及調(diào)用關(guān)系， 需要說明軟件系統(tǒng)各個層次中的每一個程序 (每個模塊或子程序 )的設計考慮，以便進行編碼和測試。應當保證軟件的需求完全分配給整個軟件。 詳細設計應當足夠詳細， 能夠根據(jù)詳細設計報告進行編碼。 特例如果軟件系統(tǒng)比較簡單， 層次較少， 可以不必進行專門的詳細設計， 而和概要設計結(jié)合起來。 詳細設計的要求a．一致性詳細設計的要求應該與需求分析報告所描述的需求、 與概要設計一致。 同時，詳細設計的各項要求之間也應該是一致的。b．合理性詳細設計所提出的設計方法和標準應該是合理的、恰當?shù)摹．可追蹤性對詳細設計所提出的各項要求應該可以得到它的清晰的源流， 即可在需求分析報告、 概要設計報告中有明確的需求描述。d．可行性根據(jù)詳細設計進行編碼、測試、操作和維護應該是可行的。 數(shù)據(jù)庫設計如果軟件產(chǎn)品需要使用到數(shù)據(jù)庫， 軟件的詳細設計應包括對數(shù)據(jù)庫的設計。 數(shù)據(jù)庫設計應在軟件的需求分析、 概要設計完成之后、 詳細設計的其它工作之前進行。 在進行數(shù)據(jù)庫設計時，應當按照交通局制定的《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》要求進行。 詳細設計的評審在軟件詳細設計完成后， 軟件開發(fā)者應向交通局提交 《軟件系統(tǒng)數(shù)據(jù)庫設計報告》 和《軟件系統(tǒng)詳細設計報告》 。在交通局對 《軟件系統(tǒng)數(shù)據(jù)庫設計報告》 、《軟件系統(tǒng)詳細設計報告》評審通過后，即可進入軟件編碼階段。 詳細設計格式《軟件系統(tǒng)詳細設計報告》 、《軟件系統(tǒng)數(shù)據(jù)庫設計報告》需按一定的格式進行編寫，具體的《軟件系統(tǒng)詳細設計報告》文檔編寫模板和 《軟件系統(tǒng)數(shù)據(jù)庫設計報告》文檔編寫模板請見附錄 C、附錄 D。3.4 軟件的編碼 軟件編碼在軟件編碼階段，開發(fā)者根據(jù)《軟件系統(tǒng)詳細設計報告》 中對數(shù)據(jù)結(jié)構(gòu)、算法分析和模塊實現(xiàn)等方面的設計要求， 開始具體的編寫程序工作， 分別實現(xiàn)各模塊的功能， 從而實現(xiàn)對目標系統(tǒng)的功能、性能、接口、界面等方面的要求。 軟件編碼的要求a．模塊化編碼b．代碼可讀性5c．可維護性d．模塊接口標準化e．界面風格統(tǒng)一e．注釋的應用 編碼的評審為了盡早發(fā)現(xiàn)軟件中的障礙， 提高軟件產(chǎn)品的質(zhì)量， 開發(fā)者在編碼的過程中應該強調(diào)代碼評審工作。將代碼評審報告作為文檔的一部分，提交給交通局。 編程規(guī)范及要求為了提高編程實現(xiàn)的質(zhì)量，軟件的程序設計必須遵照國家頒布的相關(guān)編程規(guī)范。主要內(nèi)容包括： 規(guī)范化的程序內(nèi)部文檔、 數(shù)據(jù)結(jié)構(gòu)的詳細說明、清晰的語句結(jié)構(gòu)、 編碼規(guī)范。編碼規(guī)范的內(nèi)容包括命名規(guī)范、界面規(guī)范、提示及幫助信息規(guī)范、熱鍵定義等。其中數(shù)據(jù)庫部分應遵守《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》的要求。在軟件編碼的同時應進行單元測試。3.5 軟件的測試 軟件測試為了盡早發(fā)現(xiàn)軟件產(chǎn)品中的錯誤， 從而達到提高軟件質(zhì)量、 降低軟件維護的費用， 開發(fā)者應在編碼過程中對各個模塊的程序代碼進行單元測試， 系統(tǒng)集成時進行集成測試， 系統(tǒng)集成完成后對整個軟件進行系統(tǒng)測試。 單元測試是在軟件開發(fā)過程中針對程序模塊進行正確性檢驗。集成測試是在單元測試的基礎上， 將所有模塊按照設計要求組裝成系統(tǒng)或子系統(tǒng)， 對模塊組裝過程和模塊接口進行正確性檢驗。軟件系統(tǒng)測試不僅是檢測軟件的整體行為表現(xiàn)，從另一個側(cè)面看，也是對軟件開發(fā)設計的再確認。進行軟件系統(tǒng)測試工作時。 測試主要包括界面測試、可用性測試、功能測試、穩(wěn)定性 (強度)測試、性能測試、強壯性 (恢復)測試、邏輯性測試、破壞性測試、安全性測試等。開發(fā)者針對單元測試，集成測試，系統(tǒng)測試分別制定《測試計劃》 。集成測試需要根據(jù)需求分析報告和概要設計制作測試用例， 并須經(jīng)過評審。 軟件測試按照 《測試計劃》 、《需求分析報告》的要求進行，最后形成《軟件測試報告》 。 測試計劃在軟件編碼開始之前，開發(fā)者應向交通局提交《測試計劃》 ，在軟件交付時，開發(fā)者應向交通局提交《軟件測試報告》 ，以確保開發(fā)者的軟件得到了充分的測試。開發(fā)的軟件必須經(jīng)過充分的測試證明其符合設計要求、運行穩(wěn)定、安全可用方可交付交通局。3.6 軟件的交付準備 交付清單在軟件測試證明軟件達到要求后， 軟件開發(fā)者應向交通局提交開發(fā)的目標安裝程序、 數(shù)據(jù)庫的數(shù)據(jù)字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等雙方合同約定的產(chǎn)物?！队脩舭惭b手冊》 應詳細介紹安裝軟件對運行環(huán)境的要求、 安裝軟件的定義和內(nèi)容、 在客戶端、服務器端及中間件的具體安裝步驟、安裝后的系統(tǒng)配置?！队脩羰褂弥改稀窇ㄜ浖黜椆δ艿氖褂昧鞒?、操作步驟、相應業(yè)務介紹、特殊提示和注意事項等方面的內(nèi)容，在需要時還應舉例說明。63.7 軟件的鑒定驗收 軟件的鑒定驗收在軟件開發(fā)完成后， 為了確保軟件是按照需求分析的要求進行開發(fā)的， 保證軟件產(chǎn)品的質(zhì)量，需要對軟件產(chǎn)品進行鑒定驗收。 在開發(fā)者如期交付軟件后， 由交通局負責確定具體的鑒定驗收日期。 驗收人員由交通局聘請具有一定的分析、 設計、編程和軟件測試經(jīng)驗的驗收組長和其他專業(yè)人員組成。驗收組設組長一名 (可設有副組長 )，負責整個驗收的計劃、組織工作。 驗收具體內(nèi)容驗收內(nèi)容應該包括： 合法性檢查、文檔檢查、 軟件一致性檢查、軟件系統(tǒng)測試與測試結(jié)果評審等幾項工作。合法性檢查檢查軟件開發(fā)工具是否合法、 使用的函數(shù)庫、 控件、組件是否有合法的發(fā)布許可。文檔檢查檢查開發(fā)者提交的文檔必須齊全， 質(zhì)量是否過關(guān)。 需要開發(fā)者提供的文檔包括：項目實施計劃；詳細技術(shù)方案；軟件需求規(guī)格說明書 (STP)(含數(shù)據(jù)字典 )；概要設計說明書 (PDD)；詳細設計說明書 (DDD)(含數(shù)據(jù)庫設計說明書 )；軟件測試計劃 (STP)(含測試用例 )；軟件測試報告 (STR)；用戶手冊 (SUM)(含操作、使用、維護、應急處理手冊 )；源程序(SCL)(不可修改的電子文檔 )；項目實施計劃 (PIP)；項目開發(fā)總結(jié) (PDS)；軟件質(zhì)量保證計劃 (SQAP)；此外，驗收組可以根據(jù)需要對其它文檔 (如軟件配置計劃、項目進展報表、階段評審報表等)進行檢查。文檔的質(zhì)量根據(jù)完備性、正確性、簡明性、可追蹤性、自說明性、規(guī)范件等方面進行蹤合評定。驗收需要對軟件代碼進行檢查，以確保其符合規(guī)范，并檢查其一致性。 軟件驗收測試大綱在軟件進行鑒定驗收前，開發(fā)者需按照一定的格式編寫《軟件驗收測試大綱》 ，具體的格式請見附錄 E。3.8 培訓 系統(tǒng)應用培訓主要培訓內(nèi)容包括：系統(tǒng)操作使用、業(yè)務管理流程。培訓對象：應用操作人員。7 系統(tǒng)管理的培訓（可選）主要培訓內(nèi)容包括：系統(tǒng)安裝、調(diào)試、維護；系統(tǒng)管理。培訓對象：系統(tǒng)管理人員。開發(fā)者應詳細列出培訓計劃，包括培訓內(nèi)容、教材、時間和人員等。8附錄A軟件需求分析報告文檔模板1.引言...........................................................................................................................................111.1編寫目的............................................................................................................................111.2項目風險............................................................................................................................111.3文檔約定............................................................................................................................111.4預期讀者和閱讀建議111.5產(chǎn)品范圍............................................................................................................................121.6參考文獻............................................................................................................................122.綜合描述...................................................................................................................................122.1產(chǎn)品的狀況........................................................................................................................122.2產(chǎn)品的功能........................................................................................................................132.3用戶類和特性....................................................................................................................132.4運行環(huán)境............................................................................................................................132.5設計和實現(xiàn)上的限制132.6假設和約束(依賴)..............................................................................................................143.外部接口需求...........................................................................................................................143.1用戶界面............................................................................................................................143.2硬件接口............................................................................................................................153.3軟件接口............................................................................................................................153.4通訊接口............................................................................................................................164.系統(tǒng)功能需求...........................................................................................................................164.1說明和優(yōu)先級....................................................................................................................164.2激勵／響應序列................................................................................................................174.3輸入／輸出數(shù)據(jù)................................................................................................................175.其它非功能需求.......................................................................................................................175.1性能需求............................................................................................................................175.2安全措施需求....................................................................................................................185.3安全性需求........................................................................................................................185.4軟件質(zhì)量屬性....................................................................................................................185.5業(yè)務規(guī)則............................................................................................................................185.6用戶文檔............................................................................................................................186.詞匯表.......................................................................................................................................197.數(shù)據(jù)定義...................................................................................................................................198.分析模型...................................................................................................................................209.待定問題列表...........................................................................................................................20910引言引言是對這份軟件產(chǎn)品需求分析報告的概覽， 是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔。1.1 編寫目的說明這份軟件產(chǎn)品需求分析報告是為哪個軟件產(chǎn)品編寫的， 開發(fā)這個軟件產(chǎn)品意義、 作用、以及最終要達到的意圖。 通過這份軟件產(chǎn)品需求分析報告詳盡說明了該軟件產(chǎn)品的需求規(guī)格，包括修正和 (或)發(fā)行版本號，從而對該軟件產(chǎn)品進行準確的定義。如果這份軟件產(chǎn)品需求分析報告只與整個系統(tǒng)的某一部分有關(guān)系， 那么只定義軟件產(chǎn)品需求分析報告中說明的那個部分或子系統(tǒng)。1.2 項目風險具體說明本軟件開發(fā)項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：● 任務提出者；● 軟件開發(fā)者；● 產(chǎn)品使用者。1.3 文檔約定描述編寫文檔時所采用的標準 (如果有標準的話 )，或者各種排版約定。排版約定應該包括：● 正文風格；● 提示方式；● 重要符號；也應該說明高層次需求是否可以被其所有細化的需求所繼承， 或者每個需求陳述是否都有其自己的優(yōu)先級。1.4 預期讀者和閱讀建議列舉本軟件產(chǎn)品需求分析報告所針對的各種不同的預期讀者，例如，可能包括：● 用戶；● 開發(fā)人員；● 項目經(jīng)理；● 營銷人員；● 測試人員；● 文檔編寫入員。并且描述了文檔中， 其余部分的內(nèi)容及其組織結(jié)構(gòu)， 并且針對每一類讀者提出最適合的11文檔閱讀建議。1.5 產(chǎn)品范圍說明該軟件產(chǎn)品及其開發(fā)目的的簡短描述， 包括利益和目標。 把軟件產(chǎn)品開發(fā)與企業(yè)目標，或者業(yè)務策略相聯(lián)系。描述產(chǎn)品范圍時需注意， 可以參考項目視圖和范圍文檔， 但是不能將其內(nèi)容復制到這里。1.6 參考文獻列舉編寫軟件產(chǎn)品需求分析報告時所用到的參考文獻及資料，可能包括：● 本項目的合同書；● 上級機關(guān)有關(guān)本項目的批文；● 本項目已經(jīng)批準的計劃任務書；● 用戶界面風格指導；● 開發(fā)本項目時所要用到的標淮；● 系統(tǒng)規(guī)格需求說明；● 使用實例文檔；● 屬于本項目的其它己發(fā)表文件；● 本軟件產(chǎn)品需求分析報告中所引用的文件、資料；● 相關(guān)軟件產(chǎn)品需求分析報告；為了方便讀者查閱， 所有參考資料應該按一定順序排列。 如果可能， 每份資料都應該給出：● 標題名稱；● 作者或者合同簽約者；● 文件編號或者版本號；● 發(fā)表日期或者簽約日期；● 出版單位或者資料來源。綜合描述這一部分概述了正在定義的軟件產(chǎn)品的作用范圍以及該軟件產(chǎn)品所運行的環(huán)境、 使用該軟件產(chǎn)品的用戶、對該軟件產(chǎn)品己知的限制、有關(guān)該軟件產(chǎn)品的假設和依賴。2.1 產(chǎn)品的狀況描述了在軟件產(chǎn)品需求分析報告中所定義的軟件產(chǎn)品的背景和起源。 說明了該軟件產(chǎn)品是否屬于下列情況：● 是否是產(chǎn)品系列中的下一成員；● 是否是成熟產(chǎn)品所改進的下一代產(chǎn)品；● 是否是現(xiàn)有應用軟件的替代品 (升級產(chǎn)品 )；● 是否是一個新型的、自主型的產(chǎn)品。12如果該軟件產(chǎn)品需求分析報告定義的軟件系統(tǒng)是：● 大系統(tǒng)的一個組成部分；● 與其它系統(tǒng)和其它機構(gòu)之間存在基本的相互關(guān)系。那么必須說明軟件產(chǎn)品需求分析報告定義的這部分軟件是怎樣與整個大系統(tǒng)相關(guān)聯(lián)的，或者（同時）說明相互關(guān)系的存在形式，并且要定義出兩者之間的全部接口。2.2 產(chǎn)品的功能因為將在需求分析報告的第 4部分中詳細描述軟件產(chǎn)品的功能， 所以在此只需要概略地總結(jié)。僅從業(yè)務層面陳述本軟件產(chǎn)品所應具有的主要功能， 在描述功能時應該針對每一項需求準確地描述其各項規(guī)格說明。 如果存在引起誤解的可能， 在陳述本軟件產(chǎn)品主要功能的作用領(lǐng)域時，也需要對應陳述本軟件產(chǎn)品的非作用領(lǐng)域，以利讀者理解本軟件產(chǎn)品。為了很好地組織產(chǎn)品功能， 使每個讀者都容易理解， 可以采用列表的方法給出。 也可以采用圖形方式，將主要的需求分組以及它們之間的聯(lián)系使用數(shù)據(jù)流程圖的頂層圖或類圖進行表示，這種表示方法是很有用的。參考用戶當前管理組織構(gòu)架， 了解各個機構(gòu)的主要職能， 將有助于陳述軟件產(chǎn)品的主要功能。2.3 用戶類和特性確定有可能使用該軟件產(chǎn)品的不同用戶類， 并且描述它們相關(guān)的特征。 往往有一些軟件需求，只與特定的用戶類有關(guān)。 描述時，應該將該軟件產(chǎn)品的重要用戶類與非重要用戶類區(qū)分開。用戶不一定是軟件產(chǎn)品的直接使用者， 通過報表、 應用程序接口、 系統(tǒng)硬件接口得到軟件產(chǎn)品的數(shù)據(jù)和服務的人、 或者機構(gòu)也有他們的需求。 所以，應該將這些外部需求視為通過報表、應用程序接口、系統(tǒng)硬件接口附加給軟件產(chǎn)品的附加用戶類。2.4 運行環(huán)境描述了本軟件的運行環(huán)境，一般包括：● 硬件平臺；● 操作系統(tǒng)和版本；● 支撐環(huán)境 (例如：數(shù)據(jù)庫等 )和版本；● 其它與該軟件有關(guān)的軟件組件；● 與該軟件共存的應用程序。2.5 設計和實現(xiàn)上的限制確定影響開發(fā)人員自由選擇的問題， 并且說明這些問題為什么成為一種限制。 可能的限制包括下列內(nèi)容：● 必須使用的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫；● 避免使用的特定技術(shù)、工具、編程語言和數(shù)據(jù)庫；● 要求遵循的開發(fā)規(guī)范和標準13例如，如果由客戶的公司或者第三方公司負責軟件維護， 就必須定義轉(zhuǎn)包者所使用的設計符號表示和編碼標準；● 企業(yè)策略的限制；● 政府法規(guī)的限制；● 工業(yè)標準的限制；● 硬件的限制例如，定時需求或存儲器限制；● 數(shù)據(jù)轉(zhuǎn)換格式標淮的限制。2.6 假設和約束 (依賴)列舉出對軟件產(chǎn)品需求分析報告中，影響需求陳述的假設因素 (與己知因素相對立 )。如果這些假設因素不正確、 不一致或者被修改， 就會使軟件產(chǎn)品開發(fā)項目受到影響。 這些假設的因素可能包括：● 計劃使用的商業(yè)組件，或者其它軟件中的某個部件；● 假定產(chǎn)品中某個用戶界面將符合一個特殊的設計約定；● 有關(guān)本軟件用戶的若干假定 (例如：假定用戶會熟練使用 SQL語言。 )；● 有關(guān)本軟件開發(fā)工作的若干假定 (例如：用戶承諾的優(yōu)惠、 方便、上級部門給予的特殊政策和支持等。 )；● 有關(guān)本軟件運行環(huán)境的一些問題；此外，確定本軟件開發(fā)項目對外部約束因素所存在的依賴。有關(guān)的約束可能包括：● 工期約束；● 經(jīng)費約束；● 人員約束；● 設備約束；● 地理位置約束；● 其它有關(guān)項目約束；外部接口需求通過本節(jié)描述可以確定， 保證軟件產(chǎn)品能和外部組件正確連接的需求。 關(guān)聯(lián)圖僅能表示高層抽象的外部接口， 必須對接口數(shù)據(jù)和外部組件進行詳細描述， 并且寫入數(shù)據(jù)定義中。 如果產(chǎn)品的不同部分有不同的外部接口， 那么應該把這些外部接口的全部詳細需求并入到這一部分實例中。注意：必須將附加用戶類的特征與外部接口需求加以區(qū)分， 附加用戶類的特征描述的是通過接口取得軟件產(chǎn)品的數(shù)據(jù)和服務的人的需求；而外部接口需求描述的是接口本身的需求。3.1 用戶界面陳述需要使用在用戶界面上的軟件組件，描述每一個用戶界面的邏輯特征。必須注意，這里需要描述的是用戶界面的邏輯特征，而不是用戶界面。以下是可能包括的一些特征：14● 將要采用的圖形用戶界面 (GUl)標準或者產(chǎn)品系列的風格；● 有關(guān)屏幕布局或者解決方案的限制；● 將要使用在每一個屏幕 (圖形用戶界面 )上的軟件組件，可能包括：選單；標準按鈕；導航鏈接；各種功能組件；消息欄；● 快捷鍵；● 各種顯示格式的規(guī)定，可能包括：不同情況下文字的對齊方式；不同情況下數(shù)字的表現(xiàn)格式與對齊方式日期的表現(xiàn)方法與格式；計時方法與時間格式；等等?！?錯誤信息顯示標準；對于用戶界面的細節(jié)， 例如：一個特定對話框的布局， 應該寫入具體的用戶界面設計說明中，而不能寫入軟件需求規(guī)格說明中。如果采用現(xiàn)成的、合適的用戶界面設計規(guī)范 (標準)，或者另文描述，可以在這里直接說明，并且將其加入?yún)⒖嘉墨I。3.2 硬件接口描述待開發(fā)的軟件產(chǎn)品與系統(tǒng)硬件接口的特征，若有多個硬件接口，則必須全都描述。接口特征的描述內(nèi)容可能包括：● 支持的硬件類型；● 軟、硬件之間交流的數(shù)據(jù)；● 控制信息的性質(zhì)；● 使用的通訊協(xié)議；3.3 軟件接口描述該軟件產(chǎn)品與其它外部組件的連接， 這些外部組件必須明確它們的名稱和版本號以資識別，可能的外部組件包括：● 操作系統(tǒng)；● 數(shù)據(jù)庫；● 工具；● 函數(shù)庫；● 集成的商業(yè)組件說明：這里所說的“集成的商業(yè)組件” ，是指與系統(tǒng)集成的商業(yè)組件，而不是與軟件產(chǎn)品集成的商業(yè)組件。例如：中間件、消息服務，等等。描述并且明確軟件產(chǎn)品與軟件組件之間交換數(shù)據(jù)或者消息的目的。描述所需要的服務，以及與內(nèi)部組件通訊的性質(zhì)。 確定軟件產(chǎn)品將與組件之間共享的數(shù)據(jù)。 如果必須使用一種特殊的方法來實現(xiàn)數(shù)據(jù)共享機制， 例如：在多用戶系統(tǒng)中的一個全局數(shù)據(jù)區(qū)， 那么就必須把它15定義為一種實現(xiàn)上的限制。3.4 通訊接口描述與軟件產(chǎn)品所使用的通訊功能相關(guān)的需求，包括：● 電子郵件；WEB瀏覽器；網(wǎng)絡通訊標準或者協(xié)議；數(shù)據(jù)交互用電子表格；必須定義相關(guān)的：● 消息格式；● 通訊安全或加密問題；● 數(shù)據(jù)傳輸速率；● 同步和異步通訊機制；系統(tǒng)功能需求需要進行詳細的需求記錄， 詳細列出與該系統(tǒng)功能相關(guān)的詳細功能需求， 并且，唯一地標識每一項需求。 這是必須提交給用戶的軟件功能， 使得用戶可以使用所提供的功能執(zhí)行服務或者使用所指定的使用實例執(zhí)行任務。 描述軟件產(chǎn)品如何響應己知的出錯條件、 非法輸入、非法動作。如果每一項功能需求都能用一項， 也只需要用一項測試用例就能進行驗證， 那么就可以認為功能需求已經(jīng)適當?shù)剡M行描述了。 如果某項功能需求找不到合適的測試用例， 或者必須使用多項測試用例才能驗證，那么該項功能需求的描述必然存在某些問題。功能需求是根據(jù)系統(tǒng)功能， 即軟件產(chǎn)品所提供的主要服務來組織的。 可以通過使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內(nèi)容，也可以便用這些元素的組合?？偠灾仨氝x擇一種是讀者容易理解預期產(chǎn)品的組織方案。用簡短的語句說明功能的名稱，例如： “4.1系統(tǒng)參數(shù)管理” 。按照服務組織的順序，逐條闡述系統(tǒng)功能。 無論說明的是何種功能， 都應該針對該系統(tǒng)功能重復敘述 4.1~4.3 這三個部分?？梢酝ㄟ^各種方式來組織這一部分內(nèi)容，例如采用：使用實例、運行模式、用戶類、對象類、功能等級等， 也可以采用它們的組合。 其最終目的是， 讓讀者容易理解即將開發(fā)的軟件產(chǎn)品。一般來說， 每個使用實例都對應一個系統(tǒng)功能， 因而按照使用實例來組織內(nèi)容比較容易讓用戶理解。對應一些被共享的獨立使用實例，可以定義一些公用系統(tǒng)功能。必須特別注意的是， 在2.2節(jié)“產(chǎn)品的功能” 中描述的全部需求， 以及它們的規(guī)格說明；必須在某個系統(tǒng)功能描述中有所反映，而且不應重復。4.1 說明和優(yōu)先級對該系統(tǒng)功能進行簡短的說明，并且指出該系統(tǒng)功能的優(yōu)先級是：高、中、還是低。需要的話，還可以包括對特定優(yōu)先級部分的評價，例如：利益、損失、費用和風險，其相對優(yōu)16先等級可以從 1(低)到9(高)。4.2 激勵／響應序列列出輸入激勵 (用戶動作、 來自外部設備的信號或者其它觸發(fā) )并且定義針對這——功能行為的系統(tǒng)響應序列，這些序列將與使用實例中相關(guān)的對話元素相對應。描述激勵／響應序列時，不僅需要描述基本過程，而且應該描述可選 (擴充)過程，包括例外(引起任務不能順序完成的情況稱為例外 )。疏忽了可選過程，有可能影響軟件產(chǎn)品的功能；如果遺漏例外過程，則有可能會引發(fā)系統(tǒng)崩潰。如果采用流程圖來描述激勵／響應序列，比較容易讓用戶理解。4.3 輸入／輸出數(shù)據(jù)列出輸入數(shù)據(jù) (用戶輸入、 來自外部接口的輸入或者其它輸入 )并且定義針對這些輸入數(shù)據(jù)的處理 (計算)方法，以及相應地輸出數(shù)據(jù)，描述對應區(qū)別：輸入數(shù)據(jù)和輸出數(shù)據(jù)。當有大量數(shù)據(jù)需要描述時， 也可以分類描述數(shù)據(jù)， 并且注明各項數(shù)據(jù)的輸入、 輸出屬性。對于每一項數(shù)據(jù)，均需要描述：● 數(shù)據(jù)名稱；● 實際含義；● 數(shù)據(jù)類型；● 數(shù)據(jù)格式；● 數(shù)據(jù)約束；對于復雜的處理方法， 僅僅給出算法原理是不夠的， 必須描述詳細的計算過程， 并且列出每一步具體使用的實際算式； 如果計算過程中涉及查表、判斷、 迭代等處理方法，應該給出處理依據(jù)和相關(guān)數(shù)據(jù)。如果計算方法很簡單，也可以將其從略，不加描述。其它非功能需求在這里列舉出所有非功能需求，主要包括可靠性、安全性、可維護性、可擴展性、可測試性等。5.1 性能需求闡述不同應用領(lǐng)域?qū)浖a(chǎn)品性能的需求， 并且說明提出需求的原理或者依據(jù)， 以幫助開發(fā)人員做出合理的設計選擇。 盡可能詳細地描述性能需求， 如果需要， 可以針對每個功能需求或者特征分別陳述其性能需求。在這里確定：● 相互合作的用戶數(shù)量；● 系統(tǒng)支持的并發(fā)操作數(shù)量；● 響應時間；● 與實時系統(tǒng)的時間關(guān)系：● 容量需求存儲器；17磁盤空間；數(shù)據(jù)庫中表的最大行數(shù)。5.2 安全措施需求詳盡陳述與軟件產(chǎn)品使用過程中可能發(fā)生的損失、 破壞、危害相關(guān)的需求。 定義必須采取的安全保護或動作，以及必須預防的潛在危險動作。明確軟件產(chǎn)品必須遵從的安全標準、策略、或規(guī)則。5.3 安全性需求詳盡陳述與系統(tǒng)安全性、 完整性問題相關(guān)的需求， 或者與個人隱私問題相關(guān)的需求。 這些問題將會影響到軟件產(chǎn)品的使用， 和軟件產(chǎn)品所創(chuàng)建或者使用的數(shù)據(jù)的保護。 定義用戶身份認證，或備授權(quán)需求。 明確軟件產(chǎn)品必須滿足的安全性或者保密性策略。 也可以通過稱為完整性的質(zhì)量屬性來闡述這些需求。一個典型的軟件系統(tǒng)安全需求范例如下： “每個用戶在第一次登錄后，必須更改他的系統(tǒng)預置登錄密碼，系統(tǒng)預置的登錄密碼不能重用。 ”5.4 軟件質(zhì)量屬性詳盡陳述對客戶和開發(fā)人員至關(guān)重要的在軟件產(chǎn)品其它方面表現(xiàn)出來的質(zhì)量功能。 這些功能必須是確定的、 定量的、 在需要時是可以驗證的。 至少也應該指明不同屬性的相對側(cè)重點，例如：易用性優(yōu)于易學性，或者可移植性優(yōu)于有效性。5.5 業(yè)務規(guī)則列舉出有關(guān)軟件產(chǎn)品的所有操作規(guī)則，例如：那些人在特定環(huán)境下可以進行何種操作。這些本身不是功能需求， 但是他們可以暗示某些功能需求執(zhí)行這些規(guī)則。 一個業(yè)務規(guī)則的范例如下：“進行達到或者超過 10，000，00元人民幣的儲蓄業(yè)務時，必須通過附加的管理員認證。”列舉業(yè)務規(guī)則時，可以根據(jù)規(guī)則的數(shù)量，選取合適的編目方式。5.6 用戶文檔列舉出將與軟件產(chǎn)品一同交付的用戶文檔， 并且明確所有己知用戶文檔的交付格式或標準，例如：● 安裝指南紙質(zhì)文檔， 16開本；● 用戶手冊紙質(zhì)文檔， 16開本；● 在線幫助● 電子文檔，與軟件產(chǎn)品一同分發(fā)、配置；● 使用教程電子文檔，與軟件產(chǎn)品一同分發(fā)、配置。18詞匯表列出本文件中用到的專業(yè)術(shù)語的定義，以及有關(guān)縮寫的定義 (如有可能，列出相關(guān)的外文原詞)。為了便于非軟件專業(yè)或者非計算機專業(yè)人士閱讀軟件產(chǎn)品需求分析報告，要求使用非軟件專業(yè)或者非計算機專業(yè)的術(shù)語描述軟件需求。 所以這里所指的專業(yè)術(shù)語， 是指業(yè)務層面上的專業(yè)術(shù)語， 而不是軟件專業(yè)或者計算機專業(yè)的術(shù)語。 但是，對于無法回避的軟件專業(yè)或者計算機專業(yè)術(shù)語，也應該列入詞匯表并且加以準確定義。數(shù)據(jù)定義數(shù)據(jù)定義是一個定義了應用程序中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的共享文檔， 其中對每個數(shù)據(jù)元素和結(jié)構(gòu)都準確描述： 含義、類型、數(shù)據(jù)大小、 格式、計量單位、 精度以及取值范圍。數(shù)據(jù)定義的維護獨立于軟件需求規(guī)格說明， 并且在軟件產(chǎn)品開發(fā)和維護的任何階段， 均向風險承擔者開放。如果為軟件開發(fā)項目創(chuàng)建一個獨立的數(shù)據(jù)定義，而不是為每一項特性描述有關(guān)的數(shù)據(jù)項，有利于避免冗余和不一致性。 但是卻不利于多人協(xié)同編寫需求分析報告， 容易遺漏數(shù)據(jù)，也不方便閱讀。 因此還是建議為每個特性描述有關(guān)的數(shù)據(jù)項， 匯總數(shù)據(jù)項創(chuàng)建數(shù)據(jù)定義， 再根據(jù)數(shù)據(jù)定義復核全部數(shù)據(jù)， 使得它們的名稱和含義完全一致。 必須注意的是， 為了避免二義性，在匯總數(shù)據(jù)項時應該根據(jù)數(shù)據(jù)項所代表的實際意義匯總， 而不是根據(jù)數(shù)據(jù)項的名稱匯總。在數(shù)據(jù)定義中， 每個數(shù)據(jù)項除了有一個中文名稱外， 還應該為它取一個簡短的英文名稱，該英文名稱應該符合命名規(guī)范， 因為在軟件開發(fā)時將沿用該英文名稱。 可以使用等號表示數(shù)據(jù)項，名稱寫在左邊，定義寫在右邊。常見數(shù)據(jù)項的描述方式如下：● 原數(shù)據(jù)元素一個原數(shù)據(jù)元素是不可分解的， 可以將一個數(shù)量值賦給它。 定義原數(shù)據(jù)元素必須確定其含義、類型、數(shù)據(jù)大小、格式、計量單位、精度以及取值范圍。采用以星號為界的一行注釋文本，描述原數(shù)據(jù)元素的定義?！?選擇項選擇項是一種只可以取有限離散值的特殊原數(shù)據(jù)元素， 描述時一一枚舉這些值， 并用方括號括起來寫在原數(shù)據(jù)元素的定義前。在兩項離散值之間，使用管道符分隔。● 組合項組合項是一個數(shù)據(jù)結(jié)構(gòu)或者記錄， 其中包含了多個數(shù)據(jù)項。 這些數(shù)據(jù)項可以是原數(shù)據(jù)元素，也可以是組合數(shù)據(jù)項， 各數(shù)據(jù)項之間用加號連接。 其中每個數(shù)據(jù)項都必須是數(shù)據(jù)定義中定義過的， 結(jié)構(gòu)中也可以包括其它結(jié)構(gòu)， 但是絕對不允許遞歸。 如果數(shù)據(jù)結(jié)構(gòu)中有可選項，使用圓括號把該項括起來。● 重復項重復項是組合項的一種特例， 其中有一項將有多個實例出現(xiàn)在數(shù)據(jù)結(jié)構(gòu)中， 使用花括號把該項括起來。如果知道該項可能允許的范圍，就按“最小值：最大值”的形式寫在花括號前。19分析模型這是一個可選部分，包括或涉及到相關(guān)的分析模型，例如：● 數(shù)據(jù)流程圖；● 類圖；● 狀態(tài)轉(zhuǎn)換圖；● 實體-關(guān)系圖。待定問題列表編輯一張在軟件產(chǎn)品需求分析報告中待確定問題時的列表， 把每一個表項都編上號， 以便跟蹤調(diào)查。20附錄 B軟件概要設計報告文檔模板1.引言...........................................................................................................................................231.1編寫目的.............................................................................................................................231.2項目風險.............................................................................................................................231.3預期讀者和閱讀建議.........................................................................................................231.4參考資料.............................................................................................................................232.設計概述...................................................................................................................................242.1限制和約束.........................................................................................................................242.2設計原則和設計要求.........................................................................................................243.系統(tǒng)邏輯設計...........................................................................................................................253.1系統(tǒng)組織設計.....................................................................................................................253.2系統(tǒng)結(jié)構(gòu)設計.....................................................................................................................253.2.1系統(tǒng)特性表..................................................................................................................263.2.2系統(tǒng)特性結(jié)構(gòu)圖..........................................................................................................273.3系統(tǒng)接口設計.....................................................................................................................273.3.1系統(tǒng)接口表..................................................................................................................273.3.2系統(tǒng)接口傳輸協(xié)議說明..............................................................................................283.4系統(tǒng)完整性設計.................................................................................................................284.系統(tǒng)出錯處理設計...................................................................................................................294.1系統(tǒng)出錯處理表.................................................................................................................294.2維護處理過程表.................................................................................................................305.技術(shù)設計...................................................................................................................................315.1系統(tǒng)開發(fā)技術(shù)說明表.........................................................................................................315.2開發(fā)技術(shù)應用說明.............................................................................................................326.數(shù)據(jù)庫設計...............................................................................................................................327.詞匯表.......................................................................................................................................328.進度計劃...................................................................................................................................322122引言引言是對這份軟件系統(tǒng)概要設計報告的概覽， 是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔。1.1 編寫目的說明這份軟件系統(tǒng)概要設計報告是基于哪份軟件產(chǎn)品需求規(guī)格說明書編寫的， 開發(fā)這個軟件產(chǎn)品意義、 作用、以及最終要達到的意圖。 通過這份軟件系統(tǒng)概要設計報告詳盡說明了該軟件產(chǎn)品的軟件結(jié)構(gòu)，包括數(shù)據(jù)庫結(jié)構(gòu)和出錯處理，從而對該軟件產(chǎn)品的結(jié)構(gòu)的描述。如果這份軟件系統(tǒng)概要設計報告只與整個系統(tǒng)的某一部分有關(guān)系， 那么只定義軟件系統(tǒng)概要設計報告中說明的那個部分或子系統(tǒng)。1.2 項目風險具體說明本軟件開發(fā)項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：● 任務提出者；● 軟件開發(fā)者；● 產(chǎn)品使用者。1.3 預期讀者和閱讀建議列舉本軟件系統(tǒng)概要設計報告所針對的各種不同的預期讀者，例如，可能的讀者包括：● 用戶；● 開發(fā)人員；● 項目經(jīng)理；● 營銷人員；● 測試人員；● 文檔編寫人員；● 等等。描述文檔中， 其余部分的內(nèi)容及其組織結(jié)構(gòu)， 并且針對每一類讀者提出最適合的文檔閱讀建議。1.4 參考資料列舉編寫軟件產(chǎn)品概要設計報告時所用到的參考文獻及資料，可能包括：● 本項目的合同書；● 上級機關(guān)有關(guān)本項目的批文；● 本項目已經(jīng)批準的計劃任務書；● 用戶界面風格指導；23●開發(fā)本項目時所要用到的標準；●系統(tǒng)規(guī)格需求說明；●使用實例文檔；●屬于本項目的其它已發(fā)表文件；●本軟件系統(tǒng)概要設計報告中所引用的文件、資料：●相關(guān)軟件系統(tǒng)概要設計報告：●等等。為了方便讀者查閱，所有參考資料應該按一定順排列。如果可能，每份資料都應該給出：●標題名稱；●作者或者合同簽約者；●文件編號或者版本號；●發(fā)表日期或者簽約日期；●出版單位或者資料來源。設計概述本節(jié)描述現(xiàn)有開發(fā)條件和需要實現(xiàn)的目標， 說明進行概要設計時應該遵循的設計原則和必須采用的設計方法。2.1 限制和約束簡要描述起到限制和約束作用的各種可能存在的條件，例如：● 技術(shù)條件；● 資金狀況；● 開發(fā)環(huán)境 (包括：工具和平臺 )；● 時間限制；● 等等。并且說明在上述條件下，應該實現(xiàn)的系統(tǒng)目標，2.2 設計原則和設計要求描述對本軟件系統(tǒng)進行概要設計的原則，通?？梢钥紤]以下幾方面的內(nèi)容：● 命名規(guī)則；● 模塊獨立性原則：● 邊界設計原則；● 數(shù)據(jù)庫設計規(guī)則；● 必須的安全措施；● 安全性和保密原則；● 系統(tǒng)靈活性要求；● 系統(tǒng)易操作性要求；● 系統(tǒng)可維護性要求；● 等等。24系統(tǒng)邏輯設計本節(jié)內(nèi)容主要根據(jù)軟件產(chǎn)品需求規(guī)格說明書和軟件產(chǎn)品數(shù)據(jù)字典建立系統(tǒng)的邏輯模型。此種模型暫時與系統(tǒng)的物理因素 (例如：計算機、數(shù)據(jù)庫管理系統(tǒng) )無關(guān)。它是系統(tǒng)需求與物理實現(xiàn)的中間結(jié)構(gòu)，