軟件需求分析報告（完整版）軟件需求分析報告-（完整版）
?錄
1. 范圍 (1)
2. 總體要求 (1)
2.1總體功能要求 (1)
2.2軟件開發(fā)平臺要求 (1)
2.3軟件項?的開發(fā)實施過程管理要求 (2)
2.3.1 軟件項?實施過程總體要求 (2)
2.3.2 軟件項?實施變更要求 (2)
2.3.3 軟件項?實施?程碑控制 (2)
3. 軟件開發(fā) (3)
3.1軟件的需求分析 (3)
3.1.1 需求分析 (3)
3.1.2 需求分析報告的編制者 (4)
3.1.3 需求報告評審 (4)
3.1.4 需求報告格式 (4)
3.2軟件的概要設計 (4)
3.2.1 概要設計 (4)
3.2.2 編寫概要設計的要求 (4)
3.2.3 概要設計報告的編寫者 (4)
3.2.4 概要設計和需求分析、詳細設計之間的關系和區(qū)別 (4)
3.2.5 概要設計的評審 (4)
3.2.6 概要設計格式 (4)
3.3軟件的詳細設計 (5)
3.3.1 詳細設計 (5)
3.3.2 特例 (5)
3.3.3 詳細設計的要求 (5)
3.3.4 數(shù)據(jù)庫設計 (5)
3.3.5 詳細設計的評審 (5)
3.3.6 詳細設計格式 (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 測試計劃 (6)
3.6軟件的交付準備 (6)
3.6.1 交付清單 (6)
3.7軟件的鑒定驗收 (7)
3.7.1 軟件的鑒定驗收 (7)
3.7.2 驗收?員 (7)
3.7.3 驗收具體內(nèi)容 (7)
3.7.4 軟件驗收測試?綱 (7)
3.8培訓 (7)
3.8.1 系統(tǒng)應?培訓 (7)
3.8.2 系統(tǒng)管理的培訓（可選） (8)
附錄A 軟件需求分析報告?檔模板 (9)
附錄B 軟件概要設計報告?檔模板 (21)
附錄C 軟件詳細設計報告?檔模板 (33)
附錄D 軟件數(shù)據(jù)庫設計報告?檔模板 (43)
附錄E 軟件測試(驗收)?綱 ...................................................................... 錯誤!未定義書簽。5
1. 范圍
本指南?于指導軟件開發(fā)者為南京市交通局開發(fā)軟件項?的過程，通過規(guī)范軟件項?承擔單位的開發(fā)過
程達到提?軟件質量，降低維護成本的?的。開發(fā)者應根據(jù)本指南進?軟件開發(fā)和編制軟件開發(fā)?檔。本指南是對軟件項?承擔單位的基本要求。在本指南的附錄A ?E中提供了?檔的編寫模板供開發(fā)者參考，在進?具體軟件開發(fā)時，開發(fā)者可根據(jù)實際情況采編寫，但必須提供雙?約定的?檔，?檔中約定的內(nèi)容必須描述清楚。
2. 總體要求
2.1 總體功能要求
?絡應?環(huán)境以Internet/Intranet技術為核?。
開發(fā)者應在充分分析需求的基礎上，選擇采?B/S結構或者C/S結構。
軟件系統(tǒng)的數(shù)據(jù)庫應依照《南京市交通局信息化數(shù)據(jù)庫建設規(guī)范》進?設計和建設。
本指南中沒有規(guī)定開發(fā)者采?何種具體的軟件?程開發(fā)?法，開發(fā)者可根據(jù)項?具體特點、??擅長來選擇采??向過程的?法、?向對象的?法或?向數(shù)據(jù)的?法，但建議開發(fā)商使??向對象軟件?程的?法，如：采??前被?泛使?的
RUP(Rational Unified Process)?法來進?分析、設計和開發(fā)。
2.2 軟件開發(fā)平臺要求
開發(fā)者開發(fā)的軟件必須能夠在南京市交通局規(guī)定的軟件平臺上正常運?。?前軟件平臺為：
數(shù)據(jù)庫管理系統(tǒng)：
Oracle 9i以上版本
中間件(應?服務器)系統(tǒng)：
IBM WebSphere
OA系統(tǒng)：
Lotus Domino/Notes
?絡架構：
完全?持TCP/IP協(xié)議
開發(fā)?具或技術體系：
為保證軟件的上下兼容性，開發(fā)者應選擇?較通?的開發(fā)?具的較新版本進?開發(fā)，如Microsoft Visual
www.doczj/doc/8c15b7d453e79b89680203d8ce2f0066f53364e1.html ，Borland Delphi，C++ Builder, 或
J2EE(Java2 P1atform Enterpri Edition)等。
2.3 軟件項?的開發(fā)實施過程管理要求
2.3.1 軟件項?實施過程總體要求
（?）開發(fā)者提交軟件開發(fā)?作?綱，交通局組織專家組對?作?綱進?評審，并提出整改意見。
（?）通過評審后，開發(fā)者根據(jù)整改意見完善?作?綱，經(jīng)過交通局認可后組織項?組進?軟件開發(fā)。軟件開發(fā)?作按照需求分析、概要設計、詳細設計、編碼、測試等?個階段進?，在開發(fā)過程中，開發(fā)者需分階段提交相關?檔。
（三）在軟件開發(fā)?作完成后，開發(fā)者應向交通局提交完整的軟件?檔，交通局組織驗收組對軟件進?驗收審查。
2.3.2 軟件項?實施變更要求
在開發(fā)過程中，需求或設計不可避免地需要發(fā)?變更，相關變更必須經(jīng)過交通局書?同意?可進?。在需求或設計發(fā)?變更時，需要對原有?檔進?修改，并提供完整的變更記錄，以使變更處于可控制的狀態(tài)。變更單如下表所?：
表2-1 變更單
2.3.3 軟件項?實施?程碑控制
交通局將分四個階段進?把關，召開專家審查會。
（?）需求分析（結合原型進?審查）確認；
（?）概要設計+數(shù)據(jù)庫設計；
（三）預驗收（試運?后）；
（四）正式驗收（推?使?后）。
3. 軟件開發(fā)
合同簽訂以后，項?承擔單位即可組織項?組進?軟件開發(fā)?作。軟件開發(fā)必須嚴格按照軟件?程的要求進?。開發(fā)過程包括開發(fā)者的活動和任務。此過程由軟件需求分析、概要設計、詳細設計、編碼、測試、驗收、鑒定等活動組成。
3.1 軟件的需求分析
3.1.1 需求分析
?先，開發(fā)者和交通局應共同對交通局的應?需求作充分的調(diào)研，提交完整的需求分析報告。在需求分析報告中必須描述的基本問題是：功能、性能、強加于實現(xiàn)的設計限制、屬性、外部接?。應當避免把設計或項?需求寫?需求分析報告中。它必須說明由軟件獲得的結果，?不是獲得這些結果的?段。
軟件需求可以?若?種?法來表達，如通過輸?、輸出說明；使?代表性的例?；?規(guī)范化的模型。開發(fā)者應盡可能地使?模型的?式，因為這是表達復雜需求的精確和有效的?法。?如?統(tǒng)?建模語?（UML）來描述需求。
編寫需求分析報告的要求
a．?歧義性
對最終產(chǎn)品的每?個特性?某?術語描述；若某?術語在某?特殊的??中使?時具有多種含義，那么應對該術語的每種含義做出解釋并指出其適?場合。
b．完整性
需求分析報告應該包括全部有意義的需求，?論是關系到功能的、性能的、設計約束的、還是關系到外部接???的需求；對所有可能出現(xiàn)的輸?數(shù)據(jù)的響應予以定義，要對合法和?合法的輸?值的響應做出規(guī)定；填寫全部插圖、表、圖?標記等；定義全部術語和度量單位。
c．可驗證性
需求分析報告描述的每?個需求應是可以驗證的。可以通過?個有限處理過程來檢查軟件產(chǎn)品是否滿?需求。
d．?致性
在需求分析報告中的各個需求的描述不能互相?盾。
e．可修改性
需求分析報告應具有?個有條不紊、易于使?的內(nèi)容組織；沒有冗余，即同?需求不能在需求分析報告中出現(xiàn)多次。
f．可追蹤性
每?個需求的源流必須清晰，在進?步產(chǎn)?和改變?件編制時，可以?便地引證每?個需求。
g．運?和維護階段的可使?性
需求分析報告必須滿?運?和維護階段的需要。在需求分析報告要寫明功能的來源和?的。
3.1.2 需求分析報告的編制者
需求分析報告應由交通局和開發(fā)者雙?共同完成。其中：交通局負責根據(jù)實際需要提出希望軟件實現(xiàn)的功能；軟件開發(fā)者根據(jù)交通局提出的性能需求，結合軟件開發(fā)編寫需求分析。
3.1.3 需求報告評審
在軟件需求分析?作完成后，軟件開發(fā)者應向交通局提交《軟件需求分析報告》。交通局組織有關?員對需求進?評審，以決定軟件需求是否完善和恰當。評審完成后，就可以進?軟件的設計階段。
3.1.4 需求報告格式
《軟件需求分析報告》需按?定的格式進?編寫，具體的《軟件需求分析報告》?檔編寫模板請見附錄A。
3.2 軟件的概要設計
3.2.1 概要設計
在交通局和開發(fā)者雙?認可的《需求分析報告》基礎上，開發(fā)者進?下——步的?作。?先，開發(fā)者需
要對軟件系統(tǒng)進?概要設計，即系統(tǒng)設計。概要設計需要對軟件系統(tǒng)的設計進?考慮，包括系統(tǒng)的基本處理流程、系統(tǒng)的組織結構、模塊劃分、功能分配、接?設計、運?設計、數(shù)據(jù)結構設計和出錯處理設計等，為軟件的詳細設計提供基礎。
3.2.2 編寫概要設計的要求
a．?致性
概要設計的要求應該與需求分析報告所描述的需求?致。同時，概要設計的各項要求之間也應該?致。
b．合理性
概要設計所提出的設計?法和標準應該是合理的、恰當?shù)摹?/span>
c．可追蹤性
對概要設計所提出的各項要求應該可以得到它的清晰的源流，即在需求分析報告客戶有明確的需求描述。
d．可?性
根據(jù)概要設計進?詳細設計、操作和維護應該是可?的。
3.2.3 概要設計報告的編寫者
概要設計報告由開發(fā)者根據(jù)需求分析報告的要求進?編寫。
3.2.4 概要設計和需求分析、詳細設計之間的關系和區(qū)別
需求分析不涉及具體的技術實現(xiàn)，?概要設計注重于從宏觀上和框架上來描述采?何種技術?段、?法來實現(xiàn)這些需求。詳細設計相對概要設計更注重于微觀上和框架內(nèi)的設計，是編碼的依據(jù)。概要設計是指導詳細設計的依據(jù)。
3.2.5 概要設計的評審
在軟件概要設計?作完成后，軟件開發(fā)者應向交通提交《軟件系統(tǒng)概要設計報告》。在交通局對《概要設計報告》評審通過后，即可進?詳細設計階段。
3.2.6 概要設計格式
《軟件系統(tǒng)概要設計報告》需按?定的格式進?編寫，具體的《軟件系統(tǒng)概要設計報告》?檔編寫模板請見附錄B。
3.3 軟件的詳細設計
3.3.1 詳細設計
在概要設計的基礎上，開發(fā)者需要進?軟件系統(tǒng)的詳細設計。在詳細設計中，描述實現(xiàn)具體模塊所涉及到的主要算法、數(shù)據(jù)結構、類的層次結構及調(diào)?關系，需要說明軟件系統(tǒng)各個層次中的每?個程序(每個模塊或?程序)的設計考慮，以便進?編碼和測試。應當保證軟件的需求完全分配給整個軟件。詳細設計應當?夠詳細，能夠根據(jù)詳細設計報告進?編碼。
3.3.2 特例
如果軟件系統(tǒng)?較簡單，層次較少，可以不必進?專門的詳細設計，?和概要設計結合起來。
3.3.3 詳細設計的要求
a．?致性
詳細設計的要求應該與需求分析報告所描述的需求、與概要設計?致。同時，詳細設計的各項要求之間也應該是?致的。
b．合理性
詳細設計所提出的設計?法和標準應該是合理的、恰當?shù)摹?/span>
c．可追蹤性
