軟件需求分析報(bào)告(模板).doc

_ 精品資料 軟軟件需求分析件需求分析報(bào)報(bào)告告-（模板）（模板） 目目錄錄 1. 范范圍圍.1 2. 總總體要求體要求 .1 2.1 總體功能要求.1 2.2 軟件開發(fā)平臺要求.1 2.3 軟件項(xiàng)目的開發(fā)實(shí)施過程管理要求.2 2.3.1 軟件項(xiàng)目實(shí)施過程總體要求.2 2.3.2 軟件項(xiàng)目實(shí)施變更要求.2 2.3.3 軟件項(xiàng)目實(shí)施里程碑控制.2 3. 軟軟件開件開發(fā)發(fā) .3 3.1 軟件的需求分析.3 3.1.1 需求分析.3 3.1.2 需求分析報(bào)告的編制者.4 3.1.3 需求報(bào)告評審.4 3.1.4 需求報(bào)告格式.4 3.2 軟件的概要設(shè)計(jì).4 3.2.1 概要設(shè)計(jì).4 3.2.2 編寫概要設(shè)計(jì)的要求.4 3.2.3 概要設(shè)計(jì)報(bào)告的編寫者.4 3.2.4 概要設(shè)計(jì)和需求分析、詳細(xì)設(shè)計(jì)之間的關(guān)系和區(qū)別.4 3.2.5 概要設(shè)計(jì)的評審.4 3.2.6 概要設(shè)計(jì)格式.4 3.3 軟件的詳細(xì)設(shè)計(jì).5 3.3.1 詳細(xì)設(shè)計(jì).5 3.3.2 特例.5 3.3.3 詳細(xì)設(shè)計(jì)的要求.5 3.3.4 數(shù)據(jù)庫設(shè)計(jì).5 3.3.5 詳細(xì)設(shè)計(jì)的評審.5 3.3.6 詳細(xì)設(shè)計(jì)格式.5 3.4 軟件的編碼.5 3.4.1 軟件編碼.5 3.4.2 軟件編碼的要求.5 3.4.3 編碼的評審.6 3.4.4 編程規(guī)范及要求.6 3.5 軟件的測試.6 3.5.1 軟件測試.6 3.5.2 測試計(jì)劃.6 3.6 軟件的交付準(zhǔn)備.6 3.6.1 交付清單.6 _ 精品資料 3.7 軟件的鑒定驗(yàn)收.7 3.7.1 軟件的鑒定驗(yàn)收.7 3.7.2 驗(yàn)收人員.7 3.7.3 驗(yàn)收具體內(nèi)容.7 3.7.4 軟件驗(yàn)收測試大綱.7 3.8 培訓(xùn).7 3.8.1 系統(tǒng)應(yīng)用培訓(xùn).7 3.8.2 系統(tǒng)管理的培訓(xùn)（可選）.8 附附錄錄 A 軟軟件需求分析件需求分析報(bào)報(bào)告文檔模板告文檔模板.9 附附錄錄 B 軟軟件概要件概要設(shè)計(jì)報(bào)設(shè)計(jì)報(bào)告文檔模板告文檔模板 .21 附附錄錄 C 軟軟件件詳細(xì)設(shè)計(jì)報(bào)詳細(xì)設(shè)計(jì)報(bào)告文檔模板告文檔模板.33 附附錄錄 D 軟軟件數(shù)據(jù)件數(shù)據(jù)庫設(shè)計(jì)報(bào)庫設(shè)計(jì)報(bào)告文檔模板告文檔模板.43 附附錄錄 E 軟軟件件測試測試(驗(yàn)驗(yàn)收收)大大綱綱.55 _ 精品資料 1. 范范圍圍 本指南用于指導(dǎo)軟件開發(fā)者為南京市交通局開發(fā)軟件項(xiàng)目的過程，通過規(guī)范軟件項(xiàng)目 承擔(dān)單位的開發(fā)過程達(dá)到提高軟件質(zhì)量，降低維護(hù)成本的目的。開發(fā)者應(yīng)根據(jù)本指南進(jìn)行軟 件開發(fā)和編制軟件開發(fā)文檔。本指南是對軟件項(xiàng)目承擔(dān)單位的基本要求。在本指南的附錄 A 至 E 中提供了文檔的編寫模板供開發(fā)者參考，在進(jìn)行具體軟件開發(fā)時，開發(fā)者可根據(jù)實(shí)際情 況采編寫，但必須提供雙方約定的文檔，文檔中約定的內(nèi)容必須描述清楚。 2. 總總體要求體要求 2.1 總總體功能要求體功能要求 網(wǎng)絡(luò)應(yīng)用環(huán)境以 Internet/Intranet 技術(shù)為核心。 開發(fā)者應(yīng)在充分分析需求的基礎(chǔ)上，選擇采用 B/S 結(jié)構(gòu)或者 C/S 結(jié)構(gòu)。 軟件系統(tǒng)的數(shù)據(jù)庫應(yīng)依照南京市交通局信息化數(shù)據(jù)庫建設(shè)規(guī)范進(jìn)行設(shè)計(jì)和建設(shè)。 本指南中沒有規(guī)定開發(fā)者采用何種具體的軟件工程開發(fā)方法，開發(fā)者可根據(jù)項(xiàng)目具體 特點(diǎn)、自身擅長來選擇采用面向過程的方法、面向?qū)ο蟮姆椒ɑ蛎嫦驍?shù)據(jù)的方法，但建議開 發(fā) 商使用面向?qū)ο筌浖こ痰姆椒?，如：采用目前被廣泛使用的 RUP(Rational Unified Process)方法來進(jìn)行分析、設(shè)計(jì)和開發(fā)。 2.2 軟軟件開件開發(fā)發(fā)平臺要求平臺要求 開發(fā)者開發(fā)的軟件必須能夠在南京市交通局規(guī)定的軟件平臺上正常運(yùn)行。目前軟件平 臺為： 數(shù)據(jù)庫管理系統(tǒng)： Oracle 9i 以上版本 中間件(應(yīng)用服務(wù)器)系統(tǒng)： IBM WebSphere OA 系統(tǒng)： Lotus Domino/Notes 網(wǎng)絡(luò)架構(gòu)： 完全支持 TCP/IP 協(xié)議 開發(fā)工具或技術(shù)體系： 為保證軟件的上下兼容性，開發(fā)者應(yīng)選擇比較通用的開發(fā)工具的較新版本進(jìn)行開 發(fā)，如 Microsoft Visual Studio.Net，Borland Delphi，C+ Builder, 或 J2EE(Java2 P1atform Enterprise Edition)等。 _ 精品資料 2.3 軟軟件件項(xiàng)項(xiàng)目的開目的開發(fā)實(shí)發(fā)實(shí)施施過過程管理要求程管理要求 2.3.1 軟件項(xiàng)目實(shí)施過程總體要求 一一一開發(fā)者提交軟件開發(fā)工作大綱，交通局組織專家組對工作大綱進(jìn)行評審，并提 出整改意見。 一一一通過評審后，開發(fā)者根據(jù)整改意見完善工作大綱，經(jīng)過交通局認(rèn)可后組織項(xiàng)目 組進(jìn)行軟件開發(fā)。軟件開發(fā)工作按照需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測試等幾 個階段進(jìn)行，在開發(fā)過程中，開發(fā)者需分階段提交相關(guān)文檔。 一一一在軟件開發(fā)工作完成后，開發(fā)者應(yīng)向交通局提交完整的軟件文檔，交通局組織 驗(yàn)收組對軟件進(jìn)行驗(yàn)收審查。 2.3.2 軟件項(xiàng)目實(shí)施變更要求 在開發(fā)過程中，需求或設(shè)計(jì)不可避免地需要發(fā)生變更，相關(guān)變更必須經(jīng)過交通局書面同 意方可進(jìn)行。在需求或設(shè)計(jì)發(fā)生變更時，需要對原有文檔進(jìn)行修改，并提供完整的變更記錄， 以使變更處于可控制的狀態(tài)。變更單如下表所示： 表 2-1 變更單 需求變更申請 申請變更的需求文檔 輸入名稱，版本，日期等信息 變更的內(nèi)客及其理由 評估需求變更將對 項(xiàng)目造成的影響 申請人簽字 變更申請的審批意見 項(xiàng)目經(jīng)理簽字 審批意見： 簽字 日期 客戶簽字 (合同項(xiàng)目) 審批意見： 簽字 日期 更改需求文檔 變更后的 需求文檔 輸入名稱，版本，完成日期等信息 更改人簽字 重新評審需求文檔 需求評審小組簽字 評審意見： 簽字 日期 變更結(jié)束 項(xiàng)目經(jīng)理簽字 簽字 日期 2.3.3 軟件項(xiàng)目實(shí)施里程碑控制 交通局將分四個階段進(jìn)行把關(guān)，召開專家審查會。 一一一 需求分析（結(jié)合原型進(jìn)行審查）確認(rèn)； 一一一 概要設(shè)計(jì)+數(shù)據(jù)庫設(shè)計(jì)； _ 精品資料 一一一 預(yù)驗(yàn)收（試運(yùn)行后）； 一一一 正式驗(yàn)收（推廣使用后）。 3. 軟軟件開件開發(fā)發(fā) 合同簽訂以后，項(xiàng)目承擔(dān)單位即可組織項(xiàng)目組進(jìn)行軟件開發(fā)工作。軟件開發(fā)必須嚴(yán)格按 照軟件工程的要求進(jìn)行。開發(fā)過程包括開發(fā)者的活動和任務(wù)。此過程由軟件需求分析、概要 設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測試、驗(yàn)收、鑒定等活動組成。 3.1 軟軟件的需求分析件的需求分析 3.1.1 需求分析 首先，開發(fā)者和交通局應(yīng)共同對交通局的應(yīng)用需求作充分的調(diào)研，提交完整的需求分析 報(bào)告。在需求分析報(bào)告中必須描述的基本問題是：功能、性能、強(qiáng)加于實(shí)現(xiàn)的設(shè)計(jì)限制、屬 性、外部接口。應(yīng)當(dāng)避免把設(shè)計(jì)或項(xiàng)目需求寫入需求分析報(bào)告中。它必須說明由軟件獲得的 結(jié)果，而不是獲得這些結(jié)果的手段。 軟件需求可以用若干種方法來表達(dá)，如通過輸入、輸出說明；使用代表性的例子；用規(guī)范 化的模型。開發(fā)者應(yīng)盡可能地使用模型的方式，因?yàn)檫@是表達(dá)復(fù)雜需求的精確和有效的方法。 比如用統(tǒng)一建模語言（UML）來描述需求。 編寫需求分析報(bào)告的要求 a無歧義性 對最終產(chǎn)品的每一個特性用某一術(shù)語描述；若某一術(shù)語在某一特殊的行文中使用時具有 多種含義，那么應(yīng)對該術(shù)語的每種含義做出解釋并指出其適用場合。 b完整性 需求分析報(bào)告應(yīng)該包括全部有意義的需求，無論是關(guān)系到功能的、性能的、設(shè)計(jì)約束的、 還是關(guān)系到外部接口方面的需求；對所有可能出現(xiàn)的輸入數(shù)據(jù)的響應(yīng)予以定義，要對合法和 非合法的輸入值的響應(yīng)做出規(guī)定；填寫全部插圖、表、圖示標(biāo)記等；定義全部術(shù)語和度量單位。 c可驗(yàn)證性 需求分析報(bào)告描述的每一個需求應(yīng)是可以驗(yàn)證的?？梢酝ㄟ^一個有限處理過程來檢查 軟件產(chǎn)品是否滿足需求。 d一致性 在需求分析報(bào)告中的各個需求的描述不能互相矛盾。 e可修改性 需求分析報(bào)告應(yīng)具有一個有條不紊、易于使用的內(nèi)容組織；沒有冗余，即同一需求不能 在需求分析報(bào)告中出現(xiàn)多次。 f可追蹤性 每一個需求的源流必須清晰，在進(jìn)一步產(chǎn)生和改變文件編制時，可以方便地引證每一個 需求。 g運(yùn)行和維護(hù)階段的可使用性 需求分析報(bào)告必須滿足運(yùn)行和維護(hù)階段的需要。在需求分析報(bào)告要寫明功能的來源和 目的。 _ 精品資料 3.1.2 需求分析報(bào)告的編制者 需求分析報(bào)告應(yīng)由交通局和開發(fā)者雙方共同完成。其中：交通局負(fù)責(zé)根據(jù)實(shí)際需要提出 希望軟件實(shí)現(xiàn)的功能；軟件開發(fā)者根據(jù)交通局提出的性能需求，結(jié)合軟件開發(fā)編寫需求分析。 3.1.3 需求報(bào)告評審 在軟件需求分析工作完成后，軟件開發(fā)者應(yīng)向交通局提交軟件需求分析報(bào)告。交通局 組織有關(guān)人員對需求進(jìn)行評審，以決定軟件需求是否完善和恰當(dāng)。評審?fù)瓿珊螅涂梢赃M(jìn)入 軟件的設(shè)計(jì)階段。 3.1.4 需求報(bào)告格式 軟件需求分析報(bào)告需按一定的格式進(jìn)行編寫，具體的軟件需求分析報(bào)告文檔編寫 模板請見附錄 A。 3.2 軟軟件的概要件的概要設(shè)計(jì)設(shè)計(jì) 3.2.1 概要設(shè)計(jì) 在交通局和開發(fā)者雙方認(rèn)可的需求分析報(bào)告基礎(chǔ)上，開發(fā)者進(jìn)行下步的工作。 首先，開發(fā)者需要對軟件系統(tǒng)進(jìn)行概要設(shè)計(jì)，即系統(tǒng)設(shè)計(jì)。概要設(shè)計(jì)需要對軟件系統(tǒng)的設(shè)計(jì) 進(jìn)行考慮，包括系統(tǒng)的基本處理流程、系統(tǒng)的組織結(jié)構(gòu)、模塊劃分、功能分配、接口設(shè)計(jì)、 運(yùn)行設(shè)計(jì)、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)和出錯處理設(shè)計(jì)等，為軟件的詳細(xì)設(shè)計(jì)提供基礎(chǔ)。 3.2.2 編寫概要設(shè)計(jì)的要求 a一致性 概要設(shè)計(jì)的要求應(yīng)該與需求分析報(bào)告所描述的需求一致。同時，概要設(shè)計(jì)的各項(xiàng)要求之 間也應(yīng)該一致。 b合理性 概要設(shè)計(jì)所提出的設(shè)計(jì)方法和標(biāo)準(zhǔn)應(yīng)該是合理的、恰當(dāng)?shù)摹?c可追蹤性 對概要設(shè)計(jì)所提出的各項(xiàng)要求應(yīng)該可以得到它的清晰的源流，即在需求分析報(bào)告客戶 有明確的需求描述。 d可行性 根據(jù)概要設(shè)計(jì)進(jìn)行詳細(xì)設(shè)計(jì)、操作和維護(hù)應(yīng)該是可行的。 3.2.3 概要設(shè)計(jì)報(bào)告的編寫者 概要設(shè)計(jì)報(bào)告由開發(fā)者根據(jù)需求分析報(bào)告的要求進(jìn)行編寫。 3.2.4 概要設(shè)計(jì)和需求分析、詳細(xì)設(shè)計(jì)之間的關(guān)系和區(qū)別 需求分析不涉及具體的技術(shù)實(shí)現(xiàn)，而概要設(shè)計(jì)注重于從宏觀上和框架上來描述采用何 種技術(shù)手段、方法來實(shí)現(xiàn)這些需求。詳細(xì)設(shè)計(jì)相對概要設(shè)計(jì)更注重于微觀上和框架內(nèi)的設(shè)計(jì)， 是編碼的依據(jù)。概要設(shè)計(jì)是指導(dǎo)詳細(xì)設(shè)計(jì)的依據(jù)。 3.2.5 概要設(shè)計(jì)的評審 在軟件概要設(shè)計(jì)工作完成后，軟件開發(fā)者應(yīng)向交通提交軟件系統(tǒng)概要設(shè)計(jì)報(bào)告。在交 通局對概要設(shè)計(jì)報(bào)告評審?fù)ㄟ^后，即可進(jìn)入詳細(xì)設(shè)計(jì)階段。 3.2.6 概要設(shè)計(jì)格式 軟件系統(tǒng)概要設(shè)計(jì)報(bào)告需按一定的格式進(jìn)行編寫，具體的軟件系統(tǒng)概要設(shè)計(jì)報(bào) 告文檔編寫模板請見附錄 B。 _ 精品資料 3.3 軟軟件的件的詳細(xì)設(shè)計(jì)詳細(xì)設(shè)計(jì) 3.3.1 詳細(xì)設(shè)計(jì) 在概要設(shè)計(jì)的基礎(chǔ)上，開發(fā)者需要進(jìn)行軟件系統(tǒng)的詳細(xì)設(shè)計(jì)。在詳細(xì)設(shè)計(jì)中，描述實(shí) 現(xiàn)具體模塊所涉及到的主要算法、數(shù)據(jù)結(jié)構(gòu)、類的層次結(jié)構(gòu)及調(diào)用關(guān)系，需要說明軟件系統(tǒng) 各個層次中的每一個程序(每個模塊或子程序)的設(shè)計(jì)考慮，以便進(jìn)行編碼和測試。應(yīng)當(dāng)保證 軟件的需求完全分配給整個軟件。詳細(xì)設(shè)計(jì)應(yīng)當(dāng)足夠詳細(xì)，能夠根據(jù)詳細(xì)設(shè)計(jì)報(bào)告進(jìn)行編碼。 3.3.2 特例 如果軟件系統(tǒng)比較簡單，層次較少，可以不必進(jìn)行專門的詳細(xì)設(shè)計(jì)，而和概要設(shè)計(jì)結(jié)合 起來。 3.3.3 詳細(xì)設(shè)計(jì)的要求 a一致性 詳細(xì)設(shè)計(jì)的要求應(yīng)該與需求分析報(bào)告所描述的需求、與概要設(shè)計(jì)一致。同時，詳細(xì)設(shè)計(jì) 的各項(xiàng)要求之間也應(yīng)該是一致的。 b合理性 詳細(xì)設(shè)計(jì)所提出的設(shè)計(jì)方法和標(biāo)準(zhǔn)應(yīng)該是合理的、恰當(dāng)?shù)摹?c可追蹤性 對詳細(xì)設(shè)計(jì)所提出的各項(xiàng)要求應(yīng)該可以得到它的清晰的源流，即可在需求分析報(bào)告、概 要設(shè)計(jì)報(bào)告中有明確的需求描述。 d可行性 根據(jù)詳細(xì)設(shè)計(jì)進(jìn)行編碼、測試、操作和維護(hù)應(yīng)該是可行的。 3.3.4 數(shù)據(jù)庫設(shè)計(jì) 如果軟件產(chǎn)品需要使用到數(shù)據(jù)庫，軟件的詳細(xì)設(shè)計(jì)應(yīng)包括對數(shù)據(jù)庫的設(shè)計(jì)。數(shù)據(jù)庫設(shè)計(jì) 應(yīng)在軟件的需求分析、概要設(shè)計(jì)完成之后、詳細(xì)設(shè)計(jì)的其它工作之前進(jìn)行。在進(jìn)行數(shù)據(jù)庫設(shè) 計(jì)時，應(yīng)當(dāng)按照交通局制定的南京市交通局信息化數(shù)據(jù)庫建設(shè)規(guī)范要求進(jìn)行。 3.3.5 詳細(xì)設(shè)計(jì)的評審 在軟件詳細(xì)設(shè)計(jì)完成后，軟件開發(fā)者應(yīng)向交通局提交軟件系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)報(bào)告和軟 件系統(tǒng)詳細(xì)設(shè)計(jì)報(bào)告。在交通局對軟件系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)報(bào)告、 軟件系統(tǒng)詳細(xì)設(shè)計(jì)報(bào)告評 審?fù)ㄟ^后，即可進(jìn)入軟件編碼階段。 3.3.6 詳細(xì)設(shè)計(jì)格式 軟件系統(tǒng)詳細(xì)設(shè)計(jì)報(bào)告、 軟件系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)報(bào)告需按一定的格式進(jìn)行編寫， 具體的軟件系統(tǒng)詳細(xì)設(shè)計(jì)報(bào)告文檔編寫模板和軟件系統(tǒng)數(shù)據(jù)庫設(shè)計(jì)報(bào)告文檔編寫模 板請見附錄 C、附錄 D。 3.4 軟軟件的件的編碼編碼 3.4.1 軟件編碼 在軟件編碼階段，開發(fā)者根據(jù)軟件系統(tǒng)詳細(xì)設(shè)計(jì)報(bào)告中對數(shù)據(jù)結(jié)構(gòu)、算法分析和模塊 實(shí)現(xiàn)等方面的設(shè)計(jì)要求，開始具體的編寫程序工作，分別實(shí)現(xiàn)各模塊的功能，從而實(shí)現(xiàn)對目 標(biāo)系統(tǒng)的功能、性能、接口、界面等方面的要求。 3.4.2 軟件編碼的要求 a模塊化編碼 _ 精品資料 b代碼可讀性 c可維護(hù)性 d模塊接口標(biāo)準(zhǔn)化 e界面風(fēng)格統(tǒng)一 e注釋的應(yīng)用 3.4.3 編碼的評審 為了盡早發(fā)現(xiàn)軟件中的障礙，提高軟件產(chǎn)品的質(zhì)量，開發(fā)者在編碼的過程中應(yīng)該強(qiáng)調(diào)代 碼評審工作。將代碼評審報(bào)告作為文檔的一部分，提交給交通局。 3.4.4 編程規(guī)范及要求 為了提高編程實(shí)現(xiàn)的質(zhì)量，軟件的程序設(shè)計(jì)必須遵照國家頒布的相關(guān)編程規(guī)范。 主要內(nèi)容包括：規(guī)范化的程序內(nèi)部文檔、數(shù)據(jù)結(jié)構(gòu)的詳細(xì)說明、清晰的語句結(jié)構(gòu)、編碼規(guī) 范。編碼規(guī)范的內(nèi)容包括命名規(guī)范、界面規(guī)范、提示及幫助信息規(guī)范、熱鍵定義等。 其中數(shù)據(jù)庫部分應(yīng)遵守南京市交通局信息化數(shù)據(jù)庫建設(shè)規(guī)范的要求。 在軟件編碼的同時應(yīng)進(jìn)行單元測試。 3.5 軟軟件的件的測試測試 3.5.1 軟件測試 為了盡早發(fā)現(xiàn)軟件產(chǎn)品中的錯誤，從而達(dá)到提高軟件質(zhì)量、降低軟件維護(hù)的費(fèi)用，開發(fā) 者應(yīng)在編碼過程中對各個模塊的程序代碼進(jìn)行單元測試，系統(tǒng)集成時進(jìn)行集成測試，系統(tǒng)集 成完成后對整個軟件進(jìn)行系統(tǒng)測試。單元測試是在軟件開發(fā)過程中針對程序模塊進(jìn)行正確 性檢驗(yàn)。集成測試是在單元測試的基礎(chǔ)上，將所有模塊按照設(shè)計(jì)要求組裝成系統(tǒng)或子系統(tǒng)， 對模塊組裝過程和模塊接口進(jìn)行正確性檢驗(yàn)。軟件系統(tǒng)測試不僅是檢測軟件的整體行為表 現(xiàn)，從另一個側(cè)面看，也是對軟件開發(fā)設(shè)計(jì)的再確認(rèn)。進(jìn)行軟件系統(tǒng)測試工作時。測試主要 包括界面測試、可用性測試、功能測試、穩(wěn)定性(強(qiáng)度)測試、性能測試、強(qiáng)壯性(恢復(fù))測試、邏 輯性測試、破壞性測試、安全性測試等。 開發(fā)者針對單元測試，集成測試，系統(tǒng)測試分別制定測試計(jì)劃。集成測試需要根據(jù)需 求分析報(bào)告和概要設(shè)計(jì)制作測試用例，并須經(jīng)過評審。軟件測試按照測試計(jì)劃、 需求分析 報(bào)告的要求進(jìn)行，最后形成軟件測試報(bào)告。 3.5.2 測試計(jì)劃 在軟件編碼開始之前，開發(fā)者應(yīng)向交通局提交測試計(jì)劃，在軟件交付時，開發(fā)者應(yīng)向 交通局提交軟件測試報(bào)告，以確保開發(fā)者的軟件得到了充分的測試。開發(fā)的軟件必須經(jīng)過 充分的測試證明其符合設(shè)計(jì)要求、運(yùn)行穩(wěn)定、安全可用方可交付交通局。 3.6 軟軟件的交付準(zhǔn)件的交付準(zhǔn)備備 3.6.1 交付清單 在軟件測試證明軟件達(dá)到要求后，軟件開發(fā)者應(yīng)向交通局提交開發(fā)的目標(biāo)安裝程序、數(shù) 據(jù)庫的數(shù)據(jù)字典、 用戶安裝手冊、 用戶使用指南、需求報(bào)告、設(shè)計(jì)報(bào)告、測試報(bào)告等雙方合 同約定的產(chǎn)物。 用戶安裝手冊應(yīng)詳細(xì)介紹安裝軟件對運(yùn)行環(huán)境的要求、安裝軟件的定義和內(nèi)容、在客 戶端、服務(wù)器端及中間件的具體安裝步驟、安裝后的系統(tǒng)配置。 用戶使用指南應(yīng)包括軟件各項(xiàng)功能的使用流程、操作步驟、相應(yīng)業(yè)務(wù)介紹、特殊提示 _ 精品資料 和注意事項(xiàng)等方面的內(nèi)容，在需要時還應(yīng)舉例說明。 3.7 軟軟件的件的鑒鑒定定驗(yàn)驗(yàn)收收 3.7.1 軟件的鑒定驗(yàn)收 在軟件開發(fā)完成后，為了確保軟件是按照需求分析的要求進(jìn)行開發(fā)的，保證軟件產(chǎn)品的 質(zhì)量，需要對軟件產(chǎn)品進(jìn)行鑒定驗(yàn)收。在開發(fā)者如期交付軟件后，由交通局負(fù)責(zé)確定具體的 鑒定驗(yàn)收日期。 3.7.2 驗(yàn)收人員 由交通局聘請具有一定的分析、設(shè)計(jì)、編程和軟件測試經(jīng)驗(yàn)的驗(yàn)收組長和其他專業(yè)人員 組成。驗(yàn)收組設(shè)組長一名(可設(shè)有副組長)，負(fù)責(zé)整個驗(yàn)收的計(jì)劃、組織工作。 3.7.3 驗(yàn)收具體內(nèi)容 驗(yàn)收內(nèi)容應(yīng)該包括：合法性檢查、文檔檢查、軟件一致性檢查、軟件系統(tǒng)測試與測試結(jié)果 評審等幾項(xiàng)工作。 合法性檢查檢查軟件開發(fā)工具是否合法、使用的函數(shù)庫、控件、組件是否有合法的發(fā)布 許可。 文檔檢查檢查開發(fā)者提交的文檔必須齊全，質(zhì)量是否過關(guān)。需要開發(fā)者提供的文檔包括： 項(xiàng)目實(shí)施計(jì)劃； 詳細(xì)技術(shù)方案； 軟件需求規(guī)格說明書(STP)(含數(shù)據(jù)字典)； 概要設(shè)計(jì)說明書(PDD)； 詳細(xì)設(shè)計(jì)說明書(DDD)(含數(shù)據(jù)庫設(shè)計(jì)說明書)； 軟件測試計(jì)劃(STP)(含測試用例)； 軟件測試報(bào)告(STR)； 用戶手冊(SUM)(含操作、使用、維護(hù)、應(yīng)急處理手冊)； 源程序(SCL)(不可修改的電子文檔)； 項(xiàng)目實(shí)施計(jì)劃(PIP)； 項(xiàng)目開發(fā)總結(jié)(PDS)； 軟件質(zhì)量保證計(jì)劃(SQAP)； 此外，驗(yàn)收組可以根據(jù)需要對其它文檔(如軟件配置計(jì)劃、項(xiàng)目進(jìn)展報(bào)表、階段評審報(bào) 表等)進(jìn)行檢查。 文檔的質(zhì)量根據(jù)完備性、正確性、簡明性、可追蹤性、自說明性、規(guī)范件等方面進(jìn)行蹤合 評定。 驗(yàn)收需要對軟件代碼進(jìn)行檢查，以確保其符合規(guī)范，并檢查其一致性。 3.7.4 軟件驗(yàn)收測試大綱 在軟件進(jìn)行鑒定驗(yàn)收前，開發(fā)者需按照一定的格式編寫軟件驗(yàn)收測試大綱，具體的格 式請見附錄 E。 _ 精品資料 3.8 培培訓(xùn)訓(xùn) 3.8.1 系統(tǒng)應(yīng)用培訓(xùn) 主要培訓(xùn)內(nèi)容包括：系統(tǒng)操作使用、業(yè)務(wù)管理流程。 培訓(xùn)對象：應(yīng)用操作人員。 3.8.2 系統(tǒng)管理的培訓(xùn)（可選） 主要培訓(xùn)內(nèi)容包括：系統(tǒng)安裝、調(diào)試、維護(hù)；系統(tǒng)管理。 培訓(xùn)對象：系統(tǒng)管理人員。 開發(fā)者應(yīng)詳細(xì)應(yīng)詳細(xì)列出培列出培訓(xùn)計(jì)訓(xùn)計(jì)劃，包括培劃，包括培訓(xùn)訓(xùn)內(nèi)容、教材、內(nèi)容、教材、時間時間和人和人員員等。等。 _ 精品資料 附附錄錄 A 軟軟件需求分析件需求分析報(bào)報(bào)告文檔模板告文檔模板 1. 引言引言 .11 1.1 編寫目的.11 1.2 項(xiàng)目風(fēng)險(xiǎn).11 1.3 文檔約定.11 1.4 預(yù)期讀者和閱讀建議.11 1.5 產(chǎn)品范圍.12 1.6 參考文獻(xiàn).12 2. 綜綜合描述合描述 .12 2.1 產(chǎn)品的狀況.12 2.2 產(chǎn)品的功能.13 2.3 用戶類和特性.13 2.4 運(yùn)行環(huán)境.13 2.5 設(shè)計(jì)和實(shí)現(xiàn)上的限制.13 2.6 假設(shè)和約束(依賴).14