軟件項目開發(fā)各階段文檔模板(參考)

1、I / 117 文檔可自由編輯 目錄目錄 1.1. 范圍范圍.1 1 2.2. 總體要求總體要求.1 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.3. 軟件開發(fā)軟件開發(fā).3 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 編寫概要設計的要

2、求.4 3.2.3 概要設計報告的編寫者.4 II / 117 文檔可自由編輯 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 數據庫設計 .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 軟件測試

3、.6 3.5.2 測試計劃 .6 3.6 軟件的交付準備.6 3.6.1 交付清單 .6 3.7 軟件的鑒定驗收.7 3.7.1 軟件的鑒定驗收.7 III / 117 文檔可自由編輯 3.7.2 驗收人員 .7 3.7.3 驗收具體內容.7 3.7.4 軟件驗收測試大綱.7 3.8 培訓.7 3.8.1 系統(tǒng)應用培訓.7 3.8.2 系統(tǒng)管理的培訓（可選）.8 附錄附錄 A A 軟件需求分析報告文檔模板軟件需求分析報告文檔模板 .9 9 附錄附錄 B B 軟件概要設計報告文檔模板軟件概要設計報告文檔模板 .2121 附錄附錄 C C 軟件詳細設計報告文檔模板軟件詳細設計報告文檔模板 .333

4、3 附錄附錄 D D 軟件數據庫設計報告文檔模板軟件數據庫設計報告文檔模板 .4343 附錄附錄 E E 軟件測試軟件測試( (驗收驗收) )大綱大綱 .5 55 5 1 / 117 文檔可自由編輯 1. 范圍范圍 本指南用于指導軟件開發(fā)者為南京市交通局開發(fā)軟件項目的過程， 通過規(guī)范軟件項目承擔單位的開發(fā)過程達到提高軟件質量，降低維 護成本的目的。開發(fā)者應根據本指南進行軟件開發(fā)和編制軟件開發(fā) 文檔。本指南是對軟件項目承擔單位的基本要求。在本指南的附錄 A 至 E 中提供了文檔的編寫模板供開發(fā)者參考，在進行具體軟件開 發(fā)時，開發(fā)者可根據實際情況采編寫，但必須提供雙方約定的文檔， 文檔中約定的內容

5、必須描述清楚。 2. 總體要求總體要求 2.1 總體功能要求總體功能要求 網絡應用環(huán)境以 Internet/Intranet 技術為核心。 開發(fā)者應在充分分析需求的基礎上，選擇采用 B/S 結構或者 C/S 結構。 軟件系統(tǒng)的數據庫應依照南京市交通局信息化數據庫建設規(guī)范 進行設計和建設。 本指南中沒有規(guī)定開發(fā)者采用何種具體的軟件工程開發(fā)方法，開 發(fā)者可根據項目具體特點、自身擅長來選擇采用面向過程的方法、 面向對象的方法或面向數據的方法，但建議開發(fā) 商使用面向對 2 / 117 文檔可自由編輯 象軟件工程的方法，如：采用目前被廣泛使用的 RUP(Rational Unified Process)

6、方法來進行分析、設計和開發(fā)。 2.2 軟件開發(fā)平臺要求軟件開發(fā)平臺要求 開發(fā)者開發(fā)的軟件必須能夠在南京市交通局規(guī)定的軟件平臺上正 常運行。目前軟件平臺為： 數據庫管理系統(tǒng)： Oracle 9i 以上版本 中間件(應用服務器)系統(tǒng)： IBM WebSphere OA 系統(tǒng)： Lotus Domino/Notes 網絡架構： 完全支持 TCP/IP 協(xié)議 開發(fā)工具或技術體系： 為保證軟件的上下兼容性，開發(fā)者應選擇比較通用的開發(fā)工 具的較新版本進行開發(fā)，如 Microsoft Visual Studio.Net，Borland Delphi，C+ Builder, 或 J2EE(Java2 P1at

7、form Enterprise Edition)等。 3 / 117 文檔可自由編輯 2.3 軟件項目的開發(fā)實施過程管理要求軟件項目的開發(fā)實施過程管理要求 2.3.1 軟件項目實施過程總體要求 （一）開發(fā)者提交軟件開發(fā)工作大綱，交通局組織專家組對工作 大綱進行評審，并提出整改意見。 （二）通過評審后，開發(fā)者根據整改意見完善工作大綱，經過交 通局認可后組織項目組進行軟件開發(fā)。軟件開發(fā)工作按照需求 分析、概要設計、詳細設計、編碼、測試等幾個階段進行，在 開發(fā)過程中，開發(fā)者需分階段提交相關文檔。 （三）在軟件開發(fā)工作完成后，開發(fā)者應向交通局提交完整的軟 件文檔，交通局組織驗收組對軟件進行驗收審查。

8、2.3.2 軟件項目實施變更要求 在開發(fā)過程中，需求或設計不可避免地需要發(fā)生變更，相關變更 必須經過交通局書面同 意方可進行。在需求或設計發(fā)生變更時， 需要對原有文檔進行修改，并提供完整的變更記錄， 以使變更處 于可控制的狀態(tài)。變更單如下表所示： 表 2-1 變更單 需求變更申請 申請變更的需求文 檔 輸入名稱，版本，日期等 信息 變更的內客及其理 由 4 / 117 文檔可自由編輯 評估需求變更將對 項目造成的影響 申請人簽字 變更申請的審批意見 項目經理簽字 審批意見： 簽 字 日期 客戶簽字 (合同項目) 審批意見： 簽 字 日期 更改需求文檔 變更后的 需求文檔 輸入名稱，版本，完成日

9、期等信 息 更改人簽字 重新評審需求文檔 需求評審小組簽字 評審意見： 簽 字 日期 變更結束 5 / 117 文檔可自由編輯 項目經理簽字 簽 字 日期 2.3.3 軟件項目實施里程碑控制 交通局將分四個階段進行把關，召開專家審查會。 （一） 需求分析（結合原型進行審查）確認； （二） 概要設計+數據庫設計； （三） 預驗收（試運行后） ； （四） 正式驗收（推廣使用后） 。 3. 軟件開發(fā)軟件開發(fā) 合同簽訂以后，項目承擔單位即可組織項目組進行軟件開發(fā)工作。 軟件開發(fā)必須嚴格按照軟件工程的要求進行。開發(fā)過程包括開發(fā)者 的活動和任務。此過程由軟件需求分析、概要設計、詳細設計、編 碼、測試、驗收

10、、鑒定等活動組成。 3.1 軟件的需求分析軟件的需求分析 3.1.1 需求分析 首先，開發(fā)者和交通局應共同對交通局的應用需求作充分的調研， 提交完整的需求分析 報告。在需求分析報告中必須描述的基本問 題是：功能、性能、強加于實現的設計限制、屬 性、外部接口。應 當避免把設計或項目需求寫入需求分析報告中。它必須說明由軟件 獲得的 結果，而不是獲得這些結果的手段。 6 / 117 文檔可自由編輯 軟件需求可以用若干種方法來表達，如通過輸入、輸出說明；使 用代表性的例子；用規(guī)范化的模型。開發(fā)者應盡可能地使用模型的 方式，因為這是表達復雜需求的精確和有效的方法。比如用統(tǒng)一建 模語言（UML）來描述需求

11、。 編寫需求分析報告的要求 a無歧義性 對最終產品的每一個特性用某一術語描述；若某一術語在某一特 殊的行文中使用時具有多種含義，那么應對該術語的每種含義做出 解釋并指出其適用場合。 b完整性 需求分析報告應該包括全部有意義的需求，無論是關系到功能的、 性能的、設計約束的、還是關系到外部接口方面的需求；對所有可 能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的 響應做出規(guī)定；填寫全部插圖、表、圖示標記等；定義全部術語和 度量單位。 c可驗證性 需求分析報告描述的每一個需求應是可以驗證的?？梢酝ㄟ^一個 有限處理過程來檢查軟件產品是否滿足需求。 d一致性 在需求分析報告中的各個需求的描述不

12、能互相矛盾。 e可修改性 需求分析報告應具有一個有條不紊、易于使用的內容組織；沒有 7 / 117 文檔可自由編輯 冗余，即同一需求不能在需求分析報告中出現多次。 f可追蹤性 每一個需求的源流必須清晰，在進一步產生和改變文件編制時， 可以方便地引證每一個需求。 g運行和維護階段的可使用性 需求分析報告必須滿足運行和維護階段的需要。在需求分析報告 要寫明功能的來源和目的。 3.1.2 需求分析報告的編制者 需求分析報告應由交通局和開發(fā)者雙方共同完成。其中：交通局 負責根據實際需要提出希望軟件實現的功能；軟件開發(fā)者根據交通 局提出的性能需求，結合軟件開發(fā)編寫需求分析。 3.1.3 需求報告評審 在

13、軟件需求分析工作完成后，軟件開發(fā)者應向交通局提交軟件 需求分析報告 。交通局組織有關人員對需求進行評審，以決定軟件 需求是否完善和恰當。評審完成后，就可以進入軟件的設計階段。 3.1.4 需求報告格式 軟件需求分析報告需按一定的格式進行編寫，具體的軟件 需求分析報告文檔編寫模板請見附錄 A。 3.2 軟件的概要設計軟件的概要設計 3.2.1 概要設計 在交通局和開發(fā)者雙方認可的需求分析報告基礎上，開發(fā)者 8 / 117 文檔可自由編輯 進行下步的工作。 首先，開發(fā)者需要對軟件系統(tǒng)進行概要 設計，即系統(tǒng)設計。概要設計需要對軟件系統(tǒng)的設計 進行考慮， 包括系統(tǒng)的基本處理流程、系統(tǒng)的組織結構、模塊劃

14、分、功能分配、 接口設計、 運行設計、數據結構設計和出錯處理設計等，為軟 件的詳細設計提供基礎。 3.2.2 編寫概要設計的要求 a一致性 概要設計的要求應該與需求分析報告所描述的需求一致。同時， 概要設計的各項要求之間也應該一致。 b合理性 概要設計所提出的設計方法和標準應該是合理的、恰當的。 c可追蹤性 對概要設計所提出的各項要求應該可以得到它的清晰的源流，即 在需求分析報告客戶有明確的需求描述。 d可行性 根據概要設計進行詳細設計、操作和維護應該是可行的。 3.2.3 概要設計報告的編寫者 概要設計報告由開發(fā)者根據需求分析報告的要求進行編寫。 3.2.4 概要設計和需求分析、詳細設計之間

15、的關系和區(qū)別 需求分析不涉及具體的技術實現，而概要設計注重于從宏觀上 和框架上來描述采用何種技術手段、方法來實現這些需求。詳細設 計相對概要設計更注重于微觀上和框架內的設計， 是編碼的依 9 / 117 文檔可自由編輯 據。概要設計是指導詳細設計的依據。 3.2.5 概要設計的評審 在軟件概要設計工作完成后，軟件開發(fā)者應向交通提交軟件系 統(tǒng)概要設計報告 。在交通局對概要設計報告評審通過后，即可 進入詳細設計階段。 3.2.6 概要設計格式 軟件系統(tǒng)概要設計報告需按一定的格式進行編寫，具體的 軟件系統(tǒng)概要設計報 告文檔編寫模板請見附錄 B。 3.3 軟件的詳細設計軟件的詳細設計 3.3.1 詳細

16、設計 在概要設計的基礎上，開發(fā)者需要進行軟件系統(tǒng)的詳細設計。在 詳細設計中，描述實 現具體模塊所涉及到的主要算法、數據結 構、類的層次結構及調用關系，需要說明軟件系統(tǒng)各個層次中的每 一個程序(每個模塊或子程序)的設計考慮，以便進行編碼和測試。 應當保證 軟件的需求完全分配給整個軟件。詳細設計應當足夠 詳細，能夠根據詳細設計報告進行編碼。 3.3.2 特例 如果軟件系統(tǒng)比較簡單，層次較少，可以不必進行專門的詳細設 計，而和概要設計結合起來。 3.3.3 詳細設計的要求 a一致性 10 / 117 文檔可自由編輯 詳細設計的要求應該與需求分析報告所描述的需求、與概要設計 一致。同時，詳細設計的各項

17、要求之間也應該是一致的。 b合理性 詳細設計所提出的設計方法和標準應該是合理的、恰當的。 c可追蹤性 對詳細設計所提出的各項要求應該可以得到它的清晰的源流，即 可在需求分析報告、概要設計報告中有明確的需求描述。 d可行性 根據詳細設計進行編碼、測試、操作和維護應該是可行的。 3.3.4 數據庫設計 如果軟件產品需要使用到數據庫，軟件的詳細設計應包括對數據 庫的設計。數據庫設計應在軟件的需求分析、概要設計完成之后、 詳細設計的其它工作之前進行。在進行數據庫設計時，應當按照交 通局制定的南京市交通局信息化數據庫建設規(guī)范要求進行。 3.3.5 詳細設計的評審 在軟件詳細設計完成后，軟件開發(fā)者應向交通

18、局提交軟件系統(tǒng) 數據庫設計報告和軟件系統(tǒng)詳細設計報告 。在交通局對軟件 系統(tǒng)數據庫設計報告 、 軟件系統(tǒng)詳細設計報告評審通過后，即 可進入軟件編碼階段。 3.3.6 詳細設計格式 軟件系統(tǒng)詳細設計報告 、 軟件系統(tǒng)數據庫設計報告需按一 定的格式進行編寫， 具體的軟件系統(tǒng)詳細設計報告文檔編 11 / 117 文檔可自由編輯 寫模板和軟件系統(tǒng)數據庫設計報告文檔編寫模 板請見附錄 C、附錄 D。 3.4 軟件的編碼軟件的編碼 3.4.1 軟件編碼 在軟件編碼階段，開發(fā)者根據軟件系統(tǒng)詳細設計報告中對數 據結構、算法分析和模塊實現等方面的設計要求，開始具體的編寫 程序工作，分別實現各模塊的功能，從而實現

19、對目標系統(tǒng)的功能、 性能、接口、界面等方面的要求。 3.4.2 軟件編碼的要求 a模塊化編碼 b代碼可讀性 c可維護性 d模塊接口標準化 e界面風格統(tǒng)一 e注釋的應用 3.4.3 編碼的評審 為了盡早發(fā)現軟件中的障礙，提高軟件產品的質量，開發(fā)者在編 碼的過程中應該強調代碼評審工作。將代碼評審報告作為文檔的一 部分，提交給交通局。 3.4.4 編程規(guī)范及要求 為了提高編程實現的質量，軟件的程序設計必須遵照國家頒布的 12 / 117 文檔可自由編輯 相關編程規(guī)范。 主要內容包括：規(guī)范化的程序內部文檔、數據結構的詳細說明、 清晰的語句結構、編碼規(guī)范。編碼規(guī)范的內容包括命名規(guī)范、界面 規(guī)范、提示及幫

20、助信息規(guī)范、熱鍵定義等。 其中數據庫部分應遵守南京市交通局信息化數據庫建設規(guī)范 的要求。 在軟件編碼的同時應進行單元測試。 3.5 軟件的測試軟件的測試 3.5.1 軟件測試 為了盡早發(fā)現軟件產品中的錯誤，從而達到提高軟件質量、降低 軟件維護的費用，開發(fā)者應在編碼過程中對各個模塊的程序代碼進 行單元測試，系統(tǒng)集成時進行集成測試，系統(tǒng)集成完成后對整個軟 件進行系統(tǒng)測試。單元測試是在軟件開發(fā)過程中針對程序模塊進行 正確性檢驗。集成測試是在單元測試的基礎上，將所有模塊按照設 計要求組裝成系統(tǒng)或子系統(tǒng)，對模塊組裝過程和模塊接口進行正確 性檢驗。軟件系統(tǒng)測試不僅是檢測軟件的整體行為表 現，從另 一個側面

21、看，也是對軟件開發(fā)設計的再確認。進行軟件系統(tǒng)測試工 作時。測試主要包括界面測試、可用性測試、功能測試、穩(wěn)定性(強 度)測試、性能測試、強壯性(恢復)測試、邏輯性測試、破壞性測試、 安全性測試等。 開發(fā)者針對單元測試，集成測試，系統(tǒng)測試分別制定測試計劃 13 / 117 文檔可自由編輯 。集成測試需要根據需求分析報告和概要設計制作測試用例，并須 經過評審。軟件測試按照測試計劃 、 需求分析報告的要求進 行，最后形成軟件測試報告 。 3.5.2 測試計劃 在軟件編碼開始之前，開發(fā)者應向交通局提交測試計劃 ，在 軟件交付時，開發(fā)者應向交通局提交軟件測試報告 ，以確保開發(fā) 者的軟件得到了充分的測試。開

22、發(fā)的軟件必須經過充分的測試證明 其符合設計要求、運行穩(wěn)定、安全可用方可交付交通局。 3.6 軟件的交付準備軟件的交付準備 3.6.1 交付清單 在軟件測試證明軟件達到要求后，軟件開發(fā)者應向交通局提交開 發(fā)的目標安裝程序、數據庫的數據字典、 用戶安裝手冊 、 用戶使 用指南 、需求報告、設計報告、測試報告等雙方合同約定的產物。 用戶安裝手冊應詳細介紹安裝軟件對運行環(huán)境的要求、安裝 軟件的定義和內容、在客戶端、服務器端及中間件的具體安裝步驟、 安裝后的系統(tǒng)配置。 用戶使用指南應包括軟件各項功能的使用流程、操作步驟、 相應業(yè)務介紹、特殊提示和注意事項等方面的內容，在需要時還應 舉例說明。 14 /

23、117 文檔可自由編輯 3.7 軟件的鑒定驗收軟件的鑒定驗收 3.7.1 軟件的鑒定驗收 在軟件開發(fā)完成后，為了確保軟件是按照需求分析的要求進行開 發(fā)的，保證軟件產品的質量，需要對軟件產品進行鑒定驗收。在開 發(fā)者如期交付軟件后，由交通局負責確定具體的鑒定驗收日期。 3.7.2 驗收人員 由交通局聘請具有一定的分析、設計、編程和軟件測試經驗的驗 收組長和其他專業(yè)人員組成。驗收組設組長一名(可設有副組長)， 負責整個驗收的計劃、組織工作。 3.7.3 驗收具體內容 驗收內容應該包括：合法性檢查、文檔檢查、軟件一致性檢查、 軟件系統(tǒng)測試與測試結果評審等幾項工作。 合法性檢查檢查軟件開發(fā)工具是否合法、

24、使用的函數庫、控件、 組件是否有合法的發(fā)布許可。 文檔檢查檢查開發(fā)者提交的文檔必須齊全，質量是否過關。需要 開發(fā)者提供的文檔包括： 項目實施計劃； 詳細技術方案； 軟件需求規(guī)格說明書(STP)(含數據字典)； 概要設計說明書(PDD)； 詳細設計說明書(DDD)(含數據庫設計說明書)； 軟件測試計劃(STP)(含測試用例)； 15 / 117 文檔可自由編輯 軟件測試報告(STR)； 用戶手冊(SUM)(含操作、使用、維護、應急處理手冊)； 源程序(SCL)(不可修改的電子文檔)； 項目實施計劃(PIP)； 項目開發(fā)總結(PDS)； 軟件質量保證計劃(SQAP)； 此外，驗收組可以根據需要對其

25、它文檔(如軟件配置計劃、項目 進展報表、階段評審報 表等)進行檢查。 文檔的質量根據完備性、正確性、簡明性、可追蹤性、自說明性、 規(guī)范件等方面進行蹤合評定。 驗收需要對軟件代碼進行檢查，以確保其符合規(guī)范，并檢查其一 致性。 3.7.4 軟件驗收測試大綱 在軟件進行鑒定驗收前，開發(fā)者需按照一定的格式編寫軟件驗 收測試大綱 ，具體的格式請見附錄 E。 3.8 培訓培訓 3.8.1 系統(tǒng)應用培訓 主要培訓內容包括：系統(tǒng)操作使用、業(yè)務管理流程。 培訓對象：應用操作人員。 3.8.2 系統(tǒng)管理的培訓（可選） 主要培訓內容包括：系統(tǒng)安裝、調試、維護；系統(tǒng)管理。 16 / 117 文檔可自由編輯 培訓對象：

26、系統(tǒng)管理人員。 開發(fā)者應詳細列出培訓計劃，包括培訓內容、教材、時間和人員應詳細列出培訓計劃，包括培訓內容、教材、時間和人員 等。等。 17 / 117 文檔可自由編輯 附錄附錄 A A 軟件需求分析報告文檔模板軟件需求分析報告文檔模板 1.1. 引言引言.1111 1.1 編寫目的.11 1.2 項目風險.11 1.3 文檔約定.11 1.4 預期讀者和閱讀建議.11 1.5 產品范圍.12 1.6 參考文獻.12 2.2. 綜合描述綜合描述.1212 2.1 產品的狀況.12 2.2 產品的功能.13 2.3 用戶類和特性.13 2.4 運行環(huán)境.13 2.5 設計和實現上的限制.13 2.

27、6 假設和約束(依賴).14 3.3. 外部接口需求外部接口需求.1414 3.1 用戶界面.14 3.2 硬件接口.15 3.3 軟件接口.15 3.4 通訊接口.16 18 / 117 文檔可自由編輯 4.4. 系統(tǒng)功能需求系統(tǒng)功能需求.1616 4.1 說明和優(yōu)先級.16 4.2 激勵響應序列.17 4.3 輸入輸出數據.17 5.5. 其它非功能需求其它非功能需求.1717 5.1 性能需求.17 5.2 安全措施需求.18 5.3 安全性需求.18 5.4 軟件質量屬性.18 5.5 業(yè)務規(guī)則.18 5.6 用戶文檔.18 6.6. 詞匯表詞匯表.1919 7.7. 數據定義數據定義

28、.1919 8.8. 分析模型分析模型.2020 9.9. 待定問題列表待定問題列表.2020 19 / 117 文檔可自由編輯 20 / 117 文檔可自由編輯 1. 引言引言 引言是對這份軟件產品需求分析報告的概覽，是為了幫助閱讀者 了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份 文檔。 1.1 編寫目的編寫目的 說明這份軟件產品需求分析報告是為哪個軟件產品編寫的，開發(fā) 這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件 產品需求分析報告詳盡說明了該軟件產品的需求規(guī)格，包括修正和 (或)發(fā)行版本號，從而對該軟件產品進行準確的定義。 如果這份軟件產品需求分析報告只與整個系

29、統(tǒng)的某一部分有關系， 那么只定義軟件產品需求分析報告中說明的那個部分或子系統(tǒng)。 1.2 項目風險項目風險 具體說明本軟件開發(fā)項目的全部風險承擔者，以及各自在本階段 所需要承擔的主要風險，首要風險承擔者包括： 任務提出者； 軟件開發(fā)者； 產品使用者。 1.3 文檔約定文檔約定 描述編寫文檔時所采用的標準(如果有標準的話)，或者各種排版 21 / 117 文檔可自由編輯 約定。排版約定應該包括： 正文風格； 提示方式； 重要符號； 也應該說明高層次需求是否可以被其所有細化的需求所繼承，或 者每個需求陳述是否都有其自己的優(yōu)先級。 1.4 預期讀者和閱讀建議預期讀者和閱讀建議 列舉本軟件產品需求分析報

30、告所針對的各種不同的預期讀者，例 如，可能包括： 用戶； 開發(fā)人員； 項目經理； 營銷人員； 測試人員； 文檔編寫入員。 并且描述了文檔中，其余部分的內容及其組織結構，并且針對每 一類讀者提出最適合的文檔閱讀建議。 1.5 產品范圍產品范圍 說明該軟件產品及其開發(fā)目的的簡短描述，包括利益和目標。把 軟件產品開發(fā)與企業(yè)目標，或者業(yè)務策略相聯(lián)系。 22 / 117 文檔可自由編輯 描述產品范圍時需注意，可以參考項目視圖和范圍文檔，但是不 能將其內容復制到這里。 1.6 參考文獻參考文獻 列舉編寫軟件產品需求分析報告時所用到的參考文獻及資料，可 能包括： 本項目的合同書； 上級機關有關本項目的批文；

31、 本項目已經批準的計劃任務書； 用戶界面風格指導； 開發(fā)本項目時所要用到的標淮； 系統(tǒng)規(guī)格需求說明； 使用實例文檔； 屬于本項目的其它己發(fā)表文件； 本軟件產品需求分析報告中所引用的文件、資料； 相關軟件產品需求分析報告； 為了方便讀者查閱，所有參考資料應該按一定順序排列。如果可 能，每份資料都應該給出： 標題名稱； 作者或者合同簽約者； 文件編號或者版本號； 發(fā)表日期或者簽約日期； 23 / 117 文檔可自由編輯 出版單位或者資料來源。 2. 綜合描述綜合描述 這一部分概述了正在定義的軟件產品的作用范圍以及該軟件產品 所運行的環(huán)境、使用該軟件產品的用戶、對該軟件產品己知的限制、 有關該軟件產

32、品的假設和依賴。 2.1 產品的狀況產品的狀況 描述了在軟件產品需求分析報告中所定義的軟件產品的背景和起 源。說明了該軟件產品是否屬于下列情況： 是否是產品系列中的下一成員； 是否是成熟產品所改進的下一代產品； 是否是現有應用軟件的替代品(升級產品)； 是否是一個新型的、自主型的產品。 如果該軟件產品需求分析報告定義的軟件系統(tǒng)是： 大系統(tǒng)的一個組成部分； 與其它系統(tǒng)和其它機構之間存在基本的相互關系。 那么必須說明軟件產品需求分析報告定義的這部分軟件是怎樣與 整個大系統(tǒng)相關聯(lián)的，或者（同時）說明相互關系的存在形式，并 且要定義出兩者之間的全部接口。 24 / 117 文檔可自由編輯 2.2 產品

33、的功能產品的功能 因為將在需求分析報告的第 4 部分中詳細描述軟件產品的功能， 所以在此只需要概略地總結。僅從業(yè)務層面陳述本軟件產品所應具 有的主要功能，在描述功能時應該針對每一項需求準確地描述其各 項規(guī)格說明。如果存在引起誤解的可能，在陳述本軟件產品主要功 能的作用領域時，也需要對應陳述本軟件產品的非作用領域，以利 讀者理解本軟件產品。 為了很好地組織產品功能，使每個讀者都容易理解，可以采用列 表的方法給出。也可以采用圖形方式，將主要的需求分組以及它們 之間的聯(lián)系使用數據流程圖的頂層圖或類圖進行表示，這種表示方 法是很有用的。 參考用戶當前管理組織構架，了解各個機構的主要職能，將有助 于陳述

34、軟件產品的主要功能。 2.3 用戶類和特性用戶類和特性 確定有可能使用該軟件產品的不同用戶類，并且描述它們相關的 特征。往往有一些軟件需求，只與特定的用戶類有關。描述時，應 該將該軟件產品的重要用戶類與非重要用戶類區(qū)分開。 用戶不一定是軟件產品的直接使用者，通過報表、應用程序接口、 系統(tǒng)硬件接口得到軟件產品的數據和服務的人、或者機構也有他們 的需求。所以，應該將這些外部需求視為通過報表、應用程序接口、 系統(tǒng)硬件接口附加給軟件產品的附加用戶類。 25 / 117 文檔可自由編輯 2.4 運行環(huán)境運行環(huán)境 描述了本軟件的運行環(huán)境，一般包括： 硬件平臺； 操作系統(tǒng)和版本； 支撐環(huán)境(例如：數據庫等)

35、和版本； 其它與該軟件有關的軟件組件； 與該軟件共存的應用程序。 2.5 設計和實現上的限制設計和實現上的限制 確定影響開發(fā)人員自由選擇的問題，并且說明這些問題為什么成 為一種限制?？赡艿南拗瓢ㄏ铝袃热荩?必須使用的特定技術、工具、編程語言和數據庫； 避免使用的特定技術、工具、編程語言和數據庫； 要求遵循的開發(fā)規(guī)范和標準 例如，如果由客戶的公司或者第三方公司負責軟件維護，就必須 定義轉包者所使用的設計符號表示和編碼標準； 企業(yè)策略的限制； 政府法規(guī)的限制； 工業(yè)標準的限制； 硬件的限制 例如，定時需求或存儲器限制； 數據轉換格式標淮的限制。 26 / 117 文檔可自由編輯 2.6 假設和約

36、束假設和約束( (依賴依賴) ) 列舉出對軟件產品需求分析報告中，影響需求陳述的假設因素 (與己知因素相對立)。如果這些假設因素不正確、不一致或者被修 改，就會使軟件產品開發(fā)項目受到影響。這些假設的因素可能包括： 計劃使用的商業(yè)組件，或者其它軟件中的某個部件； 假定產品中某個用戶界面將符合一個特殊的設計約定； 有關本軟件用戶的若干假定(例如：假定用戶會熟練使用 SQL 語言。)； 有關本軟件開發(fā)工作的若干假定(例如：用戶承諾的優(yōu)惠、方 便、上級部門給予的特殊政策和支持等。)； 有關本軟件運行環(huán)境的一些問題； 此外，確定本軟件開發(fā)項目對外部約束因素所存在的依賴。有關 的約束可能包括： 工期約束；

37、 經費約束； 人員約束； 設備約束； 地理位置約束； 其它有關項目約束； 27 / 117 文檔可自由編輯 3. 外部接口需求外部接口需求 通過本節(jié)描述可以確定，保證軟件產品能和外部組件正確連接的 需求。關聯(lián)圖僅能表示高層抽象的外部接口，必須對接口數據和外 部組件進行詳細描述，并且寫入數據定義中。如果產品的不同部分 有不同的外部接口，那么應該把這些外部接口的全部詳細需求并入 到這一部分實例中。 注意：必須將附加用戶類的特征與外部接口需求加以區(qū)分，附加 用戶類的特征描述的是通過接口取得軟件產品的數據和服務的人的 需求；而外部接口需求描述的是接口本身的需求。 3.1 用戶界面用戶界面 陳述需要使用

38、在用戶界面上的軟件組件，描述每一個用戶界面的 邏輯特征。必須注意，這里需要描述的是用戶界面的邏輯特征，而 不是用戶界面。以下是可能包括的一些特征： 將要采用的圖形用戶界面(GUl)標準或者產品系列的風格； 有關屏幕布局或者解決方案的限制； 將要使用在每一個屏幕(圖形用戶界面)上的軟件組件，可能 包括： 選單； 標準按鈕； 導航鏈接； 各種功能組件； 28 / 117 文檔可自由編輯 消息欄； 快捷鍵； 各種顯示格式的規(guī)定，可能包括： 不同情況下文字的對齊方式； 不同情況下數字的表現格式與對齊方式 日期的表現方法與格式； 計時方法與時間格式； 等等。 錯誤信息顯示標準； 對于用戶界面的細節(jié)，例如

39、：一個特定對話框的布局，應該寫入 具體的用戶界面設計說明中，而不能寫入軟件需求規(guī)格說明中。 如果采用現成的、合適的用戶界面設計規(guī)范(標準)，或者另文描 述，可以在這里直接說明，并且將其加入參考文獻。 3.2 硬件接口硬件接口 描述待開發(fā)的軟件產品與系統(tǒng)硬件接口的特征，若有多個硬件接 口，則必須全都描述。接口特征的描述內容可能包括： 支持的硬件類型； 軟、硬件之間交流的數據； 控制信息的性質； 使用的通訊協(xié)議； 29 / 117 文檔可自由編輯 3.3 軟件接口軟件接口 描述該軟件產品與其它外部組件的連接，這些外部組件必須明確 它們的名稱和版本號以資識別，可能的外部組件包括： 操作系統(tǒng)； 數據庫

40、； 工具； 函數庫； 集成的商業(yè)組件 說明：這里所說的“集成的商業(yè)組件” ，是指與系統(tǒng)集成的商業(yè) 組件，而不是與軟件產品集成的商業(yè)組件。例如：中間件、消息服 務，等等。 描述并且明確軟件產品與軟件組件之間交換數據或者消息的目的。 描述所需要的服務，以及與內部組件通訊的性質。確定軟件產品將 與組件之間共享的數據。如果必須使用一種特殊的方法來實現數據 共享機制，例如：在多用戶系統(tǒng)中的一個全局數據區(qū)，那么就必須 把它定義為一種實現上的限制。 3.4 通訊接口通訊接口 描述與軟件產品所使用的通訊功能相關的需求，包括： 電子郵件； WEB 瀏覽器； 網絡通訊標準或者協(xié)議； 30 / 117 文檔可自由編

41、輯 數據交互用電子表格； 必須定義相關的： 消息格式； 通訊安全或加密問題； 數據傳輸速率； 同步和異步通訊機制； 4. 系統(tǒng)功能需求系統(tǒng)功能需求 需要進行詳細的需求記錄，詳細列出與該系統(tǒng)功能相關的詳細功 能需求，并且，唯一地標識每一項需求。這是必須提交給用戶的軟 件功能，使得用戶可以使用所提供的功能執(zhí)行服務或者使用所指定 的使用實例執(zhí)行任務。描述軟件產品如何響應己知的出錯條件、非 法輸入、非法動作。 如果每一項功能需求都能用一項，也只需要用一項測試用例就能 進行驗證，那么就可以認為功能需求已經適當地進行描述了。如果 某項功能需求找不到合適的測試用例，或者必須使用多項測試用例 才能驗證，那么該

42、項功能需求的描述必然存在某些問題。 功能需求是根據系統(tǒng)功能，即軟件產品所提供的主要服務來組織 的?？梢酝ㄟ^使用實例、運行模式、用戶類、對象類或者功能等級 來組織這部分內容，也可以便用這些元素的組合?？偠灾仨?選擇一種是讀者容易理解預期產品的組織方案。 用簡短的語句說明功能的名稱，例如：“4.1 系統(tǒng)參數管理” 。 31 / 117 文檔可自由編輯 按照服務組織的順序，逐條闡述系統(tǒng)功能。無論說明的是何種功能， 都應該針對該系統(tǒng)功能重復敘述 4.1 4.3 這三個部分。 可以通過各種方式來組織這一部分內容，例如采用：使用實例、 運行模式、用戶類、對象類、功能等級等，也可以采用它們的組合。 其

43、最終目的是，讓讀者容易理解即將開發(fā)的軟件產品。一般來說， 每個使用實例都對應一個系統(tǒng)功能，因而按照使用實例來組織內容 比較容易讓用戶理解。 對應一些被共享的獨立使用實例，可以定義一些公用系統(tǒng)功能。 必須特別注意的是，在 2.2 節(jié)“產品的功能”中描述的全部需求， 以及它們的規(guī)格說明；必須在某個系統(tǒng)功能描述中有所反映，而且 不應重復。 4.1 說明和優(yōu)先級說明和優(yōu)先級 對該系統(tǒng)功能進行簡短的說明，并且指出該系統(tǒng)功能的優(yōu)先級是： 高、中、還是低。需要的話，還可以包括對特定優(yōu)先級部分的評價， 例如：利益、損失、費用和風險，其相對優(yōu)先等級可以從 1(低)到 9(高)。 4.2 激勵響應序列激勵響應序列

44、 列出輸入激勵(用戶動作、來自外部設備的信號或者其它觸發(fā))并 且定義針對這功能行為的系統(tǒng)響應序列，這些序列將與使用實 例中相關的對話元素相對應。 32 / 117 文檔可自由編輯 描述激勵響應序列時，不僅需要描述基本過程，而且應該描述 可選(擴充)過程，包括例外(引起任務不能順序完成的情況稱為例外)。 疏忽了可選過程，有可能影響軟件產品的功能；如果遺漏例外過程， 則有可能會引發(fā)系統(tǒng)崩潰。 如果采用流程圖來描述激勵響應序列，比較容易讓用戶理解。 4.3 輸入輸出數據輸入輸出數據 列出輸入數據(用戶輸入、來自外部接口的輸入或者其它輸入)并 且定義針對這些輸入數據的處理(計算)方法，以及相應地輸出數

45、據， 描述對應區(qū)別：輸入數據和輸出數據。 當有大量數據需要描述時，也可以分類描述數據，并且注明各項 數據的輸入、輸出屬性。 對于每一項數據，均需要描述： 數據名稱； 實際含義； 數據類型； 數據格式； 數據約束； 對于復雜的處理方法，僅僅給出算法原理是不夠的，必須描述詳 細的計算過程，并且列出每一步具體使用的實際算式；如果計算過 程中涉及查表、判斷、迭代等處理方法，應該給出處理依據和相關 數據。如果計算方法很簡單，也可以將其從略，不加描述。 33 / 117 文檔可自由編輯 5. 其它非功能需求其它非功能需求 在這里列舉出所有非功能需求，主要包括可靠性、安全性、可維 護性、可擴展性、可測試性等

46、。 5.1 性能需求性能需求 闡述不同應用領域對軟件產品性能的需求，并且說明提出需求的 原理或者依據，以幫助開發(fā)人員做出合理的設計選擇。盡可能詳細 地描述性能需求，如果需要，可以針對每個功能需求或者特征分別 陳述其性能需求。在這里確定： 相互合作的用戶數量； 系統(tǒng)支持的并發(fā)操作數量； 響應時間； 與實時系統(tǒng)的時間關系： 容量需求 存儲器； 磁盤空間； 數據庫中表的最大行數。 5.2 安全措施需求安全措施需求 詳盡陳述與軟件產品使用過程中可能發(fā)生的損失、破壞、危害相 關的需求。定義必須采取的安全保護或動作，以及必須預防的潛在 危險動作。明確軟件產品必須遵從的安全標準、策略、或規(guī)則。 34 / 1

47、17 文檔可自由編輯 5.3 安全性需求安全性需求 詳盡陳述與系統(tǒng)安全性、完整性問題相關的需求，或者與個人隱 私問題相關的需求。這些問題將會影響到軟件產品的使用，和軟件 產品所創(chuàng)建或者使用的數據的保護。定義用戶身份認證，或備授權 需求。明確軟件產品必須滿足的安全性或者保密性策略。也可以通 過稱為完整性的質量屬性來闡述這些需求。一個典型的軟件系統(tǒng)安 全需求范例如下：“每個用戶在第一次登錄后，必須更改他的系統(tǒng) 預置登錄密碼，系統(tǒng)預置的登錄密碼不能重用。 ” 5.4 軟件質量屬性軟件質量屬性 詳盡陳述對客戶和開發(fā)人員至關重要的在軟件產品其它方面表現 出來的質量功能。這些功能必須是確定的、定量的、在需要時是可 以驗證的。至少也應該指明不同屬性的相對側重點，例如：易用性 優(yōu)于易學性，或者可移植性優(yōu)于有效性。 5.5 業(yè)務規(guī)則業(yè)務規(guī)則 列舉出有關軟件產品的所有操作規(guī)則，例如：那些人在特定環(huán)境 下可以進行何種操作。這些本身不是功能需求，但是他們可以暗示 某些功能需求執(zhí)行這些規(guī)則。一個業(yè)務規(guī)則的范例如下：“進行達 到或者超過 10，000，00 元人民幣的儲蓄業(yè)務時，必須通過附