軟體文檔編寫嚮導

2016/08/05 來源：CSDN博客

綜述：

在程式設計師的日常工作中，除了編寫代碼之外，還免不了需要編寫各種技術文檔。一個編寫良好的技術文檔在項目中能夠很好地建立溝通與協作，起到很積極的作用。因此，編寫技術文檔也就成為了程式設計師技能提升的很重要的一面。

為此，我們特意收集了一些在項目開發過程中經常用到的文檔模板，這些模板包括格式和簡單的寫作說明，相信能夠幫助大家編寫出更加高效、實用的技術文檔。在收集過程中，我們十分注重其實用性，以確保每個模板的價值，而且對於一些重要的文檔提供了多個模板。

為了方便大家查找，我們將收錄的57模板分為以下幾類：

1） 項目及開發管理類：包括立項前的分析，立項後的計劃、以及進度跟蹤、風險控制方面的文檔模板，共計16個；

2） 需求分析類：明確清晰的需求，是項目成功的基礎，在此收集了在需求分析過程中所將使用到的文檔模板，共計14個；

3） 系統分析與設計類：包括體系結構設計、高層設計、詳細設計、資料庫設計等6個相關文檔模板；

4） 軟體質量保證類：軟體測試是質量保證的關鍵活動，在此收集了軟體測試相關的11個文檔模板；

5） 其它類：除此之外，還收集了關於用戶手冊、軟體維護等方面的10個文檔模板，其中還有一個軟體過程規範的示例。

另外，值得說明的是，文檔模板只是為文檔的編寫提供一個基礎，在實際的編寫過程中，你可以根據自己的需要進行必要的剪裁和增補。

一、 項目及開發管理類

可行性研究報告(ISO標準)

編者說明：

在立項時，應該對項目進行綜合分析，探討項目的經濟、社會、技術可行性，從而為決策提供基礎。該模板為ISO標準文檔模板，其不僅適用於軟體項目，對於其它的系統項目也適用。

1. 引言

1.1 編寫目的

[編寫本可行性研究報告的目的，指出預期的讀者。]

1.2 背景

a.[所建議開發的軟體系統的名稱；]

b.[本項目的任務提出者、開發者、用戶及實現該軟體的計算站或計算機網絡；]

c.[該軟體系統同其他系統或其他機構的基本的相互來往關係。]

1.3 定義

[列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。]

1.4 參考資料

[列出用得著的參考資料。]

2. 可行性研究的前提

[說明對所建議開發的軟體的項目進行可行性研究的前提。]

2.1 要求

[說明對所建議開發的軟體的基本要求。]

2.2 目標

[說明所建議系統的主要開發目標。]

2.3 條件、假定和限制

[說明對這項開發中給出的條件、假定和所受到期的限制。]

2.4 進行可行性研究的方法

[說明這項可行性研究將是如何進行的，所建議的系統將是如何評價的，摘要說明所使用的基本方法和策略。]

2.5 評價尺度

[說明對系統進行評價時所使用的主要尺度。]

3. 對現有系統的分析

[這裡的現有系統是指當前實際使用的系統，這個系統可能是計算機系統，也可能是一個機械系統甚至是一個人工系統。]

[分析現有系統的目的是為了進一步闡明建議中的開發新系統或修改現有系統的必要性。]

3.1 處理流程和數據流程

[說明現有系統的基本的處理流程和數據流程。此流程可用圖表即流程圖的形式表示，並加以敘述。]

3.2 工作負荷

[列出現有系統所承擔的工作及工作量。]

3.3 費用開支

[列出由於運行現有系統所引起的費用開支。]

3.4 人員

[列出為了現有系統的運行和維護所需要的人員的專業技術類別和數量。]

3.5 設備

[列出現有系統所使用的各種設備。]

3.6 局限性

[列出本系統的主要局限性。]

4. 所建議的系統

4.1 對所建議系統的說明

[概括地說明所建議系統，並說明在第2條中列出的那些要求將如何得到滿足，說明所使用的基本方法及理論根據。]

4.2 處理流程和數據流程。

[給出所建議系統的處理流程式和數據流程。]

4.3 改進之處

[按2.2條中列出的目標，逐項說明所建議系統相對於現存系統具有的改進。]

4.4 影響

[說明新提出的設備要求及對現存系統中尚可使用的設備須作出的修改。]

4.4.1.對設備的影響

[說明新提出的設備要求及對現存系統中尚可使用的設備須作出的修改]

4.4.2.對軟體的影響

[說明為了使現存的應用軟體和支持軟體能夠同所建議系統相適應，而需要對這些軟體所進行的修改和補充。]

4.4.3.對用戶單位機構的影響

[說明為了建立和運行所建議系統，對用戶單位機構、人員的數量和技術水平等方面的全部要求。]

4.4.4.對系統運行過程的影響

[說明所建議系統對運行過程的影響。]

4.4.5.對開發的影響

[說明對開發的影響。]

4.4.6.對地點和設施的影響

[說明對建築物改造的要求及對環境設施的要求。]

4.4.7.對經費開支的影響

[扼要說明為了所建議系統的開發，統計和維持運行而需要的各項經費開支。]

4.5 技術條件方面的可能性

[本節應說明技術條件方面的可能性]

5. 可選擇的其他系統方案

[扼要說明曾考慮過的每一種可選擇的系統方案，包括需開發的和可從國內國外直接購買的，如果沒有供選擇的系統方案可考慮，則說明這一點。]

5.1 可選擇的系統方案1

[說明可選擇的系統方案1，並說明它末被選中的理由。]

5.2 可選擇的系統方案2

[按類似5。1條的方式說明第2個乃至第n個可選擇的系統方案。]

[……]

6. 投資及效益分析

6.1 支出

[對於所選擇的方案，說明所需的費用，如果已有一個現存系統，則包括該系統繼續運行期間所需的費用。]

6.1.1 基本建設投資

[包括採購、開發和安裝所需的費用。]

6.1.2 其他一次性支出

6.1.3 非一次性支出

[列出在該系統生命期內按月或按季或按年支出的用於運行和維護的費用。]

6.2 收益

[對於所選擇的方案，說明能夠帶來的收益，這裡所說的收益，表現為開支費用的減少或避免、差錯的減少、靈活性的增加、動作速度的提高和管理計劃方面的改進等，包括：

6.2.1 一次性收益]

[說明能夠用人民幣數目表示的一次性收益，可按數據處理、用戶、管理和支持等項分類敘述。]

6.2.2 非一次性收益

[說明在整個系統生命期內由於運行所建議系統而導致的按月的、按年的能用人民幣數目表示的收益，包括開支的減少和避免。]

6.2.3 不可定量的收益

[逐項列出無法直用人民幣表示的收益。]

6.3 收益/投資比

[求出整個系統生命期的收益/投資比值。]

6.4 投資回收周期

[求出收益的累計數開始超過支出的累計數的時間。]

6.5 敏感性分析

[是指一些關鍵性因素與這些不同類型之間的合理搭配、處理速度要求、設備和軟體的配置等變化時，對開支和收益的影響最靈敏的範圍的估計。]

7. 社會因素方面的可能性

7.1.[法律方面的可行性]

7.2.[使用方面的可行性]

8. 結論

[在進行可行性研究報告的編制時，必須有一個研究的結論]

軟體項目商業性分析[XuFeng1]

編者說明：

隨著市場經濟的不斷發展，一個項目的商業價值、市場價值往往是衡量項目價值的最大依據。該文檔模板十分適用於產品型項目，當你提出一個新的產品開發方向時，一份商業性分析是說服管理層的一個很好工具。

當然，如果是一些內部項目，也是可以借鑑該文檔模板來論證該項目的商業價值。

1. 文檔概述

[該部分主要描述該文檔的目的、範圍、術語以及參考資料等方面的內容。]

1.1 目的

[說明該文檔的作用。]

1.2 範圍

[簡要說明該與文檔相關的其它事物與資料。]

1.3 術語

[列出所有將出現於本文檔的新術語、縮略語等。]

1.4 參考資料

[在此應列出項目計劃中引用的文檔列表，對於引用的每個文檔都應該列出其標題、文檔編號、日期，並且指出這些文檔的來源，以方便該計劃的閱讀者查找。]

1.5 概述

[本小節說明該文檔所包括的內容，以及它的組織方式。]

2.系統說明

[在此簡要地說明將要開發的系統，包括其名稱、系統所解決的問題以及它的開發價值等，從而使得讀者能夠有一個直接的了解。並且在這處還應列出與在本文檔中出現的縮略詞的解釋，以便讀者更好地閱讀。]

3.業務環境

[這一小節主要說明要開發的系統所處於的業務環境。它包括系統所面向的領域、用戶。也可以在此指出它是產品型項目，還是用戶定製型項目，同時如果該項目與原有的項目有緊密的聯繫，在此也應該把這些聯繫列出來。]

4.產品目標

[這一小節則用於深入說明為什麼要開發該系統，它有什麼價值。最好還應對進度計劃、進度風險做一些評估。一個明確確定、表述清晰、可以度量的目標將為今後系統的開發工作打下堅實的基礎。]

5. 財務預測

[如果是產品型項目，那麼其輸出就是一個商業軟體產品。對於這樣的項目，在此應該包括對該項目的財務預測，最主要應該得出投資回報（ROI）指標。在做ROI分析時，應該針對不同的完成時間做出不同的預測，以讓系統開發者對於進度延遲對投資回報的損傷有一個直觀的了解。]

[在財務預測中，有一個基點就是對項目工作量、資源使用的估算，在這裡還應給出估算的基礎技術，當然這裡的估算會隨著項目的進展而逐步精化，應該這裡還是應該估算出一個合理的範圍。]

6. 約束

[任何事有利就有弊，在本小節則主要列舉執行該項目時會遇到的一個諸如外部接口、標準、認證、特殊的技術等約束，這些約速將會對項目帶來很大的執行風險，可能對項目的成本也帶來巨大的影響。]

軟體開發項目立項表

編者說明：

在許多開發組織中，開發立項請求通常來自市場部門，該表格的設計就是為了更好地理順兩個部門之間的溝通與協調，也使得開發立項流程化，你可以根據自己公司的實際情況，對該表格的格式做一些修改。

項目名稱(暫定)：

項目編號（開發部填寫）

問題/機會：

項目目標及成功標準：

目標描述：

假設、風險及障礙：

客戶名單：項目提出人：項目決策人：項目相關人員：

審批人意見：簽名： 日期：

軟體項目計劃(ISO標準)

編者說明：

拿破崙說過：「沒有一場戰役是按照計劃打的，而勝利的戰役沒有一個是沒有計劃的。」，戰役尚且如此，軟體項目也不例個。一個經過周密考慮，團隊協作共同制訂的項目計劃是成功的關鍵。本文檔模板是ISO標準模板，雖然時間有點久遠，但還是十分有參考價值的。

1. 引言

1.1 編寫目的

[說明編寫這份項目開發計劃的目的，並指出預期的讀者。]

1.2 背景

a. 待開發軟體系統的名稱；

b. 本項目的任務提出者、開發者、用戶及實現該軟體的計算中心或計算機網絡；

c. 該軟體系統同其他系統或其他機構的基本的相互來往關係。

1.3 定義

1.4 參考資料

2. 項目概述

2.1 工作內容

[簡要地說明在本項目的開發中須進行的各項主要工作。 ]

2.2 主要參加人員

[扼要地說明參加本項目開發工作的主要人員的情況，包括他們的技術水平。]

2.3 產品

2.3.1 程序

[列出需移交給用戶的程序的名稱、所用的程式語言及存儲程序的媒體形式，並通過引用有關文件。逐項說明其功能和能力。]

2.3.2.文件

[列出需移交給用戶的每種文件的名稱及內容要點。]

2.3.3.服務

[列出需向用戶提供的各項服務。 ]

2.3.4.非移交的產品

[說明開發集體應向本單位交出但不必向用戶移交的產品。 ]

2.4 驗收標準

[對於上述這些應交出的產品和服務，逐項說明或引用資料說明驗收標準。]

2.5 [完成項目的最遲期限]

2.6 [本計劃的批准者和批准日期]

3. 實施計劃

3.1 工作任務的分解與人員分工

[對於項目開發中需完成的各項工作，從需求分析、設計、實現、測試直到維護，包括文件的編制、審批、列印、分發工作，用戶培訓工作，軟體安裝工作等，按層次進行分解，指明每項任務的負責人和參加人員。]

3.2 接口人員

[說明負責接口工作的人員及他們的職責。]

3.3 進度

[對於需求分析、設計、編碼實現、測試、移交、培訓和安裝等工作，給出每項工作任務的預定的開始日期、完成日期及所需資源，規定各項工作任務完成的先後順序以及表徵每項工作任務完成的標誌性事件。]

3.4 預算

[逐項列出本開發項目所需要的勞務以及經費的預算和來源。]

3.5 關鍵問題

[逐項列出能夠影響整個項目成敗的關鍵問題、技術難點和風險，指出這些問題對項目的影響。]

4.支持條件

[說明為支持本項目的開發所需要的各種條件和設施。]

4.1 計算機系統支持

[逐項列出開發中和運行時所需的計算機系統支持，包括計算機、外圍設備、通訊設備、模擬器、編譯程序、作業系統、數據管理程序包、數據存儲能力和測試支持能力等，逐項給出有關到貨日期、使用時間的要求。]

4.2 需由用戶承擔的工作

[逐項列出需要用戶承擔的工作和完成期限，包括需由用戶提供的條件及提供時間。]

4.3 需由外單位提供的條件

[逐項列出需要外單位分合同承包者承擔的工作和完成的時間。]

5.專題計劃要點

[說明本項目開發中需制訂的各個專題計劃的要點。]

軟體項目計劃模板(2)

編者說明：

大家可能都發現了ISO標準的項目計劃缺少實用性，那是因為其未能很好地與WBS、甘特圖技術實現良好的結合。該文檔模板則充分考慮到這一點，其簡單、實用，適用於中小規模項目。

1.引言

1.1 計劃的目的

1.2 項目的範圍和目標

1.2.1 範圍描述

1.2.2 主要功能

1.2.3 性能

1.2.4 管理和技術約束

2.項目估算

2.1 使用的歷史數據

2.2 使用的評估技術

2.3 工作量、成本、時間估算

3. 風險管理戰略

3.1 風險識別

3.2 有關風險的討論

3.3 風險管理計劃

3.3.1 風險計劃

3.3.2 風險監視

3.3.3 風險管理

4.日程

4.1 項目工作分解結構

4.2 時限圖(甘特圖)

4.3 資源表

5.項目資源

5.1 人員

5.2 硬體和軟體

5.3 特別資源

6.人員組織

6.1 組織結構

6.2 管理報告

7.跟蹤和控制機制

7.1 質量保證和控制

7.2 變化管理和控制

8.附錄

軟體項目計劃模板(3)[XuFeng2]

編者說明：

如果項目規模較大，除了上一個模板中的內容之外，還應該加入許多分支內容，包括過程計劃、組織計劃、測試計劃、變更及管理計劃、文檔計劃等各多方面的問題，將這些內容的細化，將使項目計劃更全面、更周密。

第1部分 概述

1.1 目標

[這部分的目標是總結整個項目計劃。]

1.2 概述

[簡要描述要做的工作。給出所有理解工作環境所需的背景。然後闡述在合同下的項目任務。緊接著，說明項目如何組織。然後，在項目的基礎上列出假設和約束。]

1.3 詳述

[說明項目的總體時間進度。包括項目中的所有主要工作，無論是你能控制的還是不能控制的。如果你計劃發布多個版本，要說明如何安排進度。]

第2部分 過程計劃

2.1 目標

[這部分的目標是對用一系列稱為「過程」的時間段對開發活動加以定義，也就是確定該項目的開發將選用什麼樣的過程模型。]

2.2 概述

[定義你的開發生命周期，並且簡要說明生命周期的每個過程。]

2.3 詳述

2.3.1 定義過程

[主要目標：分析問題、製作項目計劃、定義接收標準、選擇項目工具。]

[次要目標：尋找人員、了解客戶、形成試驗性的設計思想。]

2.3.2 設計過程

[主要目標：設計操作性程序、設計支持性程序、改進項目計劃、進行項目評審。]

[次要目標：準備集成環境、建立變更管理、製作模擬模型、為下一個過程尋找人員、準備程式設計師培訓、出版程式設計師手冊、初步準備系統測試、驗收測試、現場測試、建立項目資料庫。]

2.3.3 編碼過程

[主要目標：詳細設計/編碼和模塊測試、模塊集成、文檔建立。]

[次要目標：詳細地準備系統測試、驗收測試、現場測試，準備客戶培訓、準備移植。]

2.3.4 系統測試過程

[主要目標：根據問題說明書進行系統測試、儘可能地「實況」測試、通過非程序開發人員測試。]

[次要目標：完成驗收測試準備、培訓客戶、更新描述性文檔、完成用戶文檔、再次分配人員。]

2.3.5 驗收過程

[主要目標：執行和分析驗收測試、簽署正式的接收協議。]

[次要目標：完成客戶培訓、清理文檔。]

2.3.6 移植過程

[主要目標：協助進行數據轉換、建立數據轉換標準、建立全面恢復計劃、定義移植順序、協助接入。]

[次要目標：與受影響組進行聯繫、支持評審過程。]

2.3.7 運行過程

[主要目標：協助初期運行。]

[次要目標：現場測試、繼續維護和調整、評價項目。]

第3部分 組織計劃

3.1 目標

[這部分的目標是定義項目的組織以及責任分配。]

3.2 概述

[說明建立組織的基本原因，畫出組織內部的主要工作流程圖，從問題的分析和設計開始，包括編碼、測試、製作文檔和交付。]

3.3 詳述

[在每個子部分中，列出基於組織章程的部分以及每個部分的責任，然後再說明在每個過程中組織的結構圖。]

3.3.1 部門及責任

[分析和設計部：編寫問題說明書、設計說明書、變更管理、數據控制、模擬模型、製作用戶文檔、協作集成測試。]

[編程部：詳細設計、編碼、模塊測試、集成測試、描述性文檔。]

[測試部：製作系統測試說明書、製作驗收和現場測試說明書、收集和製造測試數據、選擇和獲得測試工具、建立測試資料庫、安排測試資源進度、執行測試、分析測試結果、製作測試結果文檔。]

[行政部：資料管理、計算機時間控制、計劃和安裝終端和PC、發放程式設計師手冊、培訓、特殊技術協助、技術聯絡、文檔控制、報告控制、合同變更管理、提供雜務支持、維護項目歷史信息。]

3.3.2 組織章程

第4部分 測試計劃

4.1 目標

[這部分的目標是定義對軟體系統的所有級別測試的工具、過程和責任。]

4.2 概述

[簡要定義每個測試級別，並說明在一個測試層次上，不同級別如何組合在一起。]

4.3 詳述

4.3.1 單元測試

[在與其它功能模塊集成之前，針對單個程序模塊的測試。在此應列出單元測試的目標、責任、過程、工具。]

4.3.2 集成測試

[逐步將通過測試的模塊集成為更加複雜的集合，並且測試這些集合，直到整個軟體都被集合在一起。在此應列出集成測試的目標、責任、過程、工具。]

4.3.3 系統測試

[在儘可能真實的環境下，重新測試完成的軟體系統，應由非編程人員完成。在此應列出系統測試的目標、責任、過程、工具。]

4.3.4 驗收測試

[在用戶認可的條件下，試運行系統以驗證系統滿足了客戶的需求。在此應列出驗收測試的目標、責任、過程、工具。]

4.3.5 現場測試

[在不同的運行環境下測試軟體系統，以確保運行準備就緒，這並不是每個項目都需要的。在此應列出現場測試的目標、責任、過程、工具。]

4.3.6 共同測試設備

[描述在幾個或者所有級別的測試中共同的設備和工具，其中包括系統資料、計算機設備、桌面系統、作業系統、特殊語言、CASE工具、仿真器。]

4.3.7 測試支持程序

第5部分 變更管理計劃

5.1 目標

[這部分的目標是定義在軟體系統開發過程中，變更控制的過程。]

5.2 概述

[描述建立你和客戶都能夠接受的關鍵基線文檔以及控制與這些基線變化相關事件的需求。無論何時發生問題，基線文檔都是參考的關鍵。]

5.3 詳述

5.3.1 基線

[定義哪些文檔在你的項目中是基線。]

5.3.2 變更申請

[列出可能會提出變更的人員類別，以及提供相應的變更申請文檔。]

5.3.3 研究變更申請

5.3.4 變更的類型

[根據變更的基線影響的程序，設置不同的變更類型。]

5.3.5 變更管理會議

[明確變更管理會議的組成成員、召開時間以及具體的操作辦法。]

5.3.6 建議類型

[定義變更建議的類型，通常包括接受和拒絕兩種。]

5.3.7 執行變更

[定義執行變更的具體方法，通常包括評估變更成本、對變更進行審批、製作變更文檔、對變更後的進度進行重新安排、測試變更結果。]

第6部分 文檔計劃

6.1 目標

[這部分的目標是定義出版周期所要求過程與資源，以及列出基礎項目文檔組的框架結構。]

6.2 概述

[強調所有的項目文檔在這部分都列出結構框架。]

6.3 詳述

6.3.1 發布過程和責任

[通常包括準備和批准、打字輸入、校對和編輯、翻印、發放、電子存儲等。]

6.3.2 項目文檔大綱

[每個文檔的都包括以下部分：]

[a.項目標誌：用於標識項目文檔之用；]

[b.文檔名稱：標識主題，如問題說明書、設計說明書……]

[c.文檔編號：由項目資料員分配給文檔的唯一標識；]

[d.批准：在作為正式版本之前，文檔所需批准人的姓名。當然也不是所有文檔都需要經過批准。]

[e.發行日期]

[f.文檔主體：文檔的內容。]

6.3.3 文檔內容

[列出在該項目中將要使用的文檔模板的結構性內容。]

軟體項目計劃模板(4[XuFeng3])

編者說明：

隨著現代軟體工程思想的普及，疊代的、增量的開發生命周期已經被認識並付諸實踐，針對這樣的生命周期，其項目計劃的格式也需要做出相應的調整。

1. 文檔概述

[在此對整個文檔進行概要性描述，另外還應列出該計劃的目標、範圍、定義、術語、參考資料等內容。]

1.1 目標

[在此描述本項目計劃的目標。]

1.2 範圍

[簡要說明該計劃所覆蓋的範圍，以及與其相關的項目，與該文檔有聯繫的事物。]

1.3 定義與術語

[在此列出在該計劃中所涉及的所有術語、定義、縮寫詞的解釋，這些信息也可以引用項目詞彙表來提供。]

1.4 參考資料

1.5 概述

[說明該計劃其它部分所包含的內容，以及文檔的組織方式。]

2. 項目概述

項目目標

[指出該項目將會交付什麼樣的產品，能夠幫助客戶達到什麼目標。]

假設與約束

[列舉出制定該計劃時所做的所有假設，以及列舉出對該項目的解決方案的約束性要求，如特定的作業系統平台、特定的時間、特定的經費範圍等。]

項目交付物

[具體列出該項目完成後，將交付哪些東西，並可以列出每個交付時間。]

項目計劃更新總結

[建議採用表格的形式，將計劃的修訂過程列出來。]

3. 項目組織

項目組織結構

[建議使用組織結構圖的形式，將整個項目團隊成員之間的關係與職責明確下來，甚至可以包括管理人員、各種委員會等。]

外部聯繫人

[列出開發組織之外的，所有與項目相關的外部人員的姓名、聯繫電話等資料。]

角色與職責

[明確項目開發各個任務的負責人或小組。]

4. 項目管理計劃

項目估計

[給出關於項目成本、進度的估計值，這些估計值將是項目計劃制定的基礎，也是今後重新評估、修改計劃的基礎。你可以採用任何估算技術。]

項目計劃

4.2.1 階段計劃

[主要包括工作結構分解（WBS）、顯示各個階段或疊代時間安排的甘特圖、主要里程碑與其驗收標準。]

4.2.2 疊代目標

[如果你採用的是疊代式的開發方法，那麼在此列出每次疊代的計劃，以及每次疊代計劃實現的目標。]

4.2.3 發行計劃

[列出軟體開發過程中各個中間版本的發行時間，包括演示版、Alpha版、Beta版等。]

4.2.4 項目進度表

[使用甘特圖或PERT圖等方法，表示出該項目的進度計劃。]

4.2.5 項目資源計劃

[在此處應列出項目所需的人員、設備等資源情況。應指明所需人員的數量、技能要求，以及如何獲取這些資源，是否要對人員進行必要的培訓等。]

4.2.6 項目預算

[根據WBS和階段計劃分配成本，得到本項目的財務預算。]

疊代計劃

[根據4.2.2小節的目標，具體列出每次疊代的詳細計劃。該部分可以視需要將其單列為專題計劃。]

4.3.1 疊代一

4.3.1.1 計劃

[列出此次疊代的時間線、小型里程碑等。]

4.2.1.2 資源

[列出此次疊代所需的人力、財力、設備等資源。]

4.2.1.3 用例

[列出此次疊代將要實現的用例。]

4.2.1.4 評估標準

[列出此次疊代的各項評測標準，包括功能、性能、容量、質量等。]

項目監督與控制

4.4.1 需求管理計劃

[有針對性對制定各類需求元素的管理與跟蹤辦法。該部分可以視需要將其單列成為專題計劃。]

4.4.2 進度控制計劃

[說明如何對項目計劃執行情況進行監控，將採用什麼措施與管理手段。]

4.4.3 預算控制計劃

[說明如何對項目的財務預算進行控制，以保證成本最小化。]

4.4.4 質量控制計劃

[說明如何保證項目的質量，以及一些應急的應對措施。該部分可以視需要將其單列成為專題計劃。]

4.4.5 報告計劃

[說明項目開發過程中，整個項目團隊的報告機制，什麼時候、誰、報送什麼數據，從而形成規則。]

4.4.6 評測計劃

[制定項目開發過程中將要度量與評測的指標，說明如何評測，如何應對。該部分可以視需要將其單列成為專題計劃。]

4.5 風險管理計劃

[該部分可以視需要將其單列為專題計劃。]

4.5.1 風險總述

[對項目所涉及的風險進行一個概要性描述。]

4.5.2 風險管理任務

[簡要地說明在該項目中，風險管理所涉及的內容，可以包括用來確定風險的方法、對風險列表進行分析和確定優先級的方式、將採用的風險管理策略、對最嚴重的風險所計劃的降低/規避或預防的策略、監測風險狀態的方式、風險覆審的時間表。]

4.5.3 風險管理的組織和職責

[列出與風險管理相關的個人或小組，並對其職責進行描述。]

4.5.4 工具與技術

[列出與風險管理將採用的工具軟體或技術。]

4.5.5 納入管理的風險項

[列出主要的風險項，並描述其影響以及應急措施。具體可以參考後面的《風險條目跟蹤表模板》。]

4.6 收尾計劃

[列出在項目後期將要做的事，包括材料存檔、匯報總結等。]

5. 相關技術

5.1 開發案例

[給出本項目將採用的軟體生命周期模型、過程規範等，從而對開發過程給予明確的指導。該部分可以視需要將其單列為一個專題文件。]

5.2 方法、工具和技術

[列出本項目中將運用的方法、工具和技術，並給出適當的工作指南和說明。]

5.3 產品驗收計劃

[列出本項目驗收工作的一些細節計劃，本部分內容可以視需要將其單列為一個專題計劃。]

6．其它支持過程管理

6.1 配置管理計劃

[在此列出該項目所採用的配置管理過程，通常是單列為一個專題。]

6.2 評估計劃

[列出本項目評估時所使用的技術、標準、指標和過程。這裡的評估包括走查、檢查和覆審。]

6.3 文檔計劃

6.4 質量保證計劃

6.5 分包商管理計劃

7.其他計劃

8.附錄

9.索引

風險條目跟蹤表模板

編者說明：

對於中型以上的項目，風險控制的意義就猶為突出。要控制風險，就應該找到風險，並將風險記錄下來，確定相關責任人，對於風險性高的、可能性大的還需要制訂相關的應對措施。而最好的方法就是整理成為本模板中的表格，為每個潛在風險備個案。

序列號	<順序號
確定日期	<風險被識別出的日期
撤消日期	<撤消風險確定日期
描述	<以"條件-結果"的形式描述風險
可能性	<風險轉變為問題的可能性 註：可用0.1(極不可能)~1.0(肯定發生)來表示
影響	<如果風險變成了事實獎造成的損失 註：可用1(無甚麼影響)~10(有很深、很大的影響)來表示
危害值	<可能性＊影響
降低風險計劃	<一種或多種用來控制、避免、最小化及降低風險的方法
負責人	<解決風險的責任承擔者
截止日期	<完成降低風險措施的截止日期

進度計劃風險列表[XuFeng4]

編者說明：

準確來說，本列表不是一個文檔模板，而是一個參考文章。由於風險識別許多人都覺得無從入手，下面就是列出了與進度相關的風險條目，對於風險識別有很大的參考價值。

1.最常見的進度計劃風險

1） 功能無限蔓延；

2） 需求鍍金或開發人員鍍金；

3） 質量不定

4） 計劃過於樂觀

5） 設計欠佳

6） 銀彈綜合症

7） 研發導向開發

8） 人員薄弱

9） 簽約商失敗；

10）研發人員與客戶的磨擦。

2.進度計劃風險完整列表

2.1 計劃編制風險

1） 計劃、資源和產品定義全憑客戶或上層領導口頭指令，並且不完全一致；

2） 計劃是優化的，是「最佳狀態」；

3） 計劃忽略了必要的任務；

4） 計劃基於使用特定的小組成員，而那個小組成員其實指望不上。

5） 在限定的時間內無法建成已定規模大小的產品；

6） 產品規模比估計的要大一些；

7） 工作量大於估算數；

8） 進度已經拖延的項目在重新評估時過於優化或忽視項目歷史；

9） 過度的進度壓力造成生產率下降；

10）目標日期提前，但沒有相應地調整產品範圍或可用資源；

11）一個任務的延遲導致相關任務的連鎖反應；

12）涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。

2.2 組織和管理

1） 項目缺乏一個有凝聚力的最高領導人；

2） 由於前期乏力，項目長時間被擱置；

3） 解僱和削減開支導致項目小組能力下降；

4） 僅由管理層或市場人員進行技術決策，導致計劃進度延長；

5） 低效的項目組結構降低生產率；

6） 管理層審查/決策的周期比預期時間長；

7） 預算削減打亂項目計劃；

8） 管理層做出了打擊項目組織積極性的決定；

9） 非技術的第三方的工作比預期延長（如審批，採購等）；

10）計劃性太差，無法適應期望的開發速度；

11）項目計劃由於壓力而放棄，導致開發混亂、低效；

12）管理層強調英雄主義，而忽視客觀確切的狀態報告，這會降低發現和改正問題的能力。

2.3 開發環境

1） 設施沒有及時到位；

2） 設施到位，但不配套；

3） 設施擁擠、雜亂或者破損；

4） 開發工具未能及時到位；

5） 開發工具不如期望那樣有效，開發人員需要時間創建工作環境或切換新的工具；

6） 開發工具的選擇不是基於技術需求，不能提供計劃要求的性能；

7） 新開發工具的學習期比預期的長，內容繁多。

2.4 最終用戶

1） 最終用戶堅持新的需求；

2） 最終用戶對於最後交付的產品不滿意，要求重新設計和重做；

3） 最終用戶不買進項目產品，無法提供後續支持；

4） 最終用戶的意見未被採納，造成產品最終無法滿足用戶期望，而必須重做。

2.5 客戶

1） 客戶堅持新的需求；

2） 客戶對規劃、原型和規格的審核/決策周期比預期長；

3） 客戶沒有或不能參與規劃、原型和規格階段的審核，導致需求不穩定和耗時的重複；

4） 客戶答覆的時間比預期長（如回答需求中需澄清的問題）；

5） 客戶堅持技術決策而導致進度計劃延長；

6） 客戶對開發進度管理過細，導致實際進展變慢；

7） 客戶提供的組件無法與開發的產品匹配，導致額外的設計和集成工作；

8） 客戶提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關係管理工作；

9） 客戶要求的支持工具和環境不兼容、性能差或者功能不完善，導致生產率降低；

10）客戶不接受交付的軟體，儘管它滿足了所有的規格；

11）客戶期望的開發速度是開發人員無法達到的。

2.6 承包商

1） 承包商沒有按承諾交付組件；

2） 承包商遞交的組件質量低下無法接收，必須花時間改進質量；

3） 承包商沒有買進項目開發需要的工具，進而無法提供需要的性能水平。

2.7 需求

1） 需求已經成為項目基準，但變化還在繼續；

2） 需求定義欠佳，而進一步的定義會擴展項目範疇；

3） 添加額外的需求；

4） 產品定義含混的部分比預期需要更多的時間。

2.8 產品

1） 錯誤發生率高的模塊需要比預期更多的測試、設計和實現工作；

2） 校正質量低下不可接受的產品，需要比預期更多的測試、設計和實現工作。

3） 在一個或多上新興領域推廣計算機技術使得計劃進度的延長不可預期；

4） 由於軟體功能的錯誤，需要重新設計和實現；

5） 開發額外不需要的功能（鍍金）延長了計劃進度；

6） 要滿足產品規格與速度要求，需比預期更多時間，包括重新設計和實現的時間；

7） 嚴格要求與現有系統兼容，需要進行比預期更多的測試、設計和實現工作；

8） 要求與其他系統、複雜系統或不受本項目控制的系統相連，導致無法預料的設計、實現和測試工作。

9） 要求在不同作業系統下運行將花費比預期更長的時間；

10）在不熟悉或未經檢驗的軟（硬）件環境中運行產生未預料的問題；

11）開發一種對組織全新的模塊將比預期花費更長的時間；

12）依賴正在開發中的技術將延長計劃進度。

2.9 外部環境

1） 產品依賴政府規章，而規章的改變將是不可預期的；

2） 產品依賴草擬中的技術標準，而最後的標準將是不可預期的。

2.10 人員

1） 招聘人員所花時間比預期的長；

2） 作為先決條件的任務不能按時完成（如培訓、其它項目）；

3） 開發人員和管理層之間關係不佳導致決策緩慢，影響全局；

4） 項目組成員沒有全身心投入項目，進而無法達到需要的產品性能水平；

5） 缺乏激勵措施，士氣低下，降低了生產能力；

6） 缺乏必要的規範，增加了工作失誤與重複工作；

7） 某些人需要更多時間適應不熟悉的軟體工具和環境、硬體環境、程式語言；

8） 項目結束前，合同制人員離開團隊，或雇員辭職；

9） 項目後期加入新的開發人員，額外的培訓和溝通降低現有成員的效率；

10）項目組成員不能有效地一起工作；

11）由於項目組成員間的衝突，導致溝通不暢、設計欠佳、接口錯誤和額外的重複工作；

12）有問題的成員沒有調離項目組，損害了項目組其他成員的積極性；

13）項目的最佳人選未加入項目組；

14）項目的最佳人選已加入項目組，但因其他原因未能合理使用；

15）沒有找到項目急需的具有特定技能的人；

16）關鍵人物只能兼職參與；

17）項目人員不足；

18）任務的分配與人員技能不匹配；

19）人員工作的進展比預期的慢；

20）項目管理人員怠工導致計劃和進度失效；

21）技術人員怠工導致工作遺漏或質量低下，工作需要重做。

2.11 設計與實現

1） 設計過於簡單，無法確定主要事件，並導致重新設計和實現；

2） 設計過於複雜，導致一些不必要的工作，影響實現效率；

3） 設計質量低下，導致重複設計和實現

4） 使用不熟悉的方法，導致額外的培訓時間，並重犯前期使用這種方法時導致的錯誤；

5） 產品採用低級語言來實施，導致生產率比預期的低；

6） 一些必要的功能無法使用現有的代碼和庫實現，開發人員必須使用新庫或自選開發所要的功能；

7） 代碼和庫質量低下，導致需要額外的測試、錯誤修正或重做；

8） 過高估計了增強型工具對計劃進度的節省量；

9） 分別開發的模塊無法有效集成，需要重新設計或重做。

2.12 過程

1） 大量的紙面工作導致進程比預期的慢；

2） 進程跟蹤不準確，導致無法預知項目是否已落後於計劃進度；

3） 前期的質量保證行為不真實，導致後期的重複工作；

4） 質量跟蹤不準確，導致無法得知影響進度的質量問題；

5） 太不正規，導致溝通不足，質量問題和工作重做；

6） 過於正規，導致過多耗時無用的工作；

7） 向管理層撰寫進度報告占用的開發人員的時間比預期的多；

8） 風險管理粗心，導致沒有發現重大的項目風險；

9） 軟體項目風險管理花費的時間比預期的多。

開發進度月報(ISO標準)

編者說明：

計劃需要跟蹤進度來進行適當的調整，因此在開發組織內應該形成良好的進度匯報機制，ISO標準模板也對這一塊提供了參考。這一文檔格式十分全面，不過也略顯繁瑣，適合於中型以上項目。

l．標題

開發中的軟體系統的名稱和標識符 分項目名稱和標識符 分項目負責人簽名 本期月報編寫人簽名 本期月報的編號及所報告的年月

2．工程進度與狀態

2.1 進度

[列出本月內進行的各項主要活動，並且說明本月內遇到的重要事件，這裡所說的重要事件是指一個開發階段（即軟體生存周期內各個階段中的某一個，例如需求分析階段）的開始或結束，要說明階段名稱及開始（或結束）的日期。]

2.2 狀態

[說明本月的實際工作進度與計劃相比，是提前了、按期完成了、或是推遲了？如果與計劃不一致，說明原因及準備採取的措施。]

3．資額耗用與狀態

3.1 資額耗用

[主要說明本月份內耗用的工時與機時。]

3.1.1 工時

[分為三類：]

[a. 管理用工時 包括在項目管理（制訂計劃、布置工作、收集數據、檢查匯報工作等）方面耗用的工時； ]

[b. 服務用工時 包括為支持項目開發所必須的服務工作及非直接的開發工作所耗用的工時；]

[c. 開發用工時 要分各個開發階段填寫。]

3.1.2 機時

[說明本月內耗用的機時，以小時為單位，說明計算機系統的型號。]

3.2 狀態

[說明本月內實際耗用的資源與計劃相比，是超出了、相一致、還是不到計劃數？如果與計劃不一致，說明原因及準備採取的措施。]

4 經費支出與狀態

4.1 經費支出

4.1.1 支持性費用

[列出本月內支出的支持性費用，一般可按如下七類列出，並給出本月支持費用的總和：]

[ a. 房租或房屋折舊費；]

[b. 員工工資、獎金、補貼；]

[c. 培訓費包括給教師的酬金及教室租金；]

[d. 資料費包括複印及購買參考資料的費用；]

[e. 會議費召集有關業務會議的費用；]

[f. 旅差費；]

[g. 其他費用。]

4.1.2 設備購置費

[列出本月內支出的設備購置費，一般可分如下三類：]

[[a. 購買軟體的名稱與金額；]

[b. 購買硬設備的名稱、型號、數量及金額；]

[c. 已有硬設備的折舊費。]

4.2 狀態

[說明本月內實際支出的經費與計劃相比較，是超過了。相符合、還是不到計劃數？如果與計劃不一致，說明原因及準備採取的措施。]

5．下個月的工作計劃

6．建議

[本月遇到的重要問題和應引起重視的問題以及因此產生的建議。]

開發任務卡

編者說明：

項目中應該實現責任到人，項目的進度應該是每個項目成員個人進度表的總匯集，而開發任務卡則是項目與項目成員的約定，也是項目管理的一個好辦法。大家可以根據自己的實際情況來修改該模板。

項目名： 模塊/類名：

安排時間： 任務承擔人：

模塊/類名

負責人

開始時間

完成時間

狀態

估計完成時間： 批准人：

個人開發進度月報

編者說明：

表格式的進度報表能夠節省製作時間，縮短進度誤差。對於中型以上項目，特別是成員的任務超過了1個月，那麼讓每個開發人員填寫進度月報就是一個很好的管理辦法。當然，如果成員的任務都較小，則無需使用該文檔，只需對工作任務卡進行檢查就可以了。

1．標題

報告時間：年月日至年月日

報告人：〈簽名〉

2．進度

2.1 任務

任務：<任務名

狀態： □完成 □未完成

與計劃比較： □提前 □按期 □推遲

推遲原因：

3．資源耗費

總用工時：

機時：

上網時間：

硬體平台：

軟體環境和工具：

4.下個月工作計劃

任務描述：

任務所屬項目或子項目：

性質： □新 □續上月

5.建議

項目開發進度月報

編者說明：

項目進度月報是必須的管理機制，而長篇大論不僅浪費了大家的時間，而且也使得進度的收集與實際情況有一些時間上的誤差，因而可以採用表格化的報表格式。

1.

項目名稱及標識：

子項目名稱及標識：

本期月報編寫人：〈簽名〉

子項目負責人：〈簽名〉

月報日期： 年 月 日

2.進度

2.1 任務

任務：<任務名>

狀態： □ 完成 □未完成

推遲原因：

2.2 事件

事件：<事件名>

推遲原因：

3.資源耗費

3.1 工時

總 計：

3.2 機時

計算機類型：	用時：
總 計：	用時：

4.經費支出

4.1 支持性經費支出

工資、獎金、補貼：

培訓費：

會議費：

差旅費：

總計：

4.2 設置購置費

設備名稱	型號	數量	單價	金額
總計金額：

5.下個月工作計劃

5.1 任務

任務：<任務名>

性質： □新 □續上月

5.2 事件

事件：<事件名>

事件標誌：

性質： □新 □舊

6.建議

項目進度周報

編者說明：

月報通常需要較詳細，而周報則應該更簡潔，每周讓項目經理花上1-2分鐘將一周的項目進度情況做一個通報是很必要的。本文檔模板就是一個例子，供大家參考。

周期：2003年__月__日~2003年__月___日

項目名稱： 項目編號：

項目經理： 項目發起人：

項目成員：

項目計劃開始時間： 項目實際開始時間：

項目預計完成時間： 現在預計完成時間：

項目預計投入人力：人/日 現在已投入人力：人/日

預計共需投入人力：人/日

項目遇到的困難和要解決的問題：

項目開發總結報告(GB標準)

編者說明：

在項目中犯錯誤是正常的，但是犯同樣的錯誤則是不可原諒的。因此，我們應該善於在項目中總結、在實踐中總結。在項目結束的時候，所有的成員匯集在一起，回顧一下項目的過程，總結出錯誤，找到解決的辦法，總結出經驗，將這些經驗復用到下一個項目中。然後形成本文檔，共享給大家。

1．引言

1.1 編寫目的

[說明編寫這份項目開發總結報告的目的，指出預期的閱讀範圍。]

1.2 背景

[說明：]

[ a. 本項目的名稱和所開發出來的軟體系統的名稱；]

[b. 此軟體的任務提出者、開發者、用戶及安裝此軟體的計算中心。]

1.3 定義

[列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。]

1.4 參考資料

[列出要用到的參考資料，如：]

[a. 本項目的已核准的計劃任務書或合同、上級機關的批文；]

[b. 屬於本項目的其他已發表的文件；]

[c. 本文件中各處所引用的文件、資料，包括所要用到的軟體開發標準。]

[列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。]

2．實際開發結果

2.1 產品

[說明最終製成的產品，包括：]

[a. 程序系統中各個程序的名字，它們之間的層次關係，以千字節為單位的各個程序的程序量、存儲媒體的形式和數量；]

[b. 程序系統共有哪幾個版本，各自的版本號及它們之間的區別；]

[c. 每個文件的名稱；]

[d. 所建立的每個資料庫。如果開發中制訂過配置管理計劃，要同這個計劃相比較。]

2.2 主要功能和性能

[逐項列出本軟體產品所實際具有的主要功能和性能，對照可行性研究報告、項目開發計劃、功能需求說明書的有關內容，說明原定的開發目標是達到了、未完全達到、或超過了。]

2.3 基本流程

[用圖給出本程序系統的實際的基本的處理流程。]

2.4 進度

[列出原定計劃進度與實際進度的對比，明確說明，實際進度是提前了、還是延遲了，分析主要原因。]

2.5 費用

[列出原定計劃費用與實際支出費用的對比，包括：]

[a. 工時，以人月為單位，並按不同級別統計；]

[b. 計算機的使用時間，區別CPU時間及其他設備時間；]

[c. 物料消耗、出差費等其他支出。]

[明確說明，經費是超出了、還是節餘了，分析其主要原因。]

3．開發工作評價

3.1 對生產效率的評價

[給出實際生產效率，包括：]

[a. 程序的平均生產效率，即每人月生產的行數；]

[b. 文件的平均生產效率，即每人月生產的千字數；]

[並列出原訂計劃數作為對比。]

3.2 對產品質量的評價

[說明在測試中檢查出來的程序編制中的錯誤發生率，即每干條指令（或語句）中的錯誤指令數（或語句數）。如果開發中制訂過質量保證計劃或配置管理計劃，要同這些計劃相比較。]

3.3 對技術方法的評價

[給出對在開發中所使用的技術、方法、工具、手段的評價。]

3.4 出錯原因的分析

[給出對於開發中出現的錯誤的原因分析。]

4．經驗與教訓

[列出從這項開發工作中所得到的最主要的經驗與教訓及對今後的項目開發工作的建議。 ]

模塊開發卷宗(GB標準)

編者說明：

當一個項目完成之後，應該將所有的文檔、源程序、可執行文檔進行整理打包，統一入庫，而模塊開發卷宗則是這些文檔的封面。有了該文檔，就可以使得下次找這些資料時更加方便。

第1章 模塊開發情況

模塊名:		模塊標識符
代碼設計	計劃開始日期	實際開始日期
	計劃完成日期	實際完成日期
模塊測試	計劃開始日期	實際開始日期
	計劃完成日期	實際完成日期
組裝測試	計劃開始日期	實際開始日期
	計劃完成日期	實際完成日期
原始碼行	預計行數	實際行數
目標模塊大小	預計字節數	實際字節數
代碼複查 （日期/簽字）
批 准 （日期/簽字）

第2章 功能說明

輸入

處理

輸出

3.1 層次說明

模塊名	模塊標識符
調用模塊
被調用模塊

3.2 算法（Ｎ－Ｓ圖、ＰＡＤ圖或ＰＤＬ語言）

3.3 外部數據結構

數據結構名稱	關係
<生成/使用關係

3.4 出錯信息

5.1 測試名稱1

測試標識符：		編號：
測試目的：
測試配置：
測試用例：
序號	輸入		預期輸出		實際輸出

5.2 測試名稱2

…………

第6章 覆審結論

6.1 與需求說明的比較

6.2 與概要設計的比較

6.3 與詳細設計的比較

6.4 一般結論

二、需求分析類

編者說明：

許多有經驗的開發團隊在開始需求調查的時候，總會將「軟體客戶需求權利書」和「軟體客戶需求義務書」提交給客戶，讓客戶明確其權利與義務，將會對需求調研、分析的工作帶來意想不到的效果，你可以一試。

軟體客戶需求權利書

1.要求分析人員使用符合客戶語言習慣的表達；

2.要求分析人員了解客戶系統的業務及目標；

3.要求分析人員組織需求獲取期間所介紹的信息，並編寫軟體需求規格說明。

4.要求開發人員對需求過程中所產生的工作結果進行解釋說明；

5.要求開發人員在整個交流過程中保持和維護一種合作的職業態度；

6.要求開發人員對產品的實現及需求都要提供建議，拿出主意。

7.描述產品使其具有易用、好用的特性；

8.可以調整需求，允許重用已有的軟體組件；

9.當需要對需求進行變更時，對成本、影響、得失有個真實可信的評估；

10.獲得滿足客戶功能和質量要求的系統，並且這些要求是開發人員同意的。

軟體客戶需求義務書

1.給分析人員講解業務及說明業務方面的術語等專業問題；

2.抽出時間清楚地說明需求並不斷完善；

3.當說明系統需求時，力求準確詳細；

4.需要時要及時對需求做出決策；

5.要尊重開發人員的成本估算和對需求的可行性分析；

6.對單項需求、系統特性或使用實例劃分優先級；

7.評審需求文檔和原型；

8.一旦知道要對項目需求進行變更，要馬上與開發人員聯繫；

9.在要求需求變更時，應遵造開發組織確定的工作過程來處理；

10.尊重需求工程中開發人員採用的流程（過程）。

軟體項目視圖和範圍

編者說明：

項目所涉及的內容與所解決的問題都是有限的，而且項目應該是十分有目的性的，是為了實現某個可度量的目標而做的。因此，在需求分析的前期應該將「項目的目標與範圍」這一項目的本質文檔化，讓每一個項目成員對其達成共識。該文檔是十分重要，但卻又是十分容易被忽視的。該文檔模板比較適用於定製開發項目。

1.業務需求

[業務需求說明了提供給客戶和產品開發商的新系統的最初利益。不同產品可能會有不同的側重點。本部分描述了你為什麼要從事此項項目的開發，以及它將給開發者和購賣者帶來的利益。]

1.1 背景

[在這一部分，總結新產品的理論基礎，並提供關於產品開發的歷史背景或形勢的一般性描述。]

1.2 業務機遇

[描述現存的市場機遇或正在解決的業務問題。描述商品競爭的市場和信息系統將運用的環境。包括對現存產品的一個簡要的相對評價和解決方案，並指出所建議的產品為什麼具有吸引力和它們所能帶來的競爭優勢。認識到目前只能使用該產品才能解決的一些問題，並描述產品是怎樣順應市場趨勢和戰略目標的。]

1.3 業務目標

[用一個定量和可測量的合理方法總結產品總結產品所帶來的重要商業利潤。關於給客戶帶來的價值在後面闡述，這裡僅把重點放在給業務的價值上。這些目標與收入預算或節省開支有關，並影響到投資分析和最終產品的交付日期。]

1.4 客戶或市場需求

[描述一些典型客戶的需求，包括不滿足現在市場上的產品或信息系統的需求。提出客戶目前所遇到的問題在新產品中將可能（或不可能）出現的闡述，提供客戶怎樣使用產品的例子。確定了產品所能運行的軟、硬體平台。定義了較高層次的關鍵接口或性能要求，但避免設計或實現細節。把這些要求寫到列表中，可以反過來跟蹤調查特殊用戶和功能需求。]

1.5 提供給客戶的價值

[確定產品給客戶帶來的價值，並指明產品怎樣滿足客戶的需要。可以用下列言辭表達產品帶給客戶的價值：

Ø 提高生產效率，減少返工；

Ø 節省開支；

Ø 業務過程的流水線化；

Ø 先前人工勞動的自動化；

Ø 符合相關標準和規則；

Ø 與目前的應用產品相比較，提高了可用性或減少了失效程度。]

1.6 業務風險

[總結開發（或不開發）該產品有關的主要業務風險，例如市場競爭、時間問題、用戶的接受能力、實現的問題或對業務可能帶來的消極影響。預測風險的嚴重性，指明你所能採取的減輕風險的措施。]

2.項目視圖的解決方案

[文檔中的這一部分為系統建立了一個長遠的項目視圖，它將指明業務目標。這一項目視圖為在軟體開發生存期中作出決策提供了相關環境背景。這部分不包括詳細的功能需求和項目計劃信息。]

2.1 項目視圖陳述

[編寫一個總結長遠目標和有關開發新產品目的的簡要項目視圖陳述。項目視圖陳述將考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場企業框架。組織的戰略方向和資源局限性為基礎。]

[如："化學製品跟蹤系統"可使科學家查詢到化學製品倉庫或供應商將提供的化學製品容器。系統可隨時了解公司每一個化學製品容器所處的位置，容器中所剩餘的藥品劑量，任何時候每個容器所處的位置和用法的歷史記錄。通過充分利用公司內部的可用化學製品，廢棄極少量已使用或過期失效的化學製品，使用標準的化學製品的購買過程等將在化學製品上節省25%開支。"化學製品跟蹤系統"還能產生符合政府部門規定所要求的全部報表，包括化學製品的使用、存儲和廢棄等報表。]

2.2 主要特徵

[包括新產品將提供的主要特性和用戶性能的列表。強調的是區別於以往產品和競爭產品的特性。可以從用戶需求和功能需求中得到這些特性。]

2.3 假設和依賴環境

[在構思項目和編寫項目視圖和範圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。如果你把它們都記錄下來，並加以評論，就能對項目內部隱含的基本假設達成共識。比如，"化學製品跟蹤系統"的開發者假設：該系統可以替代現有的倉庫存貨系統，並能與有關採購部門的應用相連接。把這些都記錄下來以防止將來可能的混淆和衝突。還有，記錄項目所依賴的主要環境，比如：所使用的特殊的技術、第三方供應商、開發夥伴及其它業務關係。]

3.範圍和局限性

[項目範圍定義了所提出的解決方案和概念和適用領域，而局限性則指出產品所不包括的某些性能。如果一般客戶所提出的需求超出項目的範圍時就應當拒絕它，除非這些需求是很有益的。記錄這些需求以及拒絕它們的原因，以待查。]

3.1 首次發行的範圍

[總結首次發行的產品所具有的性能。描述了產品的質量特性，這些特性使產品可以為不同的客戶群提供預期的成果。應當避免將想到的每一個特性都包括到1.0版本產品中去。開發者應把重點放在能提供最大價值、花花費最合理的開發費用及普及率最高的產品上。]

3.2 隨後發行的範圍

[如果你想像一個周期性的產品演變過程，就要指明哪一個主要特性的開發將被延期，並期待隨後版本發行的日期。]

3.3 局限性和專用性

[明確定義包括和不包括的特性和功能的界線是處理範圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到產品中的特性和功能。]

4.業務環境

[這一部分總結了一些項目的業務問題。]

4.1 客戶概貌

[客戶概述明確了這一產品的不同類型客戶的一些本質特點，以及目標市場部門和在這些部門中的不同客戶的特徵。對於每一種客戶類型，概述要包括：

Ø 各種客戶類型將從產品中獲得的主要益處；

Ø 它們對產品所持的態度；

Ø 感興趣的關鍵產品的特性；

Ø 哪一類型客戶能成功使用；

Ø 必須適應任何客戶的限制。]

4.2 項目的優先級

[一旦明確建立項目的優先級，風險承擔者和項目的參與者就能把精力集中在一系列共同的目標上。達到這一目的的一個途徑是考慮軟體項目的五個方面：性能、質量、計劃、成本和人員。在所給的項目中，其每一方面應與下面三個因素之一相適應。

Ø 一個驅動----一個最高級別的目標；

Ø 一個約束----項目管理者必須操縱一個對象的限制因素；

Ø 一個自由度----項目管理能權衡其它方面，進而在約束限制的範圍內完成 目標的一個因素。

未必所有的因素都能成為驅動，或所有的因素都能成為約束因素。在項目開始時記錄和分析哪一個因素適用於哪一類型，將有助於使每一個人的努力和期望與普遍認可的優先級相一致。]

5.產品成功的因素

[明確產品的成功是如何定義和測量的，並指明對產品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的範圍內的事務，還要包括我部素。如果可能，可建立測量的標準，用於評價是否達到業務目標，如：市場股票、銷售量及收入、客戶滿意度、交易處理量和準確度。]

項目構想[XuFeng5]

編者說明：

這個文檔模板與「軟體項目視圖與範圍」文檔的功能十分接近，只不過該文檔更適合於產品型項目。其注重對項目的用戶、市場進行分析，緊抓項目相關人員（也叫做風險承擔者）的需求的本質。

1.文檔簡介

[軟體需求規格說明書的整個內容還是鎖定於整個系統的操作、使用層面之上的功能性需求，只是解決了How的問題，而並未回答Why的問題。這使得系統在開發過程中，開發團隊經常陷入知其然，而不知其所以然的困境，造成了不必要的誤解與錯誤。因此，需要一個側重於對項目的風險承擔者、目標用戶需要的文檔，不僅要了解他們需要的功能，還要找到他們提出這些需求的原因。這就是「項目構想」文檔所要描述的重要內容。]

[本節的內容主要是提供項目構想文檔的目的、範圍、定義、參考資料以及對其的摘要性概述。]

1.1 目的

[說明該文檔的寫作目的。]

1.2 範圍

[範圍主要用來說明該文檔描述的項目內容，以及與其相關的其它東西。]

1.3 定義、首字母縮寫詞和縮略語

[與其它文檔一樣，該文檔也需要將本文檔中所涉及的所有術語、縮略語進行詳細的定義。還有一種可簡明的做法，就是維護在一個項目詞彙表中，這樣就可以避免在每個文檔中都重複很多內容。]

1.4參考資料

[在這一小節中，應完整地列出該文檔引用的所有文檔。對於每個引用的文檔都應該給出標題、標識號、日期以及來源，為閱讀者查找這些文檔提供足夠詳細的信息。]

1.5 概述

[在本小節中，主要是說明項目構想各個部分所包含的主要內容，就像一個文章摘要一樣。同時也應該對文檔的組織方式進行解釋。]

2.定位

2.1 商業機會

[如果該項目是一個產品型項目，那麼應該在本小節中描述該產品所針對的商業機會。如果是定製開發項目，那麼可以省去本小節。]

2.2 問題說明

[使用表格的形式，將該項目將要解決的問題進行概要性地描述：]

2.3 產品定位說明

[如果是產品型項目，則該小節將以表格的形式對產品的定位進行明確，如果是定製開發項目，可以省略本小節。]

[一個具有清晰定位的產品，在開發過程中，團隊將更好地理解，更容易開發出滿足目標市場的產品，因而該部分內容是十分重要的。]

3.項目相關人員和用戶說明

[了解用戶、了解所有與該項目相關的人員，是有效地滿足他們對系統、產品需求的基礎。你應該在本小節中將所有的項目相關人員以及用戶收羅在一起，並對他們進行簡要的描述，對他們的需求、習慣、角度進行說明。這些內容將有助於開發團隊更好的理解用戶的需求本質。]

3.1 產品用戶分析

[如果是產品型項目，那麼你應該本節中對目標客戶進行分析。可以在市場調查的基礎上，對其市場的規模和增長率進行研究，從而估計其潛在的用戶數量。另外，還應結合目標市場的實際情況，分析你的組織是否在該市場上有拓展的優勢，如何獲得這些優勢。如果是定製開發項目，可以省略這一小節。]

3.2 項目相關人員一覽表

[使用下面的表格，對項目相關人員進行分析。]

人員類別	代表	作用
[指明項目相關人員的類別]	[列舉該類人員的代表]	[說明其對產品、項目開發的影響]

3.3 用戶一覽表

[使用下面的表格，對項目、產品的用戶進行分析。]

用戶類型	說明	代表
[指明用戶類別]	[簡要說明他們在系統中代表的對象和充當的作用]	[列舉出代表]

3.4 用戶環境

[了解用戶在使用環境下使用系統或產品，是十分有意義的事，也是實現產品更好地滿足需求，提供更加方便的使用界面的基礎。例如：該任務由多少人來完成？是否總在變化？一個任務周期需要多長時間？執行每項活動要用多長時間？是否總在變化？是否有特殊的環境約束：移動、戶外、乘機旅行等？目前使用的是哪些系統平台？以後會使用哪些平台？還在使用哪些應用程式？您的應用程式是否需要和這些應用程式集成？他們的計算機硬體系統的環境情況如何？他們都是在什麼樣的工作環境中使用系統的？]

3.5 項目相關人員的簡要說明

[以下表的形式，將各類項目相關人員的基本情況進行說明，以幫助開發團隊更好地了解他們的情況。為每一類人員生成一張表格。]

3.6 用戶簡要說明

[以下表的形式，將與系統相關的各種用戶的信息整理出來，以方便開發團隊針對性的工作。要注意的是，用戶會有不同的類型，有些用戶需要的是靈活性、方便快速操作的高級功能，而有些用戶則側重與用戶界面的友好性。這些與該用戶的基本情況直接相關，了解用戶才能夠真正地開發出符合用戶習慣和水平的系統。為每類用戶生成一張表。]

3.7 關鍵的項目相關人員/用戶需要

[列出項目相關人員提出的針對對於該解決方案的關鍵問題。對於列出的每個問題，需澄清：為什麼會出現這一問題？目前的解決方案是什麼？他們需要什麼要的解決方案？或者對新的解決方案有什麼樣的預期？]

[還有一個很關鍵的內容就是，每個需求的優先級，這將對制定疊代計劃時提供有效的基礎，而優先級的確定，應該採用分級、累積投票等方法從用戶、項目相關人員那裡獲得。應充分考慮項目客戶方的要求。如果是產品型項目，則應該從產品經理、市場調查資料里獲得。]

[經過整理後，將內容填入下表：]

需求

優先級

要點

目前解決方案

提議的解決方案

3.8 備選方案和競爭

[如果是產品型項目，應在此小節列舉出客戶除了購買該產品這外的選擇，其中包括購買競爭對手的產品、自行設計解決方案甚至是維持現狀。對所有潛在的競爭產品做一個列表，並根據客戶的實際情況來確認主要優缺點。]

[而如果是定製開發型項目，則應該了解競爭對手提供的解決方案，比在此進行相應的比較。]

4. 產品概述

[本節主要從產品級、系統級的視角，高度概括產品的功能、與其它應用程式的交互以及所需的系統配置等。]

4.1 產品總體效果

[本小節主要將產品話在用戶環境、使用環境的角度來介紹。如果是自成一體，則說明用戶將如何使用；如果是與其它的應用系統進行交互的，則在此小節說明如何與這些系統進行交互？它們之間採用什麼樣的通訊方式和接口。在這裡最適合的方式是使用UML的部署圖，讓用戶對系統最終的運行環境有一個較宏觀的了解。]

4.2 主要功能

[本小節不是對系統或產品所有功能的羅列，而是將能夠體現系統、產品主要優點和特性功能在此列出。在內容組織方面，應該直接與「客戶能夠通過產品獲得的好處」相聯繫，使讀者能夠將系統的功能與客戶的價值直接聯繫起來，在開發時能夠從本質出發，構建出更加符合客戶需要的系統。]

4.3 假設與依賴關係

[在此小節中，列出所有會影響該文檔中所述特性的各種因素。也就是列舉出所有可能讓該文檔發生變化的假設條件。]

4.4 成本與定價

[該小節主要是對該項目的成本進行核算，對給出相應的定價策略。對於定製開發的項目，其成本主要包括開發的人工成本、公司管理成本、項目額外開支、相關軟硬體工具投資等方面。而對於產品型項目而言，還包括分銷成本、用戶手冊製作、CD製作等方面的成本。這裡的成本核算為最終的合同價格以及產品的銷售價值將提供一個基礎的依據，因此也是十分重要的。]

4.5 許可與安裝

[該小節中主要列出影響開發工作的一些許可和安裝相關的問題。例如是否需要加密，如果驗證用戶合法性，安裝界面的要求是什麼。這方面對於產品型項目而言顯得更加重要，也是對軟體智慧財產權保護的一個重要措施。]

5.產品特性

[在本節中將列出系統或產品的特性，特性是指實現用戶價值的系統功能。每一個特性都是一個所需的服務，通常是通過一系列操作實現預期結果。在FDD中，也就是特徵。通常一個特徵會由一個或多個用例來實現，通常系統的特性應該進行整合打包，以25-99項為合適。]

[本小節的描述應該能夠讓用戶、操作人員、外部系統直接從系統的外邊感受到每項特性，這些特性應該包括功能性說明以及一些可用性問題。但是要注意，在這裡不要過早地引入設計的內容，這裡說明的是What，而不是How。]

[另外，因在所有特性的描述中，確定其優先級。]

6.約束

[記錄用戶、項目相關人員提供出的一些約束條件，以及與其它系統之間的依賴關係，這是制訂解決方案時必須考慮到的問題。]

7.質量要求

[對於整個系統的質量要求，如可靠性、可用性、性能、容錯等質量要求，在這此節中詳細地定義與描述。]

8.其他產品需求

[一些要求符合的標準、硬體基礎要求、軟體基礎要求、環境要求等。]

8.1 適用的標準

[列出產品必須符合的所有標準。其中可能包括法律和法規（FDA、UCC）標準、通訊標準（TCP/IP、ISDN）、平台一致性標準（Windows、Unix等）以及質量和安全標準（UL、ISO、CMM）。]

8.2 系統需求

[確定支持該應用程式所必需的任何系統需求。其中可能包括作業系統、網絡環境、系統配置、內存大小、硬碟大小、外圍設備和配套軟體。]

8.3 性能需求

[本節用於詳細說明性能需求。性能問題可能包括在各種負載條件下的用戶負載因素、帶寬或通信容量、吞吐量、精確度以及可靠性或響應時間。]

8.4 環境需求

[對於基於硬體的系統，環境因素可以包括溫度、振盪、濕度、輻射等。對於軟體應用系統，環境因素可以包括使用條件、用戶環境、資源可用性、維護問題、錯誤處理和恢復。]

9. 文檔需求

[列舉用戶所需的與該系統或產品相關的文檔。]

9.1 用戶手冊

[用戶手冊的製作說明，例如手冊篇幅、詳細程序、是否需要圖、主要關心的點、要不要建立索引、詞彙表，採用教程式還是速查手冊式。]

9.2 聯機幫助

[聯機幫助是一種用戶界面友好的服務，它可以為用戶提供實時的協助。]

9.3 安裝指南、配置文件、自述文件

9.4 標籤與包裝

10. 功能需求屬性

[為了在項目開發過程中，對每個功能需求進行跟蹤管理，在此對所有的功能進行一個總體的描述。]

[可以生成一張功能需求屬性表，每條記錄代表一條功能，每個功能包括以下欄位：]

1）狀態：標識該功能的最新狀態。

Ø 已提出：已經提出來，但是還沒有經過正式的覆審而確定的需求；

Ø 已批准：已經經過正式的渠道覆審而確定，準備實施的需求；

Ø 已加入：已經加入到需求管理基線中的特性。

2）利益：根據客戶的態度，確定每個需求的重要程序，也是確定系統開發優先級的基礎數據。

Ø 關鍵：必不可少的特性，缺少這些特性的系統將無法滿足客戶的要求，這些特性通常會在最早安排到疊代開發中去；

Ø 重要：對於系統來說，該特性是十分重要的，很難以通過其它方式來彌補，如果這些特性沒有第一時間實現，將會使得客戶滿意度大大降低。因此是第二優先實現的特性；

Ø 有用：這些是一些有效，但使用頻率較低的功能特性。如果沒有在第一時間實現，也不會對客戶滿意度造成很大的影響；

Ø 無用：對於系統來說是「鍍金」需求，有也可以，沒有也行的。

3）工作量：根據特性所需的時間和資源進行估算，給出團隊開發的工作時間或個人開發的工作時間。也可以估算出代碼行數或功能點數，這也將為疊代開發計劃的制定提供良好的基礎。

4）風險：列出該特性開發的最大風險，可以對這些風險進行級別細分，對於影響較大的風險還應該制定相應的應對措施。

5）穩定性：對該特性需求是否容易變化進行一個預估，以幫助設計人員在設計解決方案時更加有效地避免變化對體系結構的影響，從而節省時間。

6）基線：確定其是否已經納入基線；

7）職責分配：列出負責實現該特性的團隊；

8）原因：列出提出該特性的原因，也可以將與客戶交流的記錄等資料放在這裡，以幫助開發團隊更好的理解客戶的本意。

需求規格說明書(ISO標準版)

編者說明：

當需求調查、分析工作告一段落時，你就需要將這些需求進行規格化描述，整理成文，即軟體需求規格說明書，也就是SRS。這是在軟體項目過程中最有價值的一個文檔。ISO所提供的標準雖然已經時間久遠，但還是頗具參考價值的。

1．引言

1.1編寫的目的

[說明編寫這份需求說明書的目的指出預期的讀者。]

1.2背景

a. 待開發的系統的名稱;

b. 本項目的任務提出者、開發者、用戶；

c. 該系統同其他系統或其他機構的基本的相互來往關係。

1.3定義

1.4參考資料

2．任務概述

2.1目標

[敘述該系統開發的意圖、應用目標、作用範圍以及其他應向讀者說明的有關該系統開發的背景材料。解釋被開發系統與其他有關系統之間的關係。]

2.2用戶的特點

[列出本系統的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本系統的預期使用頻度。]

2.3假定和約束

[列出進行本系統開發工作的假定和約束。]

3．需求規定

3.1對功能的規定

[用列表的方式，逐項定量和定性地敘述對系統所提出的功能要求，說明輸入什麼量、經怎麼樣的處理、得到什麼輸出，說明系統的容量包括系統應支持的終端數和應支持的並行操作的用戶數等指標。]

3.2 對性能的規定

3.2.1精度

[說明對該系統的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。]

3.2.2時間特性要求

[說明對於該系統的時間特性要求。]

3.2.3靈活性

[說明對該系統的靈活性的要求，即當需求發生某些變化時，該系統對這些變化的適應能力。]

3.3輸入輸出要求

[解釋各輸入輸出數據類型，並逐項說明其媒體、格式、數值範圍、精度等。對系統的數據輸出及必須標明的控制輸出量進行解釋並舉例。]

3.4數據管理能力要求（針對軟體系統）

[說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。]

3.5故障處理要求

[列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。]

3.6其他專門要求

[如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。]

4．運行環境規定

4.1設備

[列出運行該軟體所需要的硬設備。說明其中的新型設備及其專門功能，包括：

a. 處理器型號及內存容量

b. 外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量

c. 輸入及輸出設備的型號和數量，聯機或脫機；

d. 數據通信設備的型號和數量

e. 功能鍵及其他專用硬體]

4.2支持軟體

[列出支持軟體，包括要用到的作業系統、編譯程序、測試支持軟體等。]

4.3接口

[說明該系統同其他系統之間的接口、數據通信協議等。]

4.4控制

[說明控制該系統的運行的方法和控制信號，並說明這些控制信號的來源。]

需求規格說明書(Volere版)

編者說明：

Atlantic System Guild（）公司所提供的Volere需求過程與軟體需求規格說明書模板則充分利用了現代軟體工程思想與技術，是一個十分實用、完善的SRS模板。其所提供的Volere需求記錄卡也十分實用，強烈推薦。

註：從Atlantic System Guild公司網站www.atlsysguild.com上獲得，並稍做修改

1.產品的目標

1.1 該項目工作的用戶問題或背景

[對引發開發任務的工作和情況的描述。同時也應描述用戶希望用將要交付的軟體來完成的工作。]

[該節內容為該項目提供了合法的理由，你應該考慮用戶的問題是否嚴重，是否應該解決和為什麼應該解決。]

1.2 產品的目標

[用一句話或很少的幾句話來說明「我們希望該產品做什麼？」換言之，即開發該產品的真正原因。

[項目如果沒有一個表述清晰、易於理解的目標，就會迷失在產品開發的沙漠中。產品必須帶來某種優勢。典型的優勢是產品會增加組織在市場上的價值，減少運作成本，或提供更好的客戶服務。這個優勢應該是可度量的，這樣才能夠讓您確定交付的產品是否達到目標。]

2.客戶、顧客和其它風險承擔者

2.1 客戶是為開發付費的人，並將成為所交付產品的擁有者

[這一項必須給出客戶的姓名，三個以內是合理的。]

[客戶最終將接受該產品，因此必須對交付的產品滿意。如果你無法找到一個客戶的姓名，那麼也許你就不應該構建該產品。]

2.2 顧客是將花錢購買該產品的人

[也給出姓名和相關的信息]

2.3 其它風險承擔者

[其他的一些人或組織的名稱，他們或者受到產品的影響，或影響產品。]

1） 經理或項目負責人；

2） 業務領域專家；

3） 技術人員；

4） 系統開發者；

5） 市場人員；

6） 產品經理；

7） 測試和質量保證人員；

8） 審查員，諸如安全審查員或審計人員；

9） 律師；

10）易用性專家；

11）你所處行業的專業人員。

3.產品的用戶

3.1 產品的用戶

[產品的潛在用戶或操作員的列表。針對每種類型的用戶，提供以下信息：]

1） 用戶分類

2） 用戶工作的任務；

3） 主要相關的經驗；

4） 技術經驗；

5） 其他用戶特徵：包括身體、智力、工作態度、對技術的態度、教育程度、語言技能、年齡、性別等。

[用戶是為了完成工作而與產品交互的人，你了解用戶，就越可能提交適合用戶工作方式的產品。]

3.2 對用戶設的優先級

[在每類用戶後面附上一個優先級，這區別了用戶的重要性和優先地位：]

1） 關鍵用戶：對產品的後續成功至關重要；

2） 次要用戶：他們使用產品，但對產品的長期成功並無影響；

3） 不重要的用戶：不常用、未授權和沒有技能的用戶。

[如果認為某些用戶對產品或組織更重要，那麼應該寫明，因為它會影響你設計產品的方式。]

4.需求限制條件

4.1 解決方案限制條件

[此處明確了限制條件，它們規定了解決問題必須採取的方式。您可以認為它們是指令式的解決方案。仔細描述該解決方案，以及測試是否符合的度量標準。如果可能，您應該解釋使用該解決方案的原因。]

[換一句話說，就是要求軟體解決方案滿足哪些限制條件！]

4.2 實現環境

[此處描述產品將被實施的技術環境和物理環境。]

[該環境也將成為設計解決方案時的限制條件之一。]

4.3 夥伴應用

[此處描述那些不屬於產品的一部分，但產品卻又必須與其協作的應用程式。]

4.4 COTS

[此處描述實現產品需求所必須使用的COTS(商業組件)。]

4.5 預期的工作場地環境

[此處描述用戶工作和使用該產品的工作場地。此處應該描述任何可能對產品設計產生影響的工作場地特徵。]

4.6 開發者構建該產品需要多少時間

[任何已知的最後期限，或商業機會的時限，應在此處說明。]

4.7 該產品的財務預算是多少

[該產品的預算，以金錢的形式或可得資源的形式說明。]

5.命名標準和定義

[定義項目中使用到的所有術語，包括同義詞。這裡的內容就是一個字典，包括在需求規格說明書中使用的所有名稱的含義。這個字典應該使用你的組織或行業使用的標準名稱。這些名稱也應該反映出在工作領域中當前使用的術語。該字典包括項目中用到的所有名稱。請仔細地選擇名稱，以避免傳達不同的、不期望的含義。為每個名字寫下簡明扼要的定義，這些定義必須經過相應的風險承擔者同意。]

6.相關事實

[可能對產品產生影響的外部因素，但不是命令式的需求限制條件。]

7.假定

[列出開發者所做的假設。]

[將所有的假設列在此的目的是讓每一個項目成員都意識到這個假設。]

8.產品的範圍

8.1 工作的上下文範圍

[上下文範圍圖用來表示將要開發的系統、產品與其它系統之間的關係，以確定系統邊界。]

8.2 工作切分

[一個事件清單，確定系統要響應的所有業務事件。清單包括：]

1） 事件名稱

2） 輸入和輸出

8.3 產品邊界

[你可以使用用例圖(use-case)來確定了用戶與產品之間的邊界。]

9.功能性需求與數據需求

9.1 功能性需求

[對產品必須執行的動作的描述。]

[每個功能性需求必須有一個驗收標準。]

9.2 數據需求

[與產品/系統有密切關係的主題域相關的業務對象、實體、類的說明書。]

[進行問題域建模，生成相應的類圖。]

10.觀感需求

[一些與產品的用戶界面相關的需求描述。]

11.易用性需求

11.1 易於使用

[描述如何構建符合最終用戶期望的產品。]

11.2 學習的容易程序

[學習使用該產品應該多容易的說明。通常是有學習時間來衡量。]

12.性能要求

12.1 速度需求

[明確完成特定任務需要的時間，這常常指響應時間。]

12.2 安全性的需求

[對可能造成人身傷害、財產損失和環境破壞所考慮到的風險進行量化描述。]

12.3 精度需求

[對產品產生的結果期望的精度進行量化描述。]

12.4 可靠性和可用性需求

[本節量化產品所需的可靠性。這常常表述為允許的兩次失敗之間無故障運行時間，或允許的總失敗率。]

12.5 容量需求

[本節明確處理的吞吐量和產品存儲數據的容量。]

13.操作需求

13.1 預期的物理環境

[本節明確產品將操作的物理環境，以及這種環境引起的任何特殊需求。]

13.2 預期的技術環境

[硬體和其它組成新產品操作環境的設備的規範。]

13.3 夥伴應用程式

[對產品必須與之交互的其它應用程式的描述。]

14.可維護性和可移植性需求

14.1 維護該產品需要多容易

[對產品作特定修改所需時間的量化描述。]

14.2 是否存在一些特殊情況適用於該產品的維護

[關於預期的產品發布周期和發布將採取的形式的規定。]

14.3 可移植性需求

[對產品必須支持的其他平台或環境的描述。]

15.安全性需求

15.1 該產品是保密的嗎？

[關於該被授權使用該產品，以及在什麼樣的情況下授權等方面的描述。]

15.2 文件完整性需求

[關於需要的資料庫和其他文件完整性方面的說明。]

15.3 審計需求

[關於需要的審計檢查方面的說明。]

16.文件和政策需求

[本節包括針對社會和政策的因素的規格說明，這些因素會影響產品的可接受性。如果你開發的產品是針對外國市場的，可能要特別注意這些需求。]

[問一下是否產品的目標是你所不熟悉的文化環境，是否其它國家的人或其他類型的組織的人會使用該產品。人們是否有與你的文化不同的習慣、節日、迷信、文化上的社會行為規範。]

17.法律需求

17.1 該產品是否受到某些法律的管制

[明確該產品的法律需求的描述。]

17.2 是否有一些必須符合的標準

[明確適用的標準和參考的詳細標準的描述。]

18.Opend問題

[對未確定但可能對產品產生重要影響的因素的問題描述。按照需求分析的術語還說，就是TBD（To Be Define）的問題。]

19.COTS解決方案

19.1 是否有一些製造好的產品可以購買

[應該調查現存產品清單，這些產品可以作為潛在的解決方案。]

19.2 該產品是否可使用製造好的組件

[描述可能用於該產品的候選組件，包括採購的和公司自己的產品。列出來源。]

19.3 是否有一些我們可以複製的東西

[其他相似產品的清單。]

20.新問題

20.1 新產品會在當前環境中帶來什麼問題

[關於新產品將怎樣影響當前的實現環境的描述。]

20.2 新的開發是否將影響某些已實施的系統

[關於新產品將怎樣與現存系統協同工作的描述。]

20.3 是否我們現有的用戶會受到新開發的敵對性影響

[關於現有用戶可能產生的敵對性反應的細節。]

20.4 預期的實現環境會存在什麼限制新產品的因素

[關於新的自動化技術、新的組織結構方式的任何潛在問題的描述。]

20.5 是否新產品會帶來其他問題

[確定我們可能不能處理的情況。]

21.任務

21.1 為提交該產品已經做了哪些事

[用來開發產品的生命周期和方法的細節。畫一個高層的過程圖展示各項任務和它們之間的接口，這可能是溝通這方面信息的最好辦法。]

21.2 開發階段

[關於每個開發階段和操作環境中的組件的規格說明。]

22.移交

22.1 我們要讓已有數據和過程配合新產品，有什麼特殊要求

[一個移交活動的列表，一個實現的時間表。]

22.2 為了新產品，哪些數據必須修改/轉換

[數據轉換任務清單，同時確定新產品需要轉換的數據。]

23. 風險

23.1 當你開發該產品時，要面對什麼風險

23.2 你制定了怎樣的偶然緊急情況計劃

24.費用

[需求的其他費用是你必須投入到產品構建中去的錢或工作量。當需求規格說明書完成時，你可以使用一種估算方法來評估費用，然後以構建所需的資金或時間的形式表述出來。]

25.用戶文檔

[用戶文檔的清單，這些文檔將作為產品的一部分交付。]

26.後續版本的需求

[這裡記錄下一些希望今後版本中實現的需求。]

Volere需求記錄卡

編者說明：

正如前面所述，Atlantic System Guild還提供了一個配套的Volere需求記錄卡，這個記錄卡十分實用。建議大家在需求調查、分析過程中，將需求記錄在一系列的Volere需求記錄卡上，這個卡讓你能夠很好的理清需求之間的關係，需求提出的背景，用戶對需求的期望，有了這些素材，整理SRS時將變得更加簡單。

註：顧客滿意度是指完成該項功能顧客滿意的程度，而顧客不滿意度則是指未實現該功能顧客不滿意的程度。

軟體需求規格說明書[XuFeng6]

編者說明：

如果在需求分析時採用了用例（Use case）技術，那麼該需求規格說明書將更加符合你的需要。當然，你也可以結合Volere需求規格說明書對該模板進行必要的修改。

1. 文檔概述

[該部分主要是對軟體需求規格說明書文檔進行基本的描述，包括該文檔的目的、範圍、術語定義、參考資料以及概要。]

[軟體需求規格說明書用來系統、完整地記錄系統的軟體需求。該軟體需求說明書的基礎是用例分析技術。因此該文檔中應包括用例模型、補充規約等內容。]

1.1目的

[在此小節中，主要對軟體需求規格說明書的目的做一概要性說明，通常軟體需求規格說明書應詳細地說明應用程式、子系統的外部行為，還要說明非功能性需求、設計約束，以及其它的相關因素。]

1.2範圍

[系統是有範圍的，而不是無限擴展的，對於無限擴展的需求是無法進行描述的。因此，在本小節應該對該說明書所涉及的項目範圍進行清晰的界定。指定該規格說明書適用的軟體應用程式、特性或者其它子系統分組、其相關的用例模型。當然在此也需要列出會受到該文檔影響的其它文檔。]

1.4參考資料

1.5 概述

[在本小節中，主要是說明軟體需求規格說明書各個部分所包含的主要內容，就像一個文章摘要一樣。同時也應該對文檔的組織方式進行解釋。]

2. 整體說明

[在本節中，將對整個軟體需求進行總體性的描述，以期讓讀者對整個軟體系統的需求有一個框架性的認識。也就是說，該節中主要包括影響產品及其需求的一般因素，而不列舉具體的需求。主要包括產品總體效果、產品功能、用戶特徵、約束、假設與依賴關係、需求子集等方面的內容。]

2.1用例模型

[在本小節中，將列出該軟體需求的用例模型，該模型處於系統級，對系統的特性進行宏觀的描述。在此應該列出所有的用例和Actor的名稱列表，並且對其做出簡要的說明，以及在圖中的各種關係。]

2.2 假設與依賴關係

[在軟體系統的開發過程中，存在許多假設和依賴關係。在本小節中應列舉出所有的重要的技術可行性假設、子系統或構件可用性假設，以及一些可行性的假設。]

3. 具體需求

[如果說第二章節是框架，那麼本節就是血肉。在本節中，應該詳細列出所有的軟體需求，其詳細程序應使設計人員能夠充分理解並且進行設計的要求，同時也應該給予測試人員足夠的信息，以幫助他們來驗證系統是否滿足了這些需求。整個需求的組織可以採用用例描述進行。]

3.1用例描述

[如果你使用用例建模技術，那麼你已經通過用例定義了系統的大部分功能性需求和一些非功能性需求。因此，在軟體需求規格說明書只需將這些具體的用例描述，整理在一起，全部放在該小節之中。當然也可以將用例描述做為附件，在此列出引用，只是這樣做並不利於閱讀。建議在組織形式上採用以「軟體需求」為線索，在每個需求中，填入對應的1個或幾個用例描述。]

3.2補充需求

[由於用例畢竟主要針對功能性需求，因此還會有一些其它的補充需求遺漏，因此在本小節中就是將這些東西補充出來。這些補充需求大部分集中在非功能需求之上，包括以下幾個方面的內容：]

1） 易用性：例如指出普通用戶和高級用戶要高效地執行某個特定操作所需的培訓時間；指出典型任務的可評測任務次數；或者指出需要滿足的可用性標準（如IBM的CUA標準、Microsoft的GUI標準。

2） 可靠性：包括系統可用性（可用時間百分比、使用小時數、維護訪問權、降紙模式操作等）；平均故障間隔時間（MTBF，通常表示為小時數，但也可表示為天數、月數或年數）；平均修復時間（MTTR，系統在發生故障後可以暫停運行的時間）；精確度（指出系統輸出要求具備的精密度、解析度和精確度）；最高錯誤或缺陷率（通常表示為bugs/KLOC，即每千行代碼的錯誤數目或 bugs/function-point，即每個功能點的錯誤數目）；錯誤或缺陷率（按照小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對「嚴重」錯誤進行界定，例如：數據完全丟失或完全不能使用系統的某部分功能）。

3） 性能：包括對事務的響應時間（平均、最長）；吞吐量（例如每秒處理的事務數）；容量（例如系統可以容納的客戶或事務數）；降級模式（當系統以某種形式降級時可接受的運行模式）；資源利用情況：內存、磁碟、通信等。

4） 其它：包括用戶界面要求、聯機幫助系統要求、法律許可、外購構件，以及作業系統、開發工具、資料庫系統等設計約束。

4.支持信息

[支持信息用於使軟體需求規格說明書更易於使用。它包括：目錄、索引、附錄等。]

計算機軟體需求說明編制指南

編者說明：

軟體需求規格說明是十分重要的文檔，因此為開發團隊提供一份詳細的編制指南是十分有意義和必要的。本文檔就是一個編制指南的例子，你可以根據該指南，結合自己的實際情況進行修改。

1．引言

1.1 目的和作用

本指南為軟體需求實踐提供了一個規範化的方法。本指南不提倡把軟體需求說明（Software Requirements Specifications，以下簡稱SRS）劃分成等級，避免把它定義成更小的需求子集。

本指南適用對象：

1）軟體客戶（Customers），以便精確地描述他們想獲得什麼樣的產品。

2）軟體開發者（Suppliers），以便準確地理解客戶需要什麼樣的產品。

對於任一要實現下列目標的單位和（或）個人：

1）要提出開發規範化的SRS提綱；

2）定義自己需要的具體的格式和內容；

3）產生附加的局部使用條款，如SRS質量檢查清單或者SRS作者手冊等。

SRS將完成下列目標：

1） 在軟體產品完成目標方面為客戶和開發者之間建立共同協議創立一個基礎。對要實現的軟體功能做全面描述，幫助客戶判斷所規定的軟體是否符合他們的要求，或者怎樣修改這種軟體才能適合他們的要求；

2） 提高開發效率。編制SRS的過程將使客戶在設計開始之前周密地思考全部需求，從而減少事後重新設計、重新編碼和重新測試的返工活動。在SRS中對各種需求仔細地進行複查，還可以在開發早期發現若干遺漏、錯誤的理解和不一致性，以便及時加以糾正；

3） 為成本計價和編制計劃進度提供基礎。SRS提供的對被開發軟體產品的描述，是計算機軟體產品成本核算的基礎，並且可以為各方的要價和付費提供依據。SRS對軟體的清晰描述，有助於估計所必須的資源，並用作編制進度的依據；

4） 為確認和驗證提供一個基準。任何組織將更有效地編制他們的確認和驗證計劃。作為開發合同的一部分，SRS還可以提供一個可以度量和遵循的基準（然而，反之則不成立，即任一有關軟體的合同都不能作為SRS。因為這種文件幾乎不包括詳盡的需求說明，並且通常不完全的）；

5） 便於移植。有了SRS就便於移值軟體產品，以適應新的用戶或新的機種。客戶也易於移植其軟體到其他部門，而開發者同樣也易於把軟體移植到新的客戶；

6） 作為不斷提高的基礎。由於SRS所討論的是軟體產品，而不是開發這個產品的設計。因此SRS是軟體產品繼續提高的基礎。雖然SRS也可能要改變，但是原來的SRS還是軟體產品改進的可靠基礎。

1.2 範圍

本指南適用於編寫軟體需求規格說明，它描述了一個SRS所必須的內容和質量，並且在第6章中提供了SRS大綱。

2．引用標準

GB 8566 計算機軟體開發規範

GB 8567 計算機軟體產品開發文件編制指南

GB/T 11457 軟體工程術語

3．定義

GB/T 11457所列術語和下列定義適用於本指南。

合同（contract）：是由客戶和開發者共同簽署的具有法律約束力的文件。其中包括產品的技術、組織、成本和進度計劃要求等內容。

客戶（customer）：指個人或單位，他們為產品開發提供資金，通常（但有時也不必）還提出各種需求。文件中的客戶和開發者也可能是同一個組織的成員。

語言（language）：是具有語法和語義的通信工具，包括一組表達式、慣例和傳遞信息的有關規則。

分割（partitioning）：把一個整體分成若干部分。

開發者（supplier）：指為客戶生產某種軟體產品的個人或集團。在本指南中，客戶和開發者可能是同一個組織的成員。

用戶（user）：指運行系統或者直接與系統發生交互作用的個人或集團。用戶和客戶通常不是同一些人。

4．編寫SRS的背景信息

4.1 SRS的基本要求

SRS是對要完成一定功能、性能的軟體產品、程序或一組程序的說明。對SRS的描述有兩項基本要求：

1）必須描述一定的功能、性能；

2）必須用確定的方法敘述這些功能、性能。

4.2 SRS的環境

必須認識到SRS在整個軟體開發規範（見GB 8566）所規定的有關階段都起作用。正因為如此，SRS的起草者必須特別注意不要超出這種作用的範圍。這意味著要滿足下列要求：

1） SRS必須正確地定義所有的軟體需求；

2） 除設計上的特殊限制之外，SRS中一般不描述任何設計、驗證或項目管理細節。

4.3 SRS的特點

4.3.1 無歧義性

若且唯若它對每一個需求只有一種解釋時，SRS者是無歧義的。

2） 要求最終產品的每一個特性用某一術語描述；

3） 若某一術語在某一特殊的行文中使用時具有多種歧義，那麼對該術語的每種含義作出解釋並指出其適用場合。

需求通常是用自然語言編寫的，使用自然語言的SRS起草者必須特別注意消除其需求的歧義性。提倡使用形式化需求說明語言。

4.3.2 完整性

如果一個SRS能滿足下列要求，則該SRS就是完整的：

1） 包括全部有意義的要求，無論是關係到功能的、性能的、設計約束的，還是關係到屬性或外部接口方面的需求；

2） 對所有可能出現的輸入數據的響應予以定義，要對合法和非合法的輸入值的響應做出規定；

3） 要符合SRS要求。如果個別章節不適用，則在SRS中要保留章節號；

4） 填寫SRS中的全部插圖、表、圖示標記和參照，並且定義全部術語和度量單位。

4.3.2.1 關於使用「待定」一詞的規定

任何一個使用「待定」的SRS都是不完全的。

1） 若萬一遇到使用「待定」一詞時，作如下處理：

Ø 對產生「待定」一詞的條件進行描述，使得問題能被解決；

Ø 描述必須幹什麼事，以刪除這個「待定」；

2） 包含有「待定」一詞的任何SRS的項目文件應該：

Ø 標識與此特定文件有關的版本號或敘述其專門的發布號；

Ø 拒絕任何仍標識為「待定」一詞的SRS章節的許諾。

4.3.3 可驗證性

若且唯若SRS中描述的每一個需求都是可以驗證的，該SRS才是可以驗證的；若且唯若在某一性能價格比可取的有限處理過程，人或機器能通過該過程檢查軟體產品能否滿足需求時，才稱這個需求是可以驗證的。

4.3.4 一致性

若且唯若SRS中各個需求的描述是不矛盾時SRS才是一致的。

4.3.5 可修改性

如果一個SRS的結構和風格在需求有必要改變時是易於實現的、完整性的、一致的，那麼這個SRS就是可以修改的。可修改性要求SRS具備以下條件：

1） 具有一個有條不紊的易於使用的內容組織，具有目錄表，索引和明確的交叉引用表；

2） 沒有冗餘。即同一需求不能在SRS中出現多次。

Ø 冗餘本身不是錯誤，但是容易發生錯誤。冗餘可增加SRS的可讀性，但是在一個冗餘文件被更新時容易出現問題。例如：假設一個明確的需求在兩個地方詳細列出，後來發現這個需求需要改變，若只修改一個地方，於是SRS就變得不一致了。

Ø 不管冗餘是否必須，SRS一定要包含一個詳細的交叉引用表，以便SRS具備可修改性。

4.3.6 可追蹤性

如果每一個需求的源流是清晰的，在進一步產生和改變文件編制時，可以方便地引證每一個需求，則該SRS就是可追蹤的。建議採用如下兩種類型的追蹤：

1） 向後追蹤（即向已開發過的前一階段追蹤）。根據先前文件或本文件前面的每一個需求進行追蹤。

2） 向前追蹤（即是向由SRS派生的所有文件追蹤）。根據SRS中具有唯一的名字和參照號的每一個需求進行追蹤。

當SRS中的一個需求表達另一個需求的一種指派或者是派生的，向前、向後的追蹤都要提供。例如：

1） 從總的用戶響應時間需求中分配給資料庫操作響應時間；

2） 識別帶有一定功能和用戶接口的需求的報告格式；

3） 支持法律或行政上需要的某個軟體產品（例如，計算稅收）。在這種情況下，要指出軟體所支持的確切的法律或行政文件。

當軟體產品進入運行和維護階段時，SRS的向前可追蹤性顯得特別重要。當編碼和設計文件作修改時，重要的是要查清這些修改所影響的全部需求。

4.3.7 運行和維護階段的可使用性

SRS必須滿足運行和維護階段的需要，包括軟體最終替換。

1） 維護常常是由與原來開發無聯繫的人來進行的。局部的改變（修正）可以藉助於好的代碼注釋來實現。對於較大範圍的改變。設計和需求文件是必不可少的，這裡隱含了兩個作用：

Ø 如4.3.5 條指出，SRS必須是可修改的；

Ø SRS中必須包括一個記錄，它記錄那些應用於各個成分的所有具體條文。例如：它們的危急性（如故障可能危及完全或導致大量財政方面和社會方面的損失）；它們僅與暫時的需要相關（如支持一種可立即恢復原狀的顯示）；它們的來源（如某功能是由已存在的軟體產品的全部拷貝複製而成）。

2） 要求在SRS中清楚地寫明功能的來源和目的，因為對功能的來源和引入該功能的目的不清楚的話，通常不可能很好地完成軟體的維護。

4.4 SRS的編制者

軟體開發的過程是由開發者和客戶雙方同意開發什麼樣的軟體協議開始的。這種協議要使用SRS的形式，應該由雙方聯合起草。這是因為：

1） 客戶通常對軟體設計和開發過程了解較少，而不能寫出可用的SRS；

2） 開發者通常對於客戶的問題和意圖了解較少，從而不可能寫出一個令人滿意的系統需求。

4.5 SRS的改進

軟體產品的開發過程中，在項目的開始階段不可能詳細說明某些細節，在開發過程中可能發現SRS的缺陷、缺點和錯誤之類的問題，所以可能要對SRS進行改進。

在SRS的改進中，應注意如下事項：

1） 儘管可以預見校正版本的開發以後不可避免，而對需求還必須儘可能完全、清楚地描述。

2） 一旦最初識別出項目的變化，應引入一個正式的改變規程來標識、控制、追蹤和報告項目的改變。批准了的需求改變，用如下的方法編入SRS之中：

Ø 提供各種改變後的正確的、完全的審查記錄；

Ø 允許對SRS當前的和被替代部分的審查。

4.6 SRS的編制工具

編制SRS最顯而易見的方法是用自然語言來描述。儘管自然語言是豐富多彩的，但不易精確，用形式化的方法較好。

4.6.1 形式化說明方法

在SRS中是否使用形式化方法要依據下列因素：

1) 程序規模和複雜性；

2) 客戶合同中是否要求使用；

3) SRS是否是一個合同工具或僅僅是一個內部文件；

4) SRS文件是否成為設計文件的根據；

5) 具有支持這種方法的計算機設備。

4.6.2 生產工具

軟體產品生產中有多種生產工具。比如，計算機的字處理器就是非常有用的生產輔助工具。一個SRS通常有若干作者。可能經歷若干版本，並且要進行多次重新組織內容。故生產工具是必要的。

4.6.3 表達工具

在SRS中有許多詞彙，特別是許多名詞和動詞，專門涉及到系統的實體和許多活動，所以表達SRS需要若干工具。比如：

1) 可以驗證實體或活動，無論在SRS中什麼地方都是同一名字。

2) 可以標識一個特殊的實體或動作在規格說明中的描述位置。

此外，可以使用若干種形式化方法，以便允許自動處理SRS內容，只要作某些限制就可以做到：

用一些表格或圖示法來顯示需求。

用詳細分層體系自動檢查SRS的需求，這裡每一個分層自身是完全的，但是也可以擴展為下一層，或是上一層的一個組成成分。

自動檢查SRS具有在4.3條描述的部分或全部特點。

5 軟體需求

SRS中每一個軟體需求是要求開發軟體產品的某些基本功能和性能的一個陳述。

5.1 表達軟體需求的方法

軟體需求可以用若干種方法來表達：

1）通過輸入、輸出說明；

2）使用代表性的例子；

3）用規範化的模型。

5.1.1 輸入、輸出說明

用輸入輸出序列來描述一個軟體產品所要求的特性是很有效的。

5.1.1.1 途徑

根據被描述的軟體的性質，至少有三種不同的途徑：

1） 有些軟體產品（如報表系統）要求著重說明輸出。一般情況下，致力於輸出的系統主要是在數據文卷上操作。用戶的輸入通常是致力於提供控制信息和啟動數據文卷的處理；

2） 有些軟體產品需要著重說明輸入、輸出特性。關注輸入、輸出的系統主要是在當前的輸入上操作，要求生成與輸入相匹配的輸出（類似於數據轉換例行程序或一個數學函數包）；

3） 還有一些系統（如過程控制系統）要求記憶它們的狀態。可以根據本次輸入和上一次輸入進行應答。也就是說，它的行為如同一個有限狀態機。在此種情況下，既要關注輸入/輸出對，又要關注這些輸入/輸出對的次序。

5.1.1.2 困難

多數軟體產品可能接收無限的序列作為輸入，於是，為了通過輸入輸出序列完整地說明產品的特性，就要求SRS包括一個無限長的輸入和所需的輸出充列。然而，用這樣的途徑不可能完整地描述軟體所要求的一切特性。

5.1.2 典型例子

一種選擇是用典型例子來說明要求的特性。例如，假設一個系統中當接收「0」時用「1」來回答。顯然，要列出全部輸入和輸出序列是不可能的。然而，用典型的序列可以十分清楚地理解系統的特性。下面是一組四種對話的典型的例子，用它描述系統特性。

0101

010101010101

01

010101

這些對話僅提供了要求的輸入和輸出之間的關係，但是不能完全描述系統的特性。

5.1.3 模型

另一種表達需求的方法是模型的方式，這是表達複雜需求的精確和有效方法。至少可以提出三種可供使用的通用模型：數學型、功能型、計時型。應注意區別各種模型的應用場合，參考5.1.3.5。

5.1.3.1 數學模型

數學模型是使用數學關係描述軟體特性的模型。數學模型對某些特殊應用領域是特別有用的。例如，導航、線性規劃、計量經濟、信號處理和氣象分析等。

用數學模型能夠對5.1.2中所討論的典型例子描述如下：

（01）*。

這裡，「*」號表示括號內的字符串可以重複一次或多次。

5.1.3.2 功能模型

功能模型是提供從略語以輸出映象的模型。象有限狀態機或Petri網，這些功能模型可以有助於標識和定義軟體的各種特點，或者可以表示系統所要進行的操作。

對前面用數學模型描述的例子。可用圖1所示的有限狀態機形式的功能模型來描述。圖中進入的箭頭表示啟動狀態。雙線的方框表示接收狀態。在各線記號x/y的含義是：x代表接受的輸入，而y是產生的輸出。

5.1.3.3 計時模型

計時模型是一種增加了時間限制的模型。這種模型對於表達軟體特性的形式和細節特別有用。尤其是實時系統或考慮人為因素的系統。

計時模型可以把下列限制加到圖1的模型中去：

1）激活因素0將在進入S1狀態30S之內出現；

2）響應1將在進入S2狀態2S之內出現。

5.1.3.4 其他模型

除了上面提及的模型外。對一些特殊的應用還有一些特別有用的模型。例如，編譯程序的說明可以使用屬性文法，工資單系統可以使用表格。要注意的是，對SRS使用形式需求語言，通常含有使用特殊模型的意思。

5.1.3.5 警告

無論使用哪一類型的模型，都要在SRS中或在SRS涉及到的一個文件中對它嚴格定義。這個定義應該規定：

1）模型中的參數所要求的範圍；

2）使用時的限定值；

3）結果的精確度；

4）負載的能力；

5）要求的執行時間；

6）預設或失敗時的響應。

必須注意，在需求的定義域內要保持一個模型定義。每當一個SRS使用一個模型時：

1）它意味著此模型提供一個十分有效和精確的方法說明需求；

2）並不意味著軟體產品的實現必須基於這個模型。

一個模型用於解釋文件所寫的需求是有效的，但是對於實際軟體的實現可能並不是最適宜的。

5.2 軟體需求的注釋

有關軟體產品的所有需求，並不是同等重要的。某些需求可能是基本的，例如是對於生命攸關的應用。而另一些可能並不那麼重要。

SRS中每一個需求必須進行注釋，以便區別其重要的程度。

有這種方法注釋需求，可以：

1） 幫助客戶對每個需求給予更周密的考慮，通常可以在需求中澄清隱藏的假設；

2） 幫助開發者做出正確的設計決定，並對軟體產品不同部分作出相應的努力。

5.2.1 穩定性

注釋需求的一種方法是使用穩定性量綱。當一個需求在軟體預期的生存期間內描述不改變的話，可以認為該需求是穩定的，否則可以認為是易變的。

5.2.2 必要性等級

注釋的另一種方法是把需求分成必須保證級、期望級和任選級。

5） 必須保證是指軟體必須和這些需求相一致，否則該軟體不可能被接受；

6） 期望是指這些需求將提高軟體產品的功能，但如果預設的話也是可接受；

7） 任選是給開發者一個機會，可以提供某些超出SRS規定的目標。

5.2.3 注意事項

在注釋需求之前，必須徹底理解這種注釋的實質性含義。

5.3 在表達需求時遇到的共同弊病

SRS的基本點是它必須說明由軟體獲得的結果，而不是獲得這些結果的手段。編寫需求的人必須描述的基本問題是：

1） 功能——所設計的軟體要做什麼；

2） 性能——是指軟體功能在執行過程中的速度、可使用性、響應時間、各種軟體功能的恢復時間、吞吐能力、精度、頻率等等；

3） 強加於實現的設計限制——在效果、實現的語言、資料庫完整性、資源限制、操作環境等等方面所要求的標準；

4） 屬性——可移植性、正確性、可維護性及安全性等方面的考慮因素；

5） 外部接口——與人、硬體、其他軟體和其他硬體的相互關係。

編寫需求的人應當避免把設計或項目需求寫入SRS之中，應當對說明需求設計約束與規劃設計兩者有清晰的區別。

5.3.1 在SRS中嵌入了設計

在SRS中嵌入設計說明，會過多地約束軟體設計，並且人為地把具有潛在危險的需求放入SRS中。

1） SRS必須描述在幹什麼數據上、為誰完成什麼功能、在什麼地方、產生什麼結果。SRS應把注意力集中在要完成的服務目標上。通常不指定如下的設計項目：

Ø 把軟體劃分成若干模塊；

Ø 給每一個模塊分配功能；

Ø 描述模塊間的信息流程或者控制流程；

Ø 選擇數據結構。

2） 把設計完全同SRS隔離開來始終是不現實的。安全和保密方面的周密考慮可能增加一些直接反映設計約束的需求。例如：

Ø 在一些分散的模塊中保持某些功能；

Ø 允許在程序的某些區域之間進行有限的通訊；

Ø 計算臨界值的檢查和。

3） 通常應考慮到，若要為軟體選擇高層次的設計，就可能需要大量的資源（可能占整個產品開發成本的10%-20%以上）。有兩種選擇：

Ø 不顧本指南的警告，在SRS中描述了設計。這意味著，或者將一個潛在不適當的設計作為一個需求進行描述（因為，若要得到好的設計，所花費的時間是不夠的），或者在需求階段花費了過多的時間（因為在SRS完成之前整個設計分析都要完成）；

Ø 採用本指南中5.1.3條中的建議，用模型設計描述需求，這種模型設計只用於輔助描述需求，而不使之成為實際的設計。

5.3.2 在SRS中嵌入了一些項目要求

SRS應當是描寫一個軟體產品，而不是描述生產軟體產品的過程。

項目要求表達客戶和開發者之間對於軟體生產方面合同性事宜的理解（因此不應當包括在SRS中）例如：

1） 成本；

2） 交貨進度；

3） 報表處理；

4） 軟體開發方法；

5） 質量保證；

6） 確認和驗證的標準；

7） 驗收過程。

項目需求在另外文件中描述。在SRS中提供的只是關於軟體產品本身的需求。

6 SRS大綱

本章著重討論SRS的每一個基本部分，可以作為一個SRS的大綱。表1給出該大綱目錄，表2至表5給出大綱中第3章的具體需求內容。各開發者和客戶應當根據所描述的實際情況，按本指南有關規定編寫自己的SRS。

6.1 前言（SRS第1章）

本章提供整個SRS綜述。

6.1.1 目的（SRS的1.1條）

在這一條包括下列內容：

1）描述實際SRS的目的；

2）說明SRS所預期的讀者。

6.1.2 範圍（SRS的1.2條）

1） 通常應考慮到，若要為軟體選擇高層次的設計，就可能需要大量的資源（可能占整個產品開發成本的10%-20%以上）。有兩種選擇：

2） 用一個名字標識被生產的軟體產品。比如：×××資料庫系統，報表生成程序等等；

3） 說明軟體產品將幹什麼，如果需要的話，還要說明軟體產品不幹什麼；

4） 描述所說明的軟體的應用。應當：

Ø 儘可能精確地描述所有相關的利閃、目的、以及最終目標。

Ø 如果有一個較高層次的說明存在，則應該使其和高層次說明中的類似的陳述相一致（例如，系統的需求規格說明）。

6.1.3 定義、縮寫詞、略語（SRS的1.3條）

本條中必須提供全部需求的術語、縮寫詞及略語的定義，以便對SRS進行適當的解釋。這些信息可以由SRS的附錄提供。也可以參考其他的文件。

6.1.4 參考資料（SRS的1.4條）

本條應包括：

1） 在SRS中各處參照的文件的全部清單，如經核准的計劃任務書，上級機關批文、合同等；

2） 列出其他參考資料，如屬本項目的其他已發表的文件和主要文獻等。每一個文件、文獻要有標題，索引號或文件號，發布或發表日期以及出版單位；

3） 詳細說明可以得到該參考文件的來源。這個信息可以通過引用附錄或其他文件提供。

6.2 項目概述（SRS第2章）

本章應描述影響產品和其需求的一般因素，本章不說明具體的需求，而僅使需求更易於理解。

6.2.1 產品描述（SRS的2.1條）

這一條是把一個產品用其他有關的產品或項目來描述。

1） 如果這個產品是獨立的，而且全部內容自含，應在此說明；

2） 如果SRS定義的產品是一個較大的系統或項目中的一個組成部分，那麼本條應包括如下內容：

Ø 要概述這個較大的系統或項目的每個組成部分的功能，並說明其接口；

Ø 指出該軟體產品主要的外部接口。在這裡，不要求對接口詳細地描述，詳細描述放在SRS其他章條中；

Ø 描述所使用的計算機硬體、外圍設備。這裡僅僅是一個綜述性描述。

在本條的描述中，用一個方框圖來表達一個較大的系統或項目的主要組成部分、相互聯繫和外部接口是非常有幫助的。

本條既不用來強迫進行設計方案的描述，也不是描述在解決問題時的設計約束。本條應對在以後具體需求一章中說明的設計約束提供理由。

6.2.2 產品功能（SRS的2.2條）

本條是為將要完成的軟體功能提供一個摘要。例如，對於一個記帳程序來說，SRS可以用這部分來描述：客戶帳目維護、客戶財務報表和發票製作，而不必把功能所要求的大量的細節描寫出來。

有時，如果存在較高層次的規格說明時，則功能摘要可直接從中取得，這個較高層次的規格說明為軟體產品分配了特殊的功能，為了清晰起見，請注意：

1） 編制功能的一種方法是製作功能表，以便客戶或者第一次讀這個文件的人都可以理解；

2） 用方框圖來表達不同的功能和它們的關係也是有幫助的。但要牢記，這樣的圖不是產品設計時所需求的，而只是一種有效的解釋性的工具。

這一條不用作陳述具體需求，只是對後來SRS中具體需求一章中為什麼要描述的某些需求提供理由。

6.2.3 用戶特點（SRS的2.3條）

本條要描述影響具體需求的產品的最終用戶的一般特點。

許多人在軟體生存周期的操作和維護階段與系統相關。而這些人中有用戶、操作員、維護人員和系統工作人員。這些人的某些特點，象教育水平、經驗、技術、專長等，都是施加於系統操作環境的重要約束。

如果系統的大多數用戶是一些臨時用戶，那麼就要求系統包含如何完成基本功能的提示，而不是假設用戶已經從過去的會議或從閱讀用戶指南中了解到這些細節。

這一條的內容不能用來陳述具體需求或強加若干特殊的設計約束，本條應對在SRS的具體需求一章之中的某些具體需求或設計約束的描述提供理由。

6.2.4 一般約束（SRS的2.4條）

本條對設計系統陽限制開發者選擇的其他一些項作一般性描述。而這些項將限定開發者在設計系統時的任選項。這些包括：

1） 管理方針；

2） 硬體的限制；

3） 與其他應用間的接口；

4） 並行操作；

5） 審查功能；

6） 控制功能；

7） 所需的高級語言；

8） 通信協議；

9） 應用的臨界點；

10）安全和保密方面的考慮。

本條不陳述具體需求或具體設計約束：而對SRS的具體需求一章中為什麼要確定某些具體需求和設計約束提供理由。

6.2.5 假設和依據（SRS的2.5條）

本條列出影響SRS中陳述的需求的每一個因素。這些因素不是軟體的設計約束，但是它們的改變可能影響到SRS中的需求。例如：假定一個特定的作業系統是在被軟體產品指定的硬體上使用的，然而，事實上這個作業系統是不可能使用的，於是，SRS就要進行相應的改變。

6.3 具體需求（SRS的第3章）

本章應包括軟體開發者在建立設計時需要的全部細節。這是SRS中篇幅最大和最重要的部分。

1） 根據本指南第4章所規定的準則（如可驗證性、無歧義性等），對每一個需求細節作具體描述；

2） 在SRS的前言、項目概述、附錄部分的有關討論中，要提供對任何一個具體需求交叉引用的背景；

3） 具體需求分類的方法如下：

Ø 功能需求；

Ø 性能需求；

Ø 設計約束；

Ø 屬性；

Ø 外部接口需求。

本章中要注意的二點是：

1） 符合邏輯的和可讀的方式組織；

2） 詳細描述每個需求，使該需求應達到目標能夠用指定的方法進行客觀的驗證。

6.3.1 具體需求的內容

6.3.1.1 功能需求

本條描述軟體產品的輸入怎樣變換成輸出。即軟體必須完成的基本動作。 對於每一類功能或者有時對於每一個功能，需要具體描述其輸入、加工和輸出的需求。這通常由四個部頒組成：

1） 引言

這部分描述的是功能要達到的目標、所採用的方法和技術，還應清楚說明功能意圖的由來和背景。

2） 輸入

這部分應包括：

Ø 詳細描述該功能的所有輸入數據，如：輸入源、數量、度量單位、時間設定、有效輸入範圍（包括精度和公差）；

Ø 操作員控制細節的需求。其中有名字、操作員活動的描述、控制台或操作員的位置。例如：當列印檢查時，要求操作員進行格式調整；

Ø 指明引用接口說明或接口控制文件的參考資料。

3） 加工

定義輸入數據、中間參數，以獲得預期輸出結果的全部操作。它包括如下的說明：

Ø 輸入數據的有效性檢查；

Ø 操作的順序，包括事件的時間設定；

Ø 異常情況的響應，例如，溢出、通信故障、錯誤處理等；

Ø 受操作影響的參數；

Ø 降級運行的要求；

Ø 用於把系統輸入變換成相應輸出的任何方法（方程式、數學算法、邏輯操作等）；

Ø 輸出數據的有效性檢查。

4） 輸出

這部分應包括：

Ø 詳細描述該功能所有輸出數據，例如：輸出目的地、數量、度量單位、時間關係、有效輸出的範圍（包括精度和公差）、非法值的處理、出錯信息；

Ø 有關接口說明或接口控制文件的參考資料。

此外，對著重於輸入輸出行為的系統來說，SRS應指定所有有意義的輸入、輸出對及其序列。當一個系統要求記憶它的狀態時，需要這個序列，使得它可以根據本次輸入和以前的狀態作出響應。也就是說，這種情況猶如有限狀態機。

6.3.1.2 設計約束

設計約束受其他標準、硬體限制等方面的影響。

1） 其他標準的約束：本項將指定由現有的標準或規則派生的要求。例如：報表格式、數據命名、財務處理、審計追蹤等等。

2）硬體的限制：本項包括在各種硬體約束下運行的軟體要求，例如，應該包括：硬體配置的特點（接口數，指令系統等）、內存儲器和輔助存儲器的容量。

6.3.1.3 屬性

在軟體的需求之中有若干個屬性，下面指出其中的幾個（注意：對這些決不應理解為是一個完整的清單）。

1） 可用性：可以指定一些因素，如檢查點、恢復和再啟動等，以保證整個系統有一個確定的可用性級別。

2） 安全性：這裡指的是保護軟體的要素，以防止各種非法的訪問、使用，修改、破壞或者泄密。這個領域的具體需求必須包括：

Ø 利用可靠的密碼技術；

Ø 掌握特定的記錄或歷史數據集；

Ø 給不同的模塊分配不同的功能；

Ø 限定一個程序中某些區域的通信；

Ø 計算臨界值的檢查和。

3） 可維護性：這裡規定若干需求以確保軟體是可維護的。例如：

Ø 軟體模塊所需要的特殊的耦合矩陣；

Ø 對微型裝置指定特殊的數據/程序分割要求。

4） 可轉移/轉換性：這裡規定把軟體從一種環境移植到另一種環境所要求的用戶程序，用戶接口兼容方面的約束等等。

5） 警告：指定所需屬性十分重要，它使得人們能用規定的方法去進行客觀的驗證。

6.3.1.4 外部接口要求

1） 用戶接口：提供用戶使用軟體產品是地的接口需求。例如，如果系統的用戶通過顯示終端進行操作，就必須指定如下要求：

Ø 對屏幕格式的要求；

Ø 報表或菜單的頁面列印格式和內容；

Ø 輸入輸出的相對時間；

Ø 程序功能鍵的或用性。

2） 硬體接口：要指出軟體產品和系統硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什麼樣的設備，如何支撐這些設備，有何約定。

3） 軟體接口：在這裡應指定需使用的其他軟體產品（例如，數據管理系統，作業系統，或者數學軟體包），以及同其他應用系統之間的接口。 對每一個所需的軟體產品，要提供名字、助記符、規格說明號、版本號、來源等內容。 對於每一個接口，這部分應說明與軟體產品相關的接口軟體的目的，並根據信息的內容和格式定義接口，這裡不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。

4） 通信接口：這裡指定各種通信接口，例如，局部網絡的協議等等。

6.3.1.5 其他需求

根據軟體和用戶組織的特性等，某些需求放在下面各項中描述。

1） 資料庫：本項對作為產品的一部分進行開發的資料庫規定一些需求，它們可能包括：

Ø 在6.3.1.1條中標識的信息類別；

Ø 用的頻率；

Ø 存取能力；

Ø 數據元素和文卷描述符；

Ø 數據元素、記錄和文卷的關係；

Ø 靜態和動態的組織；

Ø 數據保存要求。

註：如果使用一個現有的資料庫包，這個包應在「軟體接口」中命名，並在那裡詳細說明其用法。

2） 操作：這裡說明用戶要求的常規的和特殊的操作。

Ø 在用戶組織之中各種方式的操作。例如，用戶初始化操作；

Ø 交互作用操作的同期和無人操作的周期；

Ø 數據處理支持功能；

Ø 後援和恢復操作。

註：這裡的內容有時是用戶接口的一部分。

3） 場合適應性需求：這裡包括：

Ø 對給定場合、任務或操作方式的任何數據或初始化順序的需求進行定義。例如，柵值，安全界限等等。

Ø 指出場合或相關任務的特點，這裡可以被修改以使軟體適合特殊配製的要求。

6.3.2 具體要求的組織

本條通常是SRS所有部分中最大並且最複雜的部分。

1） 可以根據軟體實現功能的基本類型，將本條分成若干段。例如：考慮一個大的交互記帳系統，在裡層可以分為操作軟體（它支持近乎實時的事務處理）、支撐軟體（聯機功能、磁碟備份、裝入磁帶等等）以及診斷軟體（診斷硬體、通信等），外一層是應收款帳以及應付款帳等等；

2） 結構細分的目的是提高SRS的可讀性，而不是進行概要設計。

對於SRS中的第3章的具體需求部分的最好的組織方案取決於所說明的軟體產品的應用範圍和性質。 文中最後部分提供了四種可能的組織方案。

1） 大綱1中首先說明全部功能需求，然後說明四種類型的接口要求，最後是其他需求；

2） 大綱2中，把對應每個特定功能的四種接口需求和該功能需求放在一起描述，然後說明其他需求；

3） 大綱3中，與功能需求有關的全部內容放在一起首先說明，然後是其他需求的描述。對每一種外部接口的需求重複上述過程；

4） 大綱4中，接口需求和其餘的需求作為每一個功能需求的附屬部分來說明。

SRS的具體需求的組織形式必須選擇可讀性最好的方法來描述。

6.4 支持信息

支持信息是指目錄表，附錄和索引。以便使SRS易於使用。

1）目錄表和索引很重要，而且應按照可以接受的好的文件規則來編寫。

2）對一個實際的需求規格說明來說，若有必要應該編寫附錄。附錄中可能包括：

Ø 輸入輸出格式樣本，成本分析研究的描述或用戶調查結果；

Ø 有助於理解SRS的背景信息；

Ø 軟體所解決問題的描述；

Ø 用戶歷史、背景、經歷和操作特點；

Ø 交叉訪問表。按先後次序進行編排，使一些不完全的軟體需求得以完善（參見4.3.2條和4.3.3條）；

Ø 特殊的裝配指令用於編碼和媒體，以滿足安全、輸出、初始裝入或其他要求。

3）6.4.3當包括附錄時，SRS必須明確地說明附錄是不是需求要考慮的部分。

SRS大綱1

3 具體需求

3.1 功能需求

3.1.1 功能需求1

3.1.1.1 引言 3.1.1.2輸入 3.1.1.3 加工 3.1.1.4輸出

3.1.2 功能需求2

……

3.1.n 功能需求n

3.2 外部接口需求

3.2.1 用戶接口 3.2.2 硬體接口 3.2.3 軟體接口 3.2.4 通信接口

3.3 性能需求

3.4 設計約束

3.4.1 其他標準的約束 3.4.2硬體的限制 …………

3.5 屬性

3.5.1 安全性 3.5.2 可維護性 …………

3.6 其他需求

3.6.1 資料庫 3.6.2 操作 3.6.3 場合適應性 …………

用例說明模板1(經典模板)

編者說明：

隨著UML的日益普及，用例（Use case）分析技術也在需求實踐中廣泛被採用。但是也有許多團隊在使用該技術時，只畫出了用例圖，而缺少了用例說明，其實這是一個嚴重的誤區。而本模板就將指導你編寫該說明。

1.用例名稱

1.1 簡要說明

[簡要說明用例的作用和目的。該小節的篇幅不要太長。]

2.上下文圖

[在此小節中，有一個只包括本用例和所有與該用例相關的Actor和其它用例組成的，一個用例圖的局部。]

3. 事件流

3.1 基本流

[當Actor採取行動時，用例也就隨即開始。用例總是由Actor啟動的，用例應說明Actor的行為及系統的響應，可按照Actor與系統進行對話的形式來逐步引入用例。]

[要注意的是，用例描述應該說明系統內發生的事情，而不是事件發生的方式與原因。如果進行了信息交換，則需指出來回傳遞的具體信息。例如，只表述主角輸入了客戶信息就不夠明確。最好明確地說主角輸入了客戶姓名和地址。當然你也可以通過項目詞彙表來定義這些信息，使得用例中的內容被簡化，從而不致於讓用例描述陷入過多的細節內容。]

[如果存在一些相對比較簡單的備選流，只需少數幾句話就可以說明清楚，那麼也可以直接在這一部分中描述。但是如果比較複雜，還是應該單獨放在備選流小節中描述。]

[一幅圖勝過千言萬語，因此建議在這一小節中，除了敘述性文字之外，你還可以引用UML中的活動圖、順序圖、協作圖、狀態圖等手段，對其進行補充說明。]

3.2 備選流

3.2.1 第一備選流

[正如前面所述，對於較複雜的備選流應單獨地說明。]

3.2.1.1 備選支流

[如果能使表達更明確，備選流又可再分為多個支流。]

3.2.2 第二備選流

[在一個用例中很可能會有多個備選流。為了使表達更清晰，應將各個備選流分開說明。使用備選流可以提高用例的可讀性，並防止將用例分解為過多的層次。應切記，用例只是文本說明，其主要目的是以清晰、簡潔、易於理解的方式記錄系統的行為。]

4. 非功能需求

[在這個小節中，主要對該用例所涉及的非功能性需求進行描述。由於其通常很難以在事件流中進行表述，因此單列為一小節進行闡述。這些需求通過包括法律法規、應用程式標準、質量屬性（可用性、可靠性、性能、支持性等）、兼容性、可移植性，以及設計約束等方面的需求。在這些需求的描述方面，一定要注意使其可度量、可驗證，否則就容易流於形式，形同擺設。]

5. 前置條件

[用例的前置條件是執行用例之前必須存在的系統狀態。]

6. 後置條件

[用例的後置條件是用例一執行完畢系統可能處於的一組狀態。]

7. 擴展點

[此用例的擴展點，通常是用例圖中的extent關係。]

用例說明模板2(單列表格式)

編者說明：

如果你覺得文本描述不夠清晰，也可以採用如本文檔模板所示的表格式的描述方式。

用例#	[用例名應是一個動詞短語，應讓讀者一目了然地從名字中就可以知道該用例的目標。]
使用語境	[用例目標，是一個較長的描述，甚至包括觸發條件。]
範圍	[用例的設計範圍，在設計時將系統作為一個黑盒來考慮。]
級別	[概要、用戶目標、子功能三者之一。]
主執行者	[也就是該用例的主Actor，在此應列出其名稱，並簡要描述。]
項目相關人員利益	項目相關人員			利益
	[項目相關人員名稱]			[項目相關人員取得的利益]
	……			……
前置條件	[也就是激發該用例，所應該滿足的條件。]
後置條件	[也就是該用例完成之後，將執行什麼動作。]
成功保證	[描述當目標完成後，環境的變化情況。]
觸發事件	[什麼引發用例，例如時間事件。]
描述	步驟		活動
	1		[在這裡寫出觸發事件到目標完成以及清除的步驟。]
	2		[……]
	3
擴展	步驟	分支動作
	1a	[引起分支的條件]
	[活動或子用例名稱]
技術和數據變化
	1	[變化列表]

用例說明模板3(雙列表格式)

編者說明：

本模板是對上一模板的補充，如果你想更好地捕捉系統的響應，那麼就可以採用本表格所示的格式。

有時，為了更好地捕獲系統的響應，對於場景描述（主成功場景、擴展場景）在上表的基礎上變成如下表所示的雙列：

步驟

用戶

系統

用例說明模板4(文本式)

編者說明：

相信用過用例分析技術的，對用例應該多少細有很大的疑問，而Alistair Cockburn率先將其進行分級：概要、用戶目標、子功能，如果你對他的思想有認同，則該模板就適合於你。

1.用例名：

[用例名應是一個動詞短語，應讓讀者一目了然地從名字中就可以知道該用例的目標。]

2.使用語境：

[用例目標，是一個較長的描述，甚至包括觸發條件。]

3.範圍：

[用例的設計範圍，在設計時將系統作為一個黑盒來考慮。]

4.級別：

[用來表示該用例是在描述哪個級別上的功能，通常包括概要、用戶目標、子功能三種。這三種級別的劃分是Alistair Cockburn在《編寫有效用例》一書是提出的。]

5.主執行者：

[也就是該用例的主Actor，在此應列出其名稱，並給予簡要描述。]

6. 項目相關人員利益

[說明該用例對項目相關人員能夠帶來什麼好處。]

7. 前置條件：

[也就是激發該用例，所應該滿足的條件。]

8. 後置條件：

[也就是該用例完成之後，將執行什麼動作。]

9. 成功保證：

[描述當目標完成後，環境的變化情況。]

10. 觸發事件：

[什麼引發用例，例如時間事件。]

11. 主成功場景

[在這裡寫出觸發事件到目標完成以及清除的步驟。]

[步驟編號＃：動作描述]

[步驟編號＃：動作描述]

……

12. 擴展：

[在這裡寫出擴展情況，每次寫一個擴展，每個擴展都應指向主場景的特定步驟。]

[被改變步驟 條件：動作或子用例]

……

13. 技術和數據變化列表

[在這裡寫出場景中因技術或數據變化而引起的可能分支。]

[步驟或變化編號＃：變化列表]

[步驟或變化編號＃：變化列表]

……

14. 相關信息

[項目所需要的所有附加信息。]

數據要求說明書(ISO標準)

編者說明：

如果在你的項目中有大量要求數據存儲、數據採集等方面的需求，那麼你就應該專門將這些需求進行整理，以數據要求說明書的形式表現出來。

1．引言

1.1編寫目的

[說明編寫這份數據要求說明書的目的，指出預期的讀者。]

1.2背景

a.待開發軟體系統的名稱；

b.列出本項目的任務提出者、開發者、用戶以及將運行該項軟體的計算站或計算機網絡系統。

1.3定義

[列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。]

1.4參考資料

[列出有關的參考資料。]

2．數據的邏輯描述

[對數據進行邏輯描述時可把數據分為動態數據和靜態數據。]

2.1靜態數據

[列出所有作為控制或參考用的靜態數據元素。]

2.2動態輸入數據

[列出動態輸入數據元素。]

2.3動態輸出數據

[列出動態輸出數據元素。]

2.4內部生成數據

[列出向用戶或開發單位中的維護調試人員提供的內部生成數據。]

2.5數據約定

[說明對數據要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制。對於在設計和開發中確定是臨界性的限制更要明確指出。]

3．數據的採集

3.1要求和範圍

[按數據元的邏輯分組來說明數據採集的要求和範圍，指明數據的採集方法，說明數據採集工作的承擔者是用戶還是開發者。]

3.2輸入的承擔者

[說明預定的對數據輸入工作的承擔者。如果輸入數據同某一接口軟體有關，還應說明該接口軟體的來源。]

3.3預期處理

[對數據的採集和預處理過程提出專門的規定，包括適合應用的數據格式、預定的數據通信媒體和對輸入的時間要求等。對於需經模擬轉換或數字轉換處理的數據量，要給出轉換方法和轉換因子等有關信息，以便軟體系統使用這些數據。]

3.4影響

[說明這些數據要求對於設備、軟體、用戶、開發單位所可能產生的影響。]

三、系統分析與設計類

軟體體系結構設計說明書[XuFeng7]

編者說明：

隨著OO方法論地日臻成熟，其思想也從編程（OOP）到了設計（OOD）和分析（OOA），而軟體體系結構則是從設計的最高層進行設計與規劃的技術，本文檔模板就是用來幫助你從用例視圖、邏輯視圖、進程視圖、部署視圖等方面對系統進行總體描述。

1.文檔簡介

[本節主要是描述軟體體系結構設計說明書的目的、範圍、相關術語、參考資料和本文檔的摘要性介紹。軟體體系結構設計屬於高層設計文檔，是符合現代軟體工程要求的概要設計。]

1.1 目的

[軟體體系結構設計說明書，將從設計的角度對系統進行綜合的描述，使用不同的視圖來描述其不同方面。在本小節中，將對該文檔的結構進行簡要的說明，明確該文檔針對的讀者群，指導他們正確的地使用該文檔。]

1.2 範圍

[說明該文檔所涉及的內容範圍，以及將影響的內容。]

1.4參考資料

1.5 概述

[在本小節中，主要是說明軟體體系結構設計說明書各個部分所包含的主要內容，就像一個文章摘要一樣。同時也應該對文檔的組織方式進行解釋。]

2. 體系結構表示方式

[本節說明軟體體系結構在當前系統中的作用及其表示方式。它將列舉其所必需的用例視圖、邏輯視圖、進程視圖、部署視圖或實施視圖，並分別說明這些視圖包含哪些類型的模型元素。]

3. 軟體體系結構的目標和約束

[本節說明對軟體體系結構具有某種重要影響的軟體需求和用戶目標，例如，系統安全性、保密性、第三方組件的使用、可移植性、發布和重新使用。它還要記錄可能適用的特殊約束：設計與實施策略、開發工具、團隊結構、時間表、遺留系統等。]

4.用例視圖

[本節使用用例分析技術所生成的系統用例模型，描述其中的一些用例或場景。在該模型中納入用例或場景，應該是系統中最重要、最核心的功能部分。]

[另外，在本節中還應該選擇一個主要的用例，對其進行描述與解釋，以幫助讀者了解軟體的實際工作方式，解釋不同的設計模型元素如何幫助系統實現。]

5. 邏輯視圖

[邏輯視圖主要是反映系統本質的問題領域類模型，在邏輯視圖中將列出組成系統的子系統、包。而對每個子系統、包分解成為一個個類，並說明這些關鍵的實體類的職責、關係、操作、屬性。這也是OO思想的體現，以類、類與類之間的協作、包、包與包之間的協作模型來表達系統的邏輯組織結構。]

5.1概述

[在本小節中，列出邏輯視圖的頂層圖，該圖將反映系統由哪些包組成，每個包之間的關係與協作，以及包的層次結構。使得讀者對整個軟體體系結構有一個整體的了解。]

5.2影響軟體體系結構的重要設計包

[在本小節中，將從邏輯視圖中選擇有重要意義的設計包，每個設計包有一個小節來描述，說明這些包的名稱、簡要的說明、該包中的主要類和相關的類圖。對於包中的重要的類，還應該說明其名稱、簡要說明、主要職責、操作、屬性等。]

6. 進程視圖

[本節主要描述該軟體體系結構下，系統運行態的情況。描述系統在執行時，包括哪些進程（包括線程、進程、進程組），以及它們之間是如何進行通信的、如何進行消息傳遞、接口如何。並且來說明如何進行組織。]

7.部署視圖

[本節主要描述該軟體系統部署後的樣子，需要哪些硬體、支撐軟體、網絡環境。在每個物理節點上所運行的模塊，它們之間是如何連接的，這些物理節點與進程之間的映射關係等等。]

8.實施視圖

[本節主要從開發的角度來描述軟體系統架構，包括其整體結構、層次結構、子系統，以及要使用的第三方控制項，自定義控制項，以及它們之間的接口。]

8.1概述

[在本小節中，說明各個層的內容、邊界與交互，通常用UML中的構件圖進行表示。]

8.2層

[本小節則是在上一小節的基礎上，對每一個層進行說明，並給出每一個層的構件圖，幫助讀者分而治之。]

概要設計說明書(ISO標準)

編者說明：

這是ISO提供的規範，是最原始的概要設計說明書的編寫格式，其適用於結構化設計思想下的軟體設計，不過其中還是有很多具有參考價值的內容。

1．引言

1.1編寫目的

[說明編寫這份概要設計說明書的目的，指出預期的讀者。]

1.2背景

a.[待開發軟體系統的名稱；]

b.[列出本項目的任務提出者、開發者、用戶。]

1.3定義

[列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。]

1.4參考資料

2．總體設計

2.1需求規定

[說明對本系統的主要的輸入輸出項目、處理的功能性能要求。包括]

2.1.1系統功能

2.1.2系統性能

2.1.2.1精度

2.1.2.2時間特性要求

2.1.2.3可靠性

2.1.2.4靈活性

2.1.3輸入輸出要求

2.1.4數據管理能力要求

2.1.5故障處理要求

2.1.6其他專門要求

2.2運行環境

[簡要地說明對本系統的運行環境的規定。]

2.2.1設備

[列出運行該軟體所需要的硬設備。說明其中的新型設備及其專門功能。]

2.2.2支持軟體

[列出支持軟體，包括要用到的作業系統、編譯（或彙編）程序、測試支持軟體等。]

2.2.3接口

[說明該系統同其他系統之間的接口、數據通信協議等]

2.2.4控制

[說明控制該系統的運行的方法和控制信號，並說明這些控制信號的來源。]

2.3基本設計概念和處理流程

[說明本系統的基本設計概念和處理流程，儘量使用圖表的形式。]

2.4結構

[給出系統結構總體框圖（包括軟體、硬體結構框圖），說明本系統的各模塊的劃分，扼要說明每個系統模塊的標識符和功能，分層次地給出各模塊之間的控制與被控制關係。]

2.5功能需求與系統模塊的關係

[本條用一張矩陣圖說明各項功能需求的實現同各模塊的分配關係。]

2.6人工處理過程

[說明在本系統的工作過程中不得不包含的人工處理過程。]

2.7尚未解決的問題

[說明在概要設計過程中尚未解決而設計者認為在系統完成之前必須解決的各個問題。]

3．接口設計

3.1用戶接口

[說明將向用戶提供的命令和它們的語法結構，以及相應的回答信息。]

[說明提供給用戶操作的硬體控制面板的定義。]

3.2外部接口

[說明本系統同外界的所有接口的安排包括軟體與硬體之間的接口、本系統與各支持系統之間的接口關係。]

3.3內部接口

[說明本系統之內的各個系統元素之間的接口的安排。]

4．運行設計

4.1運行模塊組合

[說明對系統施加不同的外界運行控制時所引起的各種不同的運行模塊組合，說明每種運行所歷經的內部模塊的支持軟體。]

4.2運行控制

[說明每一種外界的運行控制的方式方法和操作步驟。]

4.3運行時間

[說明每種運行模塊組合將占用各種資源的時間。]

5．系統數據結構設計

[不涉及軟體設計可不包含]

5.1邏輯結構設計要點

[給出本系統內軟體所使用的每個數據結構的名稱、標識符以及它們之中每個數據項、記錄、文卷和系的標識、定義、長度及它們之間的層次的或表格的相互關係。]

5.2物理結構設計要點

[給出本系統內軟體所使用的每個數據結構中的每個數據項的存儲要求，訪問方法、存取單位、存取的物理關係、設計考慮和保密條件。]

5.3數據結構與程序的關係

[說明各個數據結構與訪問這些數據結構的各個程序之間的對應關係。]

6．系統出錯處理設計

6.1出錯信息

[用一覽表的方式說明每種可能的出錯或故障情況出現時，系統輸出信息的形式、含意及處理方法。]

6.2補救措施

[說明故障出現後可能採取的變通措施。包括：]

a. 後備技術 [說明準備採用的後備技術，當原始系統數據萬一丟失時啟用的副本的建立和啟動的技術，例如周期性地把磁碟信息記錄到磁帶上去就是對於磁碟媒體的一種後備技術。]

b. 降效技術 [說明準備採用的後備技術，使用另一個效率稍低的系統或方法來求得所需結果的某些部分，例如一個自動系統的降效技術可以是手工操作和數據的人工記錄。]

c. 恢復及再啟動技術 [說明將使用的恢復再啟動技術，使軟體從故障點恢復執行或使軟體從頭開始重新運行的方法。]

6.3系統維護設計

[說明為了系統維護的方便而在程序內部設計中作出的安排，包括在程序中專門安排用於系統的檢查與維護的檢測點和專用模塊。]

概要設計說明書模板2

編者說明：

這也是一個面向結構化設計思想的概要設計說明書模板，其在ISO規範的基礎上提供了一些更加直觀的方式，是一個很有價值的模板。

第1章 引言

1.1 編寫目的

[說明對程序系統的設計考慮，包括程序系統的基本處理流圖、程序系統的組織結構、模塊劃分、功能分配、接口設計、運行設計、數據結構設計和安全性設計等。為程序的詳細設計奠定基礎。]

1.2 術語

1.3 參考文獻

2.1 系統說明

2.2 系統任務

2.2.1 系統目標

2.2.2 運行環境

2.2.3 與其它系統關係

2.3 需求規定

2.3.1 功能需求

2.3.2 性能需求

2.3.3 數據要求

2.3.4 其它

第3章 總體設計

3.1 系統物理結構

3.1.1 系統流程圖

3.1.2 設備清單

3.2 軟體結構圖

3.2.1 模塊結構圖

3.2.2 模塊清單

4.1 模塊1（標識符）功能

模塊編號：	模塊名稱：	模塊標識符：
輸入	處理	輸出

4.2 模塊2（標識符）功能

第5章 接口設計

5.1 用戶界面

5.2 硬體接口

5.3 軟體接口

5.4 通信接口

第6章 數據結構設計

6.1 數據結構1（標識符）

6.1.1 結構屬性

結構名稱	邏輯標識	物理標識
結構類型	存儲模式	存儲介質
訪問模式	讀/寫方式
記錄標識	記錄長度

6.1.2 邏輯結構

6.1.3 物理結構

6.1.4 數據元素

6.2 數據結構2（標識符）

第7章 運行設計

7.1 運行1

7.1.1 運行模塊組合運行名稱

模塊集合

運行條件

支持軟體

7.1.2 運行控制操作

運行名稱

控制方法

操作步驟

7.1.3 運行時間

運行名稱

所占資源

時間

7.2 運行2

第8章 系統安全

8.1 系統安全

[1、系統安全控制和物理保護措施；]

[2、用戶身份鑑別機制；]

[3、用戶對系統的訪問權限和範圍。]

8.2 數據安全

[1、數據用戶身份鑑別；]

[2、訪問主體、訪問對象的控制策略和實現方法；]

[3、數據加密方法。]

8.3 後備與恢復

[1、系統後備；]

[2、數據後備；]

[3、系統恢復；]

[4、數據恢復。]

8.4 出錯處理

[1、出錯情況；]

[2、出錯信息輸出形式、信息含義、處理方法；]

[3、出錯失效的後備措施。]

8.5 計算機病毒的防治措施

第9章 功能需求、數據結構和模塊

9.1 功能需求與模塊關係

功能模塊	功能1	功能2	…
模塊1	U
模塊2	U	U
模塊3	U
…

9.2 數據結構與模塊關係

數據模塊	數據結構1	數據結構2	…
模塊1	U	C
模塊2	U	U

資料庫設計說明書(ISO版)

編者說明：

如果你的項目中有很多與資料庫相關的內容，則你應該把資料庫設計、表結構設計、視圖設計統一整理形成資料庫設計說明書。

1.引言

1.1編寫目的

[說明編寫這份數據設計說明書的目的，指出預期的讀者。]

1.2背景

a.[待開發資料庫的名稱和使用此資料庫的軟體系統的名稱；]

b.[列出本項目的任務提出者、開發者、用戶。]

1.3定義

1.4參考資料

2．外部設計

2.1標識符的狀態

[聯繫用途，詳細說明用於唯一地標識該資料庫的代碼、名稱或標識符，附加的描述性信息亦要給出。如果該資料庫屬於尚在實驗中、尚在測試中或是暫時使用的，則要說明這一特點及其有效時間範圍。]

2.2使用它的程序

[列出將要使用或訪問此資料庫的所有應用程式，對於這些應用程式的每一個，給出它的名稱和版本號。]

2.3約定

[陳述一個程式設計師或一個系統分析員為了能使用此資料庫而需要了解的建立標號、標識的約定。]

2.4專門指導

[向準備從事此資料庫的生成、從事此資料庫的測試、維護人員提供專門的指導。]

2.5支持軟體

[簡單介紹同此資料庫直接有關的支持軟體。說明這些軟體的名稱、版本號的主要功能特性。列出這些支持軟體的技術文件的標題、編號及來源]

3．結構設計

3.1概念結構設計

[說明本資料庫將反映的現實世界中的實體、屬性和它們之間的關係等的原始數據形式，包括各數據項、記錄、系、文卷的標識符、定義、類型、度量單位和值域，建立本資料庫的每一幅用戶視圖。]

3.2邏輯結構設計

[說明把上述原始數據進行分解、合併後重新組織起來的資料庫全局邏輯結構。]

3.3物理結構設計

[建立系統程式設計師視圖。]

4．運用設計

4.1數據字典設計

[對資料庫設計中涉及到的各種項目一般要建立起數據字典，以說明它們的標識符、同義名及有關信息。]

4.2安全保密設計

[說明在資料庫的設計中，將如何通過區分不同的訪問者、不同的訪問類型和不同的數據對象，進行分別對待而獲得的資料庫安全保密的設計考慮。]

詳細設計說明書(ISO標準)

編者說明：

概要設計通常是項目中專門的人員完成，是對系統的高層描述，而詳細設計的任務則通常由每一個任務實施人來完成，其是對某個具體的模塊、類等局部元素的設計描述。該模板是ISO推薦的格式，其仍然是以結構化設計為主要思想。

1.引言

1.1編寫目的

[說明編寫這份詳細設計說明書的目的，指出預期的讀者。]

1.2背景

a. [待開發系統的名稱；]

b. [列出本項目的任務提出者、開發者、用戶。]

1.3定義

1.4參考資料

2. 系統的結構

[給出系統的結構框圖，包括軟體結構、硬體結構框圖。用一系列圖表列出系統內的每個模塊的名稱、標識符和它們之間的層次結構關係。]

3．模塊1（標識符）設計說明

[從本章開始，逐個地給出各個層次中的每個模塊的設計考慮。以下給出的提綱是針對一般情況的。對於一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。]

3.1模塊描述

[給出對該基本模塊的簡要描述，主要說明安排設計本模塊的目的意義，並且，還要說明本模塊的特點。]

3.2功能

[說明該基本模塊應具有的功能。]

3.3性能

[說明對該模塊的全部性能要求。]

3.4輸入項

[給出對每一個輸入項的特性。]

3.5輸出項

[給出對每一個輸出項的特性。]

3.6設計方法（算法）

[對於軟體設計，應詳細說明本程序所選取用的算法，具體的計算公式及計算步驟。]

[對於硬體設計，應詳細說明本模塊的設計原理、元器件的選取、各元器件的邏輯關係，所需要的各種協議等。]

3.7流程邏輯

[用圖表輔以必要的說明來表示本模塊的邏輯流程。]

3.8接口

[說明本模塊與其它相關模塊間的邏輯連接方式，說明涉及到的參數傳遞方式。]

3.9存儲分配

[根據需要，說明本模塊的存儲分配。]

3.10注釋設計

[說明安排的程序注釋。]

3.11限制條件

[說明本模塊在運行使用中所受到的限制條件。]

3.12測試計劃

[說明對本模塊進行單體測試的計劃，包括對測試的技術要求、輸入數據、預期結果、進度安排、人員職責、設備條件、驅動程序及樁模塊等的規定。]

3.13尚未解決的問題

[說明在本模塊的設計中尚未解決而設計者認為在系統完成之前應解決的問題。]

4．模塊2（標識符）設計說明

[用類似第3條的方式，說明第2個模塊乃至第N個模塊的設計考慮。]

詳細設計說明書模板2

編者說明：

該模板也是以結構化設計的主要思想，在ISO標準的基礎上進行了適當的修改與完善。如果你採用的是面向對象的思想，那麼通常該文檔被類圖、順序圖、交互圖、活動圖、狀態圖等描述類靜態結構與動態行為的圖表所代替，而不再專門的形成文檔。

1.引言

1.1編寫目的

[說明軟體系統各個層次的每個程序（每個模塊或子程序）的設計考慮。]

1.2 系統說明

[任務提出單位：]

1.3 術語

1.4參考資料

序號

資料名

文件編號

發表日期

出版單位

2.軟體結構

2.1 軟體結構圖

[模塊結構圖]

2.2 模塊子結構圖

[1.模塊內部結構圖；]

[2.子模塊清單。]

2.3 模塊清單

編 號

模塊名稱

模塊標識符

3. 模塊設計

3.1 模塊1 （標識符）

3.1.1 模塊概述

[包括模塊的簡要情況以及屬性。]]

3.1.2 功能和性能

3.1.2.1 （標識符）功能（IPO圖）

輸入

處理

輸出

3.1.2.2 性能

3.1.3 輸入/輸出項

3.1.3.1 輸入項

名稱

標識符

類型

介質

來源

描述

3.1.3.2 輸出項

名稱

標識符

類型

介質

來源

描述

3.1.4 數據結構

3.1.4.1 全局數據結構

3.1.4.2 局部數據結構

名稱

標識符

類型

使用方式

訪問方式

描述

3.1.5 算法

[Ｎ－Ｓ 圖、ＰＡＤ圖或ＰＤＬ語言。]

3.1.6 限制條件

[模塊的所有限制條件。]

3.1.7 測試計劃

[1.驅動模塊和樁模塊；]

[2.前置條件；]

[3.測試用例：輸入和預期結果。]

3.2 模塊2

四、軟體質量保證類

測試計劃

編者說明：

要想系統性地完成一件事，首先要做好計劃，測試工作是十分重要的，因此測試計劃也是十分必要的。該文檔適用於集成測試、系統測試、驗收測試的計劃制訂，並不適用於單元測試計劃。

第1章 引言

1.1 綜述

1.2 參考文獻

2.1 測試項

2.2 不測試的軟體項

特性或組合名稱	測試設計說明編號
特性或組合名稱	測試設計說明編號

第5章 方法

5.1 <方法名稱

5.2 <方法名稱

第6章 項通過準則

第7章 暫停標準和再啟動要求

7.1 暫停標準

7.2 再啟動要求

第8章 應提供的測試文檔

文檔名稱	標識符
序號	任務	前期任務	特殊技能	責任人	工作量（天）	完成日期

第10章 環境要求

10.1 硬體

10.2 軟體

10.3 安全性

10.4 工具

10.5 文檔

第11章 職責

11.1 測試組

11.2 開發組

11.3 ……

第12章 人員和培訓要求

12.1 人員

12.1.1 測試組

12.2 培訓

第13章 進度

13.1 進度

序號

測試任務名稱

工作量

開始日期

完成日期

13.2 測試資源使用期限

第14章 風險和應急

測試日誌

編者說明：

測試都有一個結果，而這些結果對於軟體質量保證活動來說是十分重要的，因此應該將這些結果有序地記錄下來，這就是測試日誌模板所要解決的問題。

第1章 描述

1.1 測試項

1.2 測試的環境

1.2.1 硬體

1.2.2 軟體

第2章 活動和事件條目

2.1 <日期

時間

活動描述

事件

2.2 <日期

測試設計說明

編者說明：

如果說測試計劃是對測試的活動、人員進行安排，那麼測試設計則是對測試方法、測試技術的說明。

第1章 被測試的特性

1.1 單項特性

1.2 組合特性

1.3 引用文檔

第2章 方法詳述

2.1 方法描述

2.2 測試評價標準

2.3 測試用例選擇原則

2.4 測試用例的共同屬性和依賴關係

測試用例說明

編者說明：

測試計劃解決的是怎麼安排測試活動，測試設計說明是怎麼測試，那麼測試用例說明就是測試什麼，也就是列出具體的測試項目，以使得測試有目的、有計劃。

第1章 測試項

1.1 測試項名稱

1.2 引用文檔

序號

名稱

值

類型

允許誤差

輸出方式

第4章 環境要求

4.1 硬體

4.2 軟體

4.3 其它

第5章 特殊的規程要求

第6章 用例間的依賴關係

6.1 所依賴的用例

序號

用例名稱或標識

6.2 依賴關係的性質

集成測試計劃(ISO標準)

編者說明：

前面的測試計劃模板是一個通用性的，也可以是用於制定所有測試活動的計劃，而本模塊則是用來指導編寫集成測試計劃的。

1.引言

1.1編寫目的

[說明編寫這份測試計劃目的，指出預期的讀者。]

1.2背景

a. 待開發系統的名稱；

b. 列出本項目的任務提出者、開發者、用戶。

1.3定義

1.4參考資料

2．計劃

2.1系統說明

[提供一份圖表，並逐項說明被測系統的功能、輸入、輸出等質量指標，作為敘述測試計劃的提綱。]

2.2測試內容

[列出集成測試和確認測試中的每一項測試內容的名稱標識符、這些測試的進度安排以及這些測試的內容和目的。]

2.3測試1（標識符）

[給出這項測試內容的參與單位及被測試的部位。]

2.3.1進度安排

[給出對這項測試的進度安排，包括進行測試的日期和工作內容。]

2.3.2條件

[陳述本項測試工作對資源的要求。包括：]

a. 硬體

b. 軟體

c. 人員

2.3.3測試資料

[列出本項測試所需的資料。]

2.3.4測試培訓

[說明或引用資料說明為被測系統的使用提供培訓的計劃。規定培訓的內容、受訓的人員及從事培訓的工作人員。]

2.4測試2（標識符）

[用與本測試計劃2。3條相類似的方式說明用於另一項及其後各項測試內容的測試工作計劃。]

[……]

3．測試設計說明

3.1測試1（標識符）

[說明對第一項測試內容的測試設計考慮。]

3.1.1控制

[說明本測試的控制方式。]

3.1.2輸入

[說明本項測試中所使用的輸入數據及選擇這些輸入數據的策略。]

3.1.3輸出

[說明預期的輸出數據。]

3.1.4過程

[說明完成此項測試的一個個步驟和控制命令。]

3.2測試2（標識符）

[用與本測試計劃3。1條相類似的方式說明第2項及其後各項測試工作的設計考慮。]

[……]

4．評價準則

4.1範圍

[說明所選擇的測試用例能夠檢查的範圍及其局限性。]

4.2數據整理

[陳述為了把測試數據加工成便於評價的適當形式，使得測試結果可以同已知結果進行比較而要用到的轉換處理技術；如果是用自動方式整理數據，還要說明為進行處理而要用到的硬體、軟體資源。]

4.3尺度

[說明用來判斷測試工作是否能通過的評價尺度，如合理和輸出結果的類型、測試輸出結果與預期輸出之間的容許偏離範圍、允許中斷或停機的最大數。]

軟體集成測試工作流程指南

編者說明：

嚴格地說，該文檔不屬於文檔模板，它只是一個工作指南。要想更好地完成集成測試工作，你就需要為團隊制定一個工作指南。你可以根據該文檔，結合實際進行修改。

1. 簡介

1.1目的

本文詳細闡述了集成測試流程，指導項目開發人員如何開展軟體集成測試。

1.2範圍

此指南可運用於使用RUP的任一軟體項目的集成測試。

1.3參考文件

Software Test Process

Rational Unified Process

1.4定義與縮寫

RUP：統一開發過程

SIT：軟體集成測試

SEPG：軟體工程過程小組

SQA：軟體質量保證

2. 集成測試指南

2.1 簡介

集成測試的目的是確保各單元組合在一起後能夠按既定意圖協作運行，並確保增量的行為正確。它所測試的內容包括單元間的接口以及集成後的功能。使用黑盒測試方法測試集成的功能。並且對以前的集成進行回歸測試。

2.2單元測試工作內容及其流程

活動	輸入工件	輸出工件	參與角色和職責
制定集成測試計劃	設計模型集成構建計劃	集成測試計劃	測試設計員負責制定集成測試計劃
設計集成測試	集成測試計劃設計模型	集成測試用例測試過程	測試設計員負責設計集成測試用例和測試過程。
實施集成測試	集成測試用例測試過程工作版本	測試腳本（可選）測試過程（更新）	測試設計員負責編制測試腳本（可選），更新測試過程。
		驅動程序或穩定樁	設計員負責設計驅動程序和樁，實施員負責實施驅動程序和樁。
執行集成測試	測試腳本（可選）工作版本	測試結果	測試員負責執行測試並記錄測試結果
評估集成測試	集成測試計劃測試結果	測試評估摘要	測試設計員負責會同集成員、編碼員、設計員等有關人員（具體化）評估此次測試，並生成測試評估摘要。

2.3集成測試需求獲取

集成測試需求所確定的是對某一集成工作版本的測試的內容，即測試的具體對象。集成測試需求主要來源於設計模型（Design Model）和集成構件計劃（Integration Build Plan ）。

集成測試著重於集成版本的外部接口的行為。因此，測試需求須具有可觀測、可測評性。

1.集成工作版本應分析其類協作與消息序列，從而找出該工作版本的外部接口。

2.由集成工作版本的外部接口確定集成測試用例。

3.測試用例應覆蓋工作版本每一外部接口的所有消息流序列。

注意：一個外部接口和測試用例的關係是多對多，部分集成工作版本的測試需求可映射到系統測試需求，因此對這些集成測試用例可採用重用系統測試用例技術。

2.4集成測試工作機制

軟體集成測試工作由產品評測部擔任。需要項目組相關角色配合完成。如圖示：

軟體評測部：

2.5集成測試產生的工件清單

1、軟體集成測試計劃

2、集成測試用例

3、測試過程

4、測試腳本

5、測試日誌

6、測試評估摘要

軟體系統測試工作指南

編者說明：

這是一個系統測試的工作指南。你可以根據該文檔，結合實際進行修改。

1. 簡介

1.1 目的

本文詳細闡述了系統測試的類型以及各個類型的基本測試方法，指導項目開發人員進行軟體系統測試。

1.2 範圍

本文適用於使用RUP 的所有軟體項目的系統測試工作。

1.3 文檔結構

第一部分：簡介，介紹軟體系統測試指南的目的，本指南的適用範圍，以及在本文檔中使用的術語的解釋。

第二部分：描述系統測試指南。包括系統測試流程、系統測試需求的獲取、系統測試側策略選擇、系統測試技術和方法等。

第三部分：列出本指南使用的參考文獻。

1.4 詞彙表

系統測試（System Testing）：系統測試是通過與系統的需求規格作比較，發現軟體與系統需求規格不相符合或與之矛盾的地方。它將通過確認測試的軟體，作為整個基於計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、數據和人員等其他系統元素結合起來，在實際運行（使用）環境下，對計算機系統進行的測試。

黑盒測試（Black-Box Testing）：黑盒測試是基於系統需求規格，在不知道系統或組件的內部結構的情況下進行的測試。通常又將黑盒測試叫做：基於規格的測試（Specification-Based Testing）、輸入輸出測試（Input/Output Testing ）、功能測試（Functional Testing ）。

2. 系統測試指南

2.1 系統測試過程

活動名稱	輸入工件	輸出工件	參與角色
制定系統測試計劃	軟體需求工件軟體項目計劃	系統測試計劃	測試設計員
設計系統測試	系統測試計劃軟體需求工件	系統測試用例系統測試過程	測試設計員
實施系統測試	系統測試計劃工作版本	系統測試腳本	測試設計員
執行系統測試	系統測試計劃系統測試用例系統測試過程系統測試腳本	測試結果	測試員
評估系統測試	測試結果	測試分析報告變更請求	測試設計員相關組

2.2 系統測試需求獲取

系統測試需求所確定的是測試的內容，即測試的具體對象。系統測試需求主要來源於需求工件集，它可能是一個需求規格說明書，或是由前景、用例、用例模型、詞彙表、補充規約組成的一個集合。

在分析測試需求時，可應用以下幾條一般規則：

1） 測試需求必須是可觀測、可測評的行為。如果不能觀測或測評的測試需求，就無法對其進行評估，以確定需求是否已經滿足。

2） 在每個用例或系統的補充需求與測試需求之間不存在一對一的關係。用例通常具有多個測試需求；有些補充需求將派生一個或多個測試需求，而其他補充需求（如市場需求或包裝需求）將不派生任何測試需求。

3） 在需求規格說明書中每一個功能描述將派生一個或多個測試需求，性能描述、安全性描述等也將派生出一個或多個測試需求。

1. 功能性測試需求

功能性測試需求來自於測試對象的功能性說明。每個用例至少會派生一個測試需求。對於每個用例事件流，測試需求的詳細列表至少會包括一個測試需求。對於需求規格說明書中的功能描述，將至少派生一個測試需求。

2. 性能測試需求

性能測試需求來自於測試對象的指定性能行為。性能通常被描述為對響應時間和資源使用率的某種評測。性能需要在各種條件下進行評測，這些條件包括：

1）不同的工作量和/或系統條件

2）不同的用例/功能

3）不同的配置

4）性能需求在補充規格或需求規格說明書中的性能描述部分中說明。

對包括以下內容的語句要特別注意：

1）時間語句，如響應時間或定時情況

2）指出在規定時間內必須出現的事件數或用例數的語句

3）將某一項性能的行為與另一項性能的行為進行比較的語句

4）將某一配置下的應用程式行為與另一配置下的應用程式行為進行比較的語句

5）一段時間內的操作可靠性（平均故障時間或 MTTF）

6）配置或約束

應該為規格中反映以上信息的每個語句生成至少一個測試需求。

3. 其它測試需求

其它測試需求包括配置測試、安全性測試、容量測試、強度測試、故障恢復測試、負載測試等測試需求可以從非功能性需求中發現與其對應的描述。每一個描述信息可以生成至少一個測試需求。

2.3 系統測試策略

測試策略用於說明某項特定測試工作的一般方法和目標。系統測試策略主要針對系統測試需求確定測試類型及如何實施測試的方法和技術。

一個好的測試策略應該包括要實施的測試類型和測試的目標、所採用的技術、用於評估測試結果和測試是否完成的標準、對測試策略所述的測試工作存在影響的特殊事項等內容。

2.3.1 系統測試類型和目標

確定系統測試策略首先應清楚地說明所實施系統測試的類型和測試的目標。清楚地說明這些信息有助於儘量避免混淆和誤解（尤其是由於有些類型測試看起來非常類似，如強度測試和容量測試）。測試目標應該表明執行測試的原因。

系統測試的測試類型一般包括：功能測試（Functional Testing）、性能測試（Performance Testing）負載測試（Load Testing）、強度測試（Stress Testing）、容量測試（Volume Testing）、安全性測試（Security Testing）、配置測試（Configuration Testing）、故障恢復測試（Recovery Testing）、安裝測試（Installation Testing）、文檔測試（Documentation Testing）、用戶界面測試（GUI Testing）等等。

其中，功能測試、配置測試、安裝測試等在一般情況下是必需的。而其它的測試類型則需要根據軟體項目的具體要求進行裁剪。

2.3.2 採用的測試技術

系統測試主要採用黑盒測試技術設計測試用例來確認軟體滿足需求規格說明書的要求。

2.4 系統測試的工作機制

1）項目組為每一個軟體項目成立測試組，確定測試經理（通常由測試設計員擔任）一名，測試設計員和測試員若干。

2）項目組需要提供系統測試需要的輸入，建立測試環境，以及對測試工件進行配置管理。

2.5 系統測試產生的工件清單

1）軟體系統測試計劃

2）系統測試用例

3）系統測試過程

4）測試腳本（可選）

5）測試結果

6）測試分析報告

測試分析報告(GB標準)

編者說明：

測試完成後，將會形成一些測試日誌，對於每個測試用例也有了一個反饋的結果，那麼從這個數據中看出問題、找到問題以及尋找解決問題的方法，那就是測試分析報告所要完成的事了。

1.引言

1.1 編寫目的

[說明這份測試分析報告的具體編寫目的，指出預期的閱讀範圍。]

1.2 背景

[說明：]

[ a. 被測試軟體系統的名稱；]

[ b. 該軟體的任務提出者、開發者、用戶及安裝此軟體的計算中心，指出測試環境與實際運行環境之間可能存在的差異以及這些差異對測試結果的影響。]

1.3 定義

[列出本文件中用到的專問術語的定義和外文首字母組詞的原詞組。]

1.4 參考資料

[列出要用到的參考資料，如：]

[ a. 本項目的經核准的計劃任務書或合同、上級機關的批文；]

[ b. 屬於本項目的其他已發表的文件；]

[ c. 本文件中各處引用的文件、資料，包括所要用到的軟體開發標準。]

[列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。]

2.測試概要

[用表格的形式列出每一項測試的標識符及其測試內容，並指明實際進行的測試工作內容與測試計劃中預先設計的內容之間的差別，說明作出這種改變的原因。]

3.測試結果及發現

3.1 測試1（標識符）

[把本項測試中實際得到的動態輸出（包括內部生成數據輸出）結果同對於動態輸出的要求進行比較，陳述其中的各項發現。]

3.2 測試2（標識符）

[用類似本報告 3.1條的方式給出第 2項及其後各項測試內容的測試結果和發現。]

4.對軟體功能的結論

4.1功能1（標識符）

4.1.1 能力

[簡述該項功能，說明為滿足此項功能而設計的軟體能力以及經過一項或多項測試已證實的能力。]

4.1.2 限制

[說明測試數據值的範圍（包括動態數據和靜態數據），列出就這項功能而言，測試期間在該軟體中查出的缺陷、局限性。]

4.2 功能2（標識符）

[用類似本報告4.l的方式給出第2項及其後各項功能的測試結論。]

......

5 分析摘要

5.1 能力

[陳述經測試證實了的本軟體的能力。如果所進行的測試是為了驗證一項或幾項特定性能要求的實現，應提供這方面的測試結果與要求之間的比較，並確定測試環境與實際運行環境之間可能存在的差異對能力的測試所帶來的影響。]

5.2 缺陷和限制

[陳述經測試證實的軟體缺陷和限制，說明每項缺陷和限制對軟體性能的影響，並說明全部測得的性能缺陷的累積影響和總影響。]

5.3 建議

[對每項缺陷提出改進建議，如：]

[ a. 各項修改可採用的修改方法；]

[ b. 各項修改的緊迫程度；]

[ c. 各項修改預計的工作量；]

[ d. 各項修改的負責人。]

5.4 評價

[說明該項軟體的開發是否已達到預定目標，能否交付使用。]

6 測試資源消耗

[總結測試工作的資源消耗數據，如工作人員的水平級別數量、機時消耗等。]

測試規程說明

編者說明：

軟體測試就像生產線上的產品測試一樣，需要專業的技能與工作方法，而測試規程則是確保每次測試動作高度統一。

第1章 目的

1.1 一般目的

1.2 執行的測試用例

序號	測試用例名稱或標識符

第2章 特殊要求

2.1 前繼規程

序號	前繼規程的名稱或標識符

2.2 專門技能

2.3 特殊環境

2.4 其它

第3章 規程步驟

3.1 日誌

3.2 準備

3.3 啟動

3.4 處理

3.5 度量

3.6 暫停

3.7 再啟動

3.8 停止

3.9 清除

3.10 應急

計算機軟體測試文件編制規範

編者說明：

測試是一個複雜、系統化的工作，也是一個內容廣泛的課題，其間將產生大量的文檔。本文檔就是一個指導所有這些文檔編寫的規範。你可以根據自己的實際，對其修改，以適用於你的開發團隊。

1.引言

1.1 目的和作用

本規範規定一組軟體測試文件。測試是軟體生存周期中一個獨立的、關鍵的階段，也是保證軟體質量的重要手段。為了提高檢測出錯誤的機率，使測試能有計劃地、有條不紊地進行地進行，就必須要編制測試文件。而標準化的測試文件就如同一種通用的參照體系，可達到便於交流的目的。文件中所規定的內容可以作為對測試過程完備性的對照檢查表，故採用這些文件將會提高測試過程的每個階段的能見度，極大地提高測試工作的可管理性。

1.2 適用對象及範圍

本規範是為軟體管理人員、軟體開發人員和軟體維護人員、軟體質量保證人員、審計人員、客戶及用戶制定的。

本規範用於描述一組測試文件，這些測試文件描述測試行為。本規範定義每一種基本文件的目的、格式和內容。所描述的文件著重於動態測試過程，但有些文件仍適用其它種類的測試活動。

本規範可應用於數字計算機上運行的軟體。它的應用範圍不受軟體大小、複雜度或重要性的限制，本規範既適用於初始開發的軟體測試文件編制，也適用於其後的軟體產品更新版本的測試文件編制。

本規範並不要求採用特定的測試方法學、技術及設備或工具。對文件控制、配置管理或質量保證既不指明也不強制特定的方法學。根據所用的方法學，可能需要增加別的文件（如「質量保證計劃」）。

本規範既適用於紙張上的文件，也適用於其它媒體上的文件。如果電子文件編制系統不具有安全的批准註冊機制，則批准簽字的文件必須使用紙張。

2.引用標準

GB/T 11457 軟體工程術語

GB 8566 計算機軟體開發規範

GB 8567 計算機軟體產品開發文件編制指南

3.定義

本章定義本規範中使用的關鍵術語。

3.1 設計層 design level

軟體項的設計分解（如系統、子系統、程序或模塊）。

3.2 通過準則 pass criteria

判斷一個軟體項或軟體特性的測試是否通過的判別依據。

3.3 軟體特性 software feature

軟體項的顯著特性。（如功能、性能或可移植性等）。

3.4 軟體項 software item

原始碼、目標代碼、作業控制代碼、控制數據或這些項的集合。

3.5 測試項 test item

作為測試對象的軟體項。

4.概述

4.1 主要內容

本規範確定了各個測試文件的格式和內容，所提出的文件類型包括測試計劃、測試說明和測試報告。

測試計劃描述測試活動的範圍、方法、資源和進度。它規定被測試的項、被測試的特性、應完成的測試任務、擔任各項工作的人員職責及與本計劃有關的風險等。

測試說明包括三類文件：

（1）測試設計說明：詳細描述測試方法，規定該設計及其有關測試所包括的特性，還規定完成測試所需的測試用例和測試規程，並規定特性的通過準則。

（2）測試用例說明：列出用於輸入的具體值以及預期的輸出結果，並規定在使用具體測試用例時，對測試規程的各種限制。將測試用例與測試設計分開，可以使它們用於多個設計並能在其它情形下重複使用。

（3）測試規程說明：規定對於運行系統和執行指定的測試用例來實現有關測試設計所要求的所有步驟。

測試報告包括四類文件：

（1）測試項傳遞報告：指明在開發組和測試組獨立工作的情況下或者在希望正式開始測試的情況下為進行測試而被傳遞的測試項。

（2）測試日誌：測試組用於記錄測試執行過程中發生的情況。

（3）測試事件報告：描述在測試執行期間發生並需進一步調查的一切事件。

（4）測試7總結報告：總結與測試設計說明有關的測試活動。

這些文件同其它文件在編制方面的關係以及同測試過程的對應關係如圖1所示。

4.2 實施靈活性

在GB 8567中，涉及軟體測試的文件有「測試計劃」及「測試分析報告」。本規範中的八個測試文件是上述二個文件的補充和細化，這樣可使文件的書定更具體、更有參照性，其中測試計劃可細化為本規範的測試計劃、測試設計說明、測試用例說明及測試規程說明，測試分析報告可細化為本規範的測試項傳遞報告、測試日誌、測試事件報告及測試總結報告。

使用本規範的每個單位，要規定測試階段所應有的特定文件，並在測試計劃中規定測試完成後所能提交的全部文件。對於不同的設計層或不同規模的軟體，所選文件的種類也可有所不同。

在所提供的每個標準文件中，每一章的內容對於具體的應用和特定的測試階段可以有所增減。不僅可以調整內容，還可以在基本文件集中增加另外的文件。任何一個文件都可以增加新的內容，並且某章若無可寫的內容，則可不寫，但須保留該章的編號。使用本規範的每個單位應該補充規定對內容的要求和約定，以便反映自己在測試、文件控制、配置管理和質量保證方面所用的特定方法、設備和工具。

附錄A（參考件）中，將敘述文件編制實施及使用指南。

4.3 總體要求

以下將敘述各個測試文件的書寫格式及內容。對於每一個文件而言各章應按指定的次序排列，補充的章可以放在最後或放在「批准」一章的前面（如果該文件最後一章是「批准」的話）。如果某章的部分或全部內容在另一文件中，則應在相應的內容位置上列出所引用的材料，引用的材料必須附在該文件後面或交給文件的使用者。

5.內容要求

5.1 測試計劃

測試計劃結構如下圖所示。

下面給出每一章的詳細內容：

5.1.1測試計劃名稱（本計劃的第1章）

為本測試計劃取現代戰爭專用的名稱。

5.1.2引言（本計劃的第2章）

歸納所要求測試的軟體項和軟體特性，可以包括系統目標、背景、範圍及引用材料等。

在最高層測試計劃中，如果存在下述文件，則需要引用它們：項目計劃、質量保證計劃、有關的政策、有關的標準等。

5.1.3測試項（本計劃的第3章）

描述被測試的對象，包括其版本、修訂級別，並指出在測試開始之前對邏輯或物理變換的要求。

5.1.4被測試的特性（本計劃的第4章）

指明所有要被測試的軟體特性及其組合，指明每個特性或特性組合有關的測試設計說明。

5.1.5不被測試的特性（本計劃的第5章）

指出不被測試的所有特性和特性的有意義的組合及其理由。

5.1.6方法（本計劃的第6章）

描述測試的總體方法，規定測試指定特性組志需的主要活動、、技術和工具，應詳盡地描述方法，以便列出主要的測試任務，並估計執行各項任務所需的時間。規定所希望的電低程度的測試徹底性，指明用於判斷測試徹底性的技術（如：檢查哪些語句至少執行過一次）。指出對測試的主要限制，例如：測試項可用性、測試資源的可用性和測試截止期限等。

5.1.7項通過準則（本計劃的第7章）

規定各測試項通過測試的標準。

5.1.8暫停標準和再啟動要求（本計劃第8章）

規定用於暫停全部或部分與本計劃有關的測試項的測試活動的標準。規定當測試再啟動時必須重複的測試活動。

5.1.9應提供的測試文件（本計劃的第9章）

規定測試完成後所應遞交的文件，這些文件可以是前述八個文件的全部或者部分。

5.1.10測試任務（本計劃的第10章）

指明執行測試所需的任務集合，指出任務音的一切依賴關係和所需的一切特殊技能。

5.1.11環境要求（本計劃的第11章）

規定測試環境所必備的和希望的的性質。包括：硬體、通信和系統軟體的物理特徵、使用方式以及任何其它支撐測試所需的軟體或設備，指出所需的特殊測試工具及其它測試要求（如出版物或辦公場地等）。指出測試組目前還不能得到的所有要求的來源。

5.1.12職責（本計劃的第12章）

指出負責管理、設計、準備、執行、監督、檢查和仲裁的小組。另外指出負責提供

5.1.3 中指出的測試項和在5.1.11中指出的環境要求的小組。

這些小組可以包括開發人員、測試人員、操作員、用戶代表、數據管理員和質量保證人員。

5.1.13人員和訓練要求（本計劃的第13章）

指明測試人員應有的水平以及為掌握必要技能可供選擇的訓練科目。

5.1.14進度（本計劃的第14章）

包括在軟體項目進度中規定的測試里程碑以及所有測試項傳遞時間。

定義所需的新的測試里程碑，估計完成每項測試任務所需的時間，為每項測試任務和測試里程碑規定進度，對每項測試資源規定使用期限。

5.1.15風險和應急（本計劃的第15章）

預測測試計劃中的風險，規定對各種風險的應急措施（如：延期傳遞的測試項可能需要加夜班來趕上規定的進度。）

5.1.16批准（本計劃的第16章）

規定本計劃必須由哪些人（姓名和職務）審批。為簽名和填寫日期留出位置。

5.2 測試設計說明

測試設計說明如下圖所示。

1測試設計說明名稱

2被測試的特性

3方法詳述

4測試用例名稱

5特性通過準則

下面給出本說明每一章的詳細內容。

5.2.1測試設計說明名稱（本說明第1章）

給每一個測試設計說明取一個專用名稱。如果存在的話，也可引用有關的測試計劃中給出的名稱。

5.2.2被測試的特性（本說明的第2章）

規定測試項，描述作為本設計測試目標的特性和特性的組合，其它特性可以論及，但不必測試。

5.2.3方法詳述（本說明的第3章）

將測試計劃中規定的方法進行細化，包括要用的具體測試技術，規定分析測試結果的方法（如比較程序或人工觀察）。

規定為選擇測試用例提供合理依據的一切分析結果。例如：可以說明容錯的條例（如：區別有效輸入和無效輸入的條件）。

歸納所有測試用例的共同屬性，可以包括輸入約束條件，共享環境的要求，對共享的特殊規程的要求及任何共享的測試用例間的依賴關係。

5.2.4測試例名稱（本說明的第4章）

列出與本設計有關的每一測試用例的名稱和簡要說明。某個特定的測試用例可能在多個測試設計說明中出現，列出與本測試設計說明有關的規程及其簡要說明。

5.2.5特性通過準則（本說明的第5章）

規定用於判別特性和特性組合是否通過測試的准。

5.3 測試用例說明

測試用例說明結構如下圖所示。

1測試用例說明名稱

2測試項

3輸入說明

4輸出說明

5環境要求

6特殊的規程說明

7用例間的依賴關係

由於測試用例可能被由多個小組長期使用的多個測試設計說明引用，所以在測試用例說明中必須包含足夠具體的信息以便重複使用。

下面給出本說明每一章的詳細內容。

5.3.1測試用例說明名稱（本說明的第1章）

給本測試用例說明取一個專用名稱

5.3.2測試項（本說明的第2章）

規定並簡要說明本測試用例所要涉及的項和特性、對於每一項、可考慮引用以下文件：需求說明書、設計說明書、用戶手冊、操作手冊。

5.3.3輸入說明（本說明的第3章）

規定執行測試用例所需的各個輸入。有些輸入可以用值（允許適當的誤差）來規定。而另一些輸入，如常數表或事務文件可以用名來規定。規定所有合適的資料庫、文件、終端信息、內存常駐區域和由作業系統傳送的值。規定各輸入間所需的所有關係（如時序關係等）。

5.3.4輸出說明（本說明的第4章）

規定測試項的所有輸出和特性（如：響應時間）。提供各個輸出或特性的正確值（在適當的誤差範圍內）。

5.3.5環境要求（本說明的第5章）

5.3.5.1硬體

規定執行本測試用例所需的硬體特徵和配置（如：80字符×24行的顯示終端）。

5.3.5.2軟體

規定執行本測試用例所需的系統軟體和應用軟體。系統軟體可以包括作業系統、編譯程序、模擬程序和測試工具等。

5.3.5.3其它

說明所有其它的要求，如特種設施要求或經過專門訓練的人員等。

5.3.6特殊的規程要求（本說明的第6章）

描述對執行本測試用例的測試規程的一切特殊限制。這些限制可以包括特定的準備、操作人員干預、確定特殊的輸出和清除過程。

5.3.7用例間的依賴關係（本說明的第7章）

列出必須在本測試用例之前執行的測試用例名稱，歸納依賴性質。

5.4 測試規程說明

測試規程說明結構如下圖表示

1測試規程說明名稱

2目的

3特殊要求

4規程步驟

5.4.1測試規程說明名稱（本說明的第1章）

給每個測試規程說明取一個專用名稱，給出對有關測試設計說明的引用。

5.4.2目的（本說明的第2章）

描述本規程的目的。如果本規程執行測試用例，則引用各有關的測試用例說明。

5.4.3特殊要求（本說明的第3章）

指出執行本規程所需的所有特殊要求，包括作為先決條件的規程、專門技能要求和特殊環境要求。

5.4.4規程步驟（本說明的第4章）

5.4.4.1日誌

說明用來記錄測試的執行結果、觀察到的事件和其它與測試有關事件（見5.6條測試日誌和5.7條測試事件報告）的所有特殊方法或格式。

5.4.4.2準備

描述新任務執行規程所必需的動作序列。

5.4.4.3啟動

描述開始執行規程所必需的動作。

5.4.4.4處理

描述在規程執行過程中所必需的動作。

5.4.4.5度量

描述如何進行測試度量（如描述如何用網絡模擬程序來充其量遠程終端的響應時間）。

5.4.4.6暫停

描述因發生意外事件暫停測試所必需的動作。

5.4.4.7再啟動

規定所有再撥動點和在啟動點上重新啟動規程所必需的動作。

5.4.4.8停止

描述正常停止執行時所必需的動作。

5.4.4.9清除

描述恢復環境所必需的動作。

5.4.4.10應急

描述處理執行過程中可能發生的異常事件所必需的動作。

5.5 測試項傳遞報告

測試項傳遞報告結構如下圖所示。

1傳遞報告名稱

2傳遞項

3位置

4狀態

5批准

下面給出本報告每一章的詳細內容。

5.5.1傳遞報告名稱（本報告的第1章）

為本測試項傳遞報告取一個專用名稱。

5.5.2傳遞項（本報告的第2章）

規定被傳遞的項及其版本/修訂級別。提供與傳遞項有關的項文件和測試計劃的相關信息，指出對該傳遞項負責的人員。

5.5.3位置（本報告的第3章）

規定傳遞項的位置及其所在媒體。

5.5.4狀態（本報告的第4章）

描述被傳遞的測試項的狀態，包括其與項文件、這些項的以往傳遞以及測試計劃的差別。列出希望由被傳遞項解決的事件報告。

5.5.5批准（本報告的第5章）

規定本傳遞報告必須由哪些人（姓名和職務）審批，並為簽名和日期留出位置。

5.6 測試日誌

測試日誌結構如下圖所示。

1測試日誌名稱

2描述

3活動和事件條目

下面給出本報告每一章的詳細內容。

5.6.1測試日誌名稱（本日誌的第1章）

為本測試日誌取一專用的名稱。

5.6.2描述（本日誌的第2章）

除了在日誌條目中特別註明的以外，用於日誌中所有條目的信息都包括在本章中。應該考慮有以下信息：

（1）規定被測試項及其版本/修訂級別。如果存在的話，引用各項的傳遞報告。

（2）規定完成測試的環境屬性，包括設備說明、所用的硬體、所用的系統軟體及可用存儲容量等可用資源。

5.6.3活動和事件條目（本日誌的第3章）

對每個事件（包括事件的開始和結束），記錄發生的日期和時間，並說明記錄者。應考慮以下各項信息。

5.6.3.1執行描述

記錄所執行的測試規程的名稱，並引用該測試規程說明。記錄執行時在場人員，包括：測試者、操作員和觀察員，還要說明每個人的作用。

5.6.3.2測試結果

對每次執行，記錄人工可觀察到的結果（如：產生的錯誤信息、異常中止和對操作員動作的請求等），還要記錄所有輸出的位置（如磁帶號碼），記錄測試的執行是否成功。

5.6.3.3環境信息

記錄本條目的的一切特殊的環境條件。

5.6.3.4意外事件

記錄意外事件及其發生前後的情況（如請求顯示總計，屏幕顯示正常，但響應時間似乎異常長，重複執行時響應時間也同樣過長）。記錄無法開始執行測試或無法結束測試的周圍環境（如電源故障或系統軟體問題）。

5.6.3.5事件報告名稱

每產生一個測試事件報告時，記錄其名稱。

5.7 測試事件報告

測試事件報告結構如下圖所示。

1測試事件報告名稱

2摘要

3事件描述

4影響

5.7.1測試事件報告名稱（本報告的第1章）

為本測試事件報告取一個專用名稱。

5.7.2摘要（本報告的第2章）

簡述事件，指出有關測試項及其版本/修訂級別。引用有關的測試規程說明、測試用例說明及測試日誌。

5.7.3事件描述（本報告的第3章）

對事件進行描述。該描述應包括以下各項：

輸入

預期結果

實際結果

異常現象

日期和時間

規程步驟

環境

重複執行的意圖

測試者

觀察者

該描述應該包括有助於確定事件發生原因及改正其中錯誤的有關浩劫及觀察。例如，描述可能對此事件有影響的所有測試用例執行情況，描述與已公布的測試規程之間的一切差異等。

5.7.4影響（本報告的第4章）

在所知道的範圍內指出本事件對測試計劃、測試設計說明、測試規程說明或測試用例說明所產生的影響。

5.8測試總結報告

規定本報告必須由哪些人（姓名和職務）審批，並為簽名和日期留出位置。

單元測試報告

編者說明：

單元測試是每一個開發人員都必須去做的事，它將採用白盒方法來進行，為了跟蹤單元測試的效果，對開發人員進行督促，對於一些重要的模塊進行測試是很必要的。該表格就是用來讓開發人員填寫單元測試的結果的文檔。

開發項目名稱

開發項目編號

第一責任人

單元名稱

責任人

單元所屬子系統

開發周期

代碼測試檢查：

代碼測試內容

測試人員

測試結果

備註

路徑測試

聲明測試

循環測試

邊界測試

接口測試

界面測試

數據確認測試

代碼走查

功能測試：

序號

功能名稱

操作方法

結果

建議

測試人員

備註

測試結論

責任人

項目第一責任人

審核

項目組

測試組

總工辦

總工程師

五、其它類模塊開發說明(ISO標準)

編程說明：

該文檔將與模塊開發卷宗結合使用，卷宗是對整個系統進行整理，而模塊開發說明則是對具體的模塊進行說明，其作用于歸檔階段。

1．標題

[系統名稱和標識符]

[模塊名稱和標識符]

[程序編制員簽名]

[卷宗的修改文本序號]

[修改完成日期]

[卷宗序號]

[編排日期]

2．模塊開發情況表

3．功能說明

[扼要說明本模塊的功能主要是輸入、要求的處理、輸出。可以從系統設計說明書中摘錄。同時列出在需求說明書中對這些功能的說明的章、條、款。]

4．設計說明

[說明本模塊的設計考慮]

5．硬體部分的設計結果

1） 經項目組調試通過的硬體成品1件

2）設計文件：

《原理圖》

《PCB圖》

《BOM清單》

《可編程器件及燒錄進位文件》

《必要測試點波形圖或硬體指標評細說明》

《原理詳細說明》

《與系統內其他部分接口軟硬體詳細說明》

這些文件可以附件的形式列後。

6．軟體的設計結果

[要給出所產生的本模塊的第一份無語法錯的原始碼清單以及已通過全部測試的當前有效的源程序代碼。]

7．測試說明

[說明直接要經過本模塊的每一項測試，包括這些測試各自的標識符和編號、進行這些測試的目的、所用的配置和輸入、預期的輸出及實際的輸出。]

8．覆審的結論

[把實際測試的結果，同需求說明書、系統設計說明書中規定的要求進行比較和給出結論。]

用戶手冊概要(GB標準)

編者說明：

為用戶提供一個使用手冊，是提升軟體可用性的必要措施。用戶手冊的作用是讓用戶對整個軟體系統有一個宏觀的認識。解決安裝問題，告知運行環境，介紹主要功能等。

1 引言

1.1 編寫目的

[說明編寫這份用戶手冊的目的，指出預期的讀者。]

1.2背景

[說明：]

[a. 這份用戶手冊所描述的軟體系統的名稱；]

[b. 該軟體項目的任務提出者、開發者、用戶（或首批用戶）及安裝此軟體的計算中心。]

1.3 定義

1.4 參考資料

[列出有用的參考資料，如：]

a. 項目的經核准的計劃任務書或合同、上級機關的批文；

b. 屬於本項目的其他已發表文件；

c. 本文件中各處引用的文件、資料，包括所要用到的軟體開發標準。

[列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠取得這些文件資料的來源。]

2 用途

2.1 功能

[結合本軟體的開發目的逐項地說明本軟體所具有各項功能以及它們的極限範圍。]

2.2 性能

2.2.1 精度

[逐項說明對各項輸入數據的精度要求和本軟體輸出數據達到的精度，包括傳輸中的精度要求。]

2.2.2 時間特性

[定量地說明本軟體的時間特性，如響應時間，更新處理時間，數據傳輸、轉換時間，計算時間等。]

2.2.3靈活性

[說明本軟體所具有的靈活性，即當用戶需求（如對操作方式、運行環境、結果精度、時間特性等的要求）有某些變化時，本軟體的適應能力。]

2.3 安全保密

[說明本軟體在安全、保密方面的設計考慮和實際達到的能力。]

3 運行環境

3.1 硬設備

[列出為運行本軟體所要求的硬設備的最小配置，如：]

a. 處理機的型號、內存容量;

b. 所要求的外存儲器、媒體、記錄格式、設備的型號和台數、聯機／脫機；

c. I／O設備（聯機／脫機？）；

d. 數據傳輸設備和轉換設備的型號、台數。

3.2 支持軟體

[說明為運行本軟體所需要的支持軟體，如：]

a. 作業系統的名稱、版本號；

b. 程序語言的編譯／彙編系統的名稱和版本號；

c. 資料庫管理系統的名稱和版本號；

d. 其他支持軟體。

3.3 數據結構

[列出為支持本軟體的運行所需要的資料庫或數據文件。]

4 使用過程

[在本章，首先用圖表的形式說明軟體的功能同系統的輸入源機構、輸出接收機構之間的關係。]

4.1 安裝與初始化

[一步一步地說明為使用本軟體而需進行的安裝與初始化過程，包括程序的存儲形式、安裝與初始化過程中的全部操作命令、系統對這些命令的反應與答覆。表徵安裝工作完成的測試實例等。如果有的話，還應說明安裝過程中所需用到的專用軟體。]

4.2 輸入

[規定輸入數據和參量的準備要求。]

4.2.1 輸入數據的現實背景

[說明輸入數據的現實背景，主要是：]

a. 情況--例如人員變動、庫存'缺貨；

b. 情況出現的頻度--例如是周期性的、隨機的、一項操作狀態的函數.

c. 情況來源-一例如人事部門、倉庫管理部門；

d. 輸入媒體---例如鍵盤、穿孔卡片、磁帶；

e. 限制--出於安全、保密考慮而對訪問這些輸入數據所加的限制；

f. 質量管理--例如對輸入數據合理性的檢驗以及當輸入數據有錯誤時應採取的措施，如建立出錯情況的記錄等；

g. 支配--例如如何確定輸入數據是保留還是廢棄，是否要分配給其他的接受者等。

4.2.2 輸入格式

[說明對初始輸入數據和參量的格式要求，包括語法規則和有關約定，如：]

a. 長度-一例如字符數／行，字符數／項；

b. 格式基準--例如以左面的邊沿為基準；

c. 標號--例如標記或標識符；

d. 順序--例如各個數據項的次序及位置；

e. 標點--例如用來表示行、數據組等的開始或結束而使用的空格、斜線、星號、字符組等。

f. 詞彙表--給出允許使用的字符組合的列表，禁止使用＊的字符組合的列表等；

g. 省略和重複--給出用來表示輸人元素可省略或重複的表示方式；

h. 控制--給出用來表示輸入開始或結束的控制信息。

4.2.3 輸入舉例

[為每個完整的輸入形式提供樣本，包括：]

a. 控制或首部--例如用來表示輸入的種類和類型的信息，標識符輸入日期，正文起點和對所用編碼的規定；

b. 主體--輸入數據的主體，包括數據文件的輸入表述部分；

c. 尾部--用來表示輸入結束的控制信息，累計字符總數等；

d. 省略--指出哪些輸入數據是可省略的；

e. 重複--指出哪些輸入數據是重複的。

4.3 輸出

[對每項輸出作出說明.]

4.3.1輸出數據的現實背景，

[說明輸出數據的現實背景，主要是：]

a. 使用--這些輸出數據是給誰的，用來幹什麼；

b. 使用頻度--例如每周的、定期的或備查閱的；

c. 媒體--列印、CRI顯示、磁帶、卡片、磁碟，

d. 質量管理-一例如關於合理性檢驗、出錯糾正的規定；

e. 支配--例如如何確定輸出數據是保留還是廢棄，是否分配給其他接受者等。

4.3.2 輸出格式

[給出對每一類輸出信息的解釋，主要是：]

a. 首部--如輸出數據的標識符，輸出日期和輸出編號；

b. 主體--輸出信息的主體，包括分欄標題；

c. 尾部--包括累計總數，結束標記。

4.3.3 輸出舉例

[為每種輸出類型提供例子。對例子中的每一項，說明：]

a. 定義--每項輸出信息的意義和用途；

b. 來源--是從特定的輸入中抽出、從資料庫文件中取出、或從軟體的計算過程中得到；

c. 特性--輸出的值域、計量單位、在什麼情況下可預設等。

4.4 文件查詢

[這一條的編寫針對具有查詢能力的軟體，內容包括：同資料庫查詢有關的初始化、準備、及處理所需要的詳細規定，說明查詢的能力、方式，所使用的命令和所要求的控制規定。]

4.5 出錯處理和恢復

[列出由軟體產生的出錯編碼或條件以及應由用戶承擔的修改糾正工作。指出為了確保再啟動和恢復的能力，用戶必須遵循的處理過程。]

4.6 終端操作

[當軟體是在多終端系統上工作時，應編寫本條，以說明終端的配置安排、連接步驟、數據和參數輸入步驟以及控制規定說明。通過終端操作進行查詢、檢索、修改數據文件的能力、語言、過程以及輔助性程序等。]

操作手冊 (GB標準)

編者說明：

操作手冊也是一個很常見的針對用戶的文檔，其幫助用戶更好地操作軟體，使用軟體。

1 引言

1.1 編寫目的

[說明編寫這份操作手冊的目的，指出預期的讀者。]

1.2 前景

[說明： ]

a.這份操作手冊所描述的軟體系統的名稱；

b.該軟體項目的任務提出者、開發者、用戶及安裝該軟體的計算中心。

1.3 定義

1.4 參考資料

a. 本項目的經核准的計劃任務書或合同、上級機關的批文；

b. 屬於本項目的其他已發表的文件；

c. 本文件中各處引用的文件、資料；

[包括所列出的這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。 ]

2 軟體征述

2.1 軟體的結構

[結合軟體系統所具有的功能包括輸入、處理和輸出提供該軟體的總體結構圖表。 ]

2.2 程序表

[列出本系統內每個程序的標識符、編號和助記名。]

2.3 文件表

[列出將由本系統引用、建立或更新的每個永久性文件，說明它們各自的標識符、編號、助記名、存儲媒體和存儲要求。 ]

3 安裝與初始化

[一步一步地說明為使用本軟體而需要進行的安裝與初始化過程，包括程序的存載形式，安裝與初始化過程中的全部操作命令，系統對這些命令的反應與答覆，表徵安裝工作完成的測試實例等。如果有的話，還應說明安裝過程中所需用到的專用軟體。 ]

4 運行說明

[所謂一個運行是指提供一個啟動控制信息後，直到計算機系統等待另一個啟動控制信息時為止的計算機系統執行的全部過程。]

4.1 運行表

[列出每種可能的運行，摘要說明每個運行的目的，指出各自所執行的程序。 ]

4.2 運行步驟

[說明從一個運行轉向另一個運行以完成整個系統運行的步驟。 ]

4.3 運行1（標識符）說明

[把運行1的有關信息，以對操作人員為最方便最有用的形式加以說明。]

4.3.1 運行控制

[列出為本運行所需要"的運行流向控制的說明。]

4.3.2 操作信息

[給出為操作中心的操作人員和管理人員所需要的信息，如：]

a. 運行目的；

b. 操作要求；

c. 啟動方法如應請啟動（由所遇到的請求信息啟動）、預定時間啟動、…·等；

d. 預計的運行時間和解題時間；操作命令；

f. 與運行有聯繫的其他事項。

4.3.3 輸入一輸出文件

[提供被本運行建立、更新或訪問的數據文件的有關信息，如：]

a. 文件的標識符或標號；

b. 記錄媒體；

c. 存留的目錄表；

d. 文件的支配如確定保留或廢棄的準則、是否要分配給其他接受者、占用硬設備的優先級以及保密控制等有關規定。

4.3.4 輸出文件

提供本軟體輸出的每一一個用於提示、說明、或應答的文段（包括"菜單"）的有關信息，如：

a. 文段的標識符；

b. 輸出媒體（屏幕顯示、列印、……）；

c. 文字容量；

d. 分發對象；

e. 保密要求。

4.3.5 輸出文段的複製

[對由計算機產生，而後需用其他方法複製的那些文段提供有關信息，如：]

a. 文段的標識符；

b. 複製的技術手段；

c. 紙張或其他媒體的規格；

d. 裝訂要求；

e. 分發對象；

f. 複製份數。

4.3.6 恢復過程

[說明本運行故障後的恢復過程。]

4.4 運行2（標識符）說明

[用與本手冊1.4.3條相類似的方式介紹另一個運行的有關信息。]

5 非常規過程

[提供有關應急操作或非常規操作的必要信息，如出錯處理操作、向後備系統的切換操作以及其他必須向程序維護人員交待的事項和步驟。]

6 遠程操作

[如果本軟體能夠通過遠程終端控制運行，則在本章說明通過遠程終端運行本軟體的操作過程。]

軟體維護需求表

編者說明：

軟體維護工作是一個持續的過程，該表格用於在客戶服務部門與開發部門之間的聯繫。它將維護的要求詳細地提供給開發部門，以幫助他們更好地有針對性地安排維護工作。

維護需求的編制者：

申請者：

模塊/程序名：

完成人員：

緊急程度：緊急 高 中 低

維護案例的標誌：

維護活動的標誌：

估計成本：

維護工作開始時間：

預計維護工作結束時間：

累計成本：

接收/拒收：

完成的維護工作：

日期/簽名：

軟體問題報告表

編者說明：

軟體維護通常從問題報告開始，上門維護的人員有義務將問題進行整理，以便於開發人員找到原因，提供解決方案。

軟體問題報告登記號：登記日期：時間：階段：狀 態： 1 2 3 4 5 6 7報告人資料姓 名 電 話 地 址 問題： 程 序 資料庫 文 檔 問題描述/影響： 簽名： 日期：軟體開發部意見： 簽名： 日期：附註：

軟體問題解決記錄表

編者說明：

該表格用於上門維護人員，記錄其發現問題之後的解決過程，將其備案對於維護工作有很重要的價值。

軟體問題報告號：
軟體維護人：	維護時間：
軟體解決過程： 簽名： 日期：
軟體用戶意見： 簽名： 日期：
軟體開發部意見： 簽名： 日期：
備註： 簽名： 日期：

軟體維護報告表

編者說明：

該表格用於開發部門對軟體所做出的維護性修改，將其記錄在案，是十分必要的，防止文檔的不一致性帶來的維護麻煩。

維護案例的標誌：

維護活動的標誌：

維護需求的類型：改正 改編 調整 擴充

所有維護過的模塊和系統的結果及成本/工作： 對所做維護工作的注釋： 維護人簽名： 日期：

系統方案書模板

編者說明：

現在許多系統都需要進行招標，所以投標用的技術方案是開發團隊經常編寫的，本文檔則從許多優秀的系統方案書中總結出一個基礎的框架，相信對於大家很有幫助。

1.前言

1.1 項目簡介

[在本小節對該項目的基本情況做一簡單的介紹。]

1.2 背景分析

[在本小節應列舉一些與該項目相關的背景資料以及相關的分析，可以包括國際、國內的動向，當地應用的基本情況，客戶群體背景等方面的內容。]

1.3 建設目標

[對該項目的建設目標做出一個概要性的描述，以幫助讀者能夠很快地抓住主題，對項目的意義與遠景有一個共識。]

1.4 系統設計原則

[說明該方案中的設計方案的設計原則，通常包括先進性、安全性、實用性、經濟性，或者是諸如什麼統一規劃、統一協調之類的大方向。]

1.5 遵循的標準與規範

[如果業主方有需求，或者你的設計方案是符合某個國際標準、國家標準、行業標準的話，應該在本小節中列出這些規範，並且說明你在設計方案中是如何滿足這些規範的，這樣做將帶來什麼樣的好處。]

2.系統遠期規劃

[如果你所做的系統將是一個長期性大項目的第一期，或者是其中的一期，那麼你應該從整個系統的遠期規劃著手，描述該項目的長遠目標和遠景。然後從中導出你所做的這一期的建設規劃，從而使業主明白你的設計方案與長遠規劃的一致性。]

3.項目建設計劃

[在本節中，你應該對本期建設的組織結構、實施進度計劃等方面的內容進行闡述，這樣讓業心明白你需要多少時間來完成本期項目。]

4.需求分析

[該部分內容主要來源於招標文件，你可以在招標文件提出的系統需求的基礎上，進行擴展性描述，也可以對其進行合理的重新組織，使得其更加的規格化。然後對其需求進行分析，為系統總體設計打下鋪墊。]

5.系統總體設計

[這是系統設計方案中的最重要的一部分，通過該部分的描繪，你將為業主構建一個良好的框架，讓其對你的設計思路有一個總體上的了解。]

4.1 系統架構

[在該小節中，你應該給出一個系統總體結構圖，這個圖是一個讓用戶直觀地獲得整個系統結構的示意圖。然後對該圖進行一些必要的補充說明，幫助讀者更好地理解總體結構。同時你應該結構系統總體結構圖對各個子系統的功能以及它們之間的關係進行描述。如果需要的話，還可以分小節進行描述。]

4.2 技術說明

[在該小節中，你可以對選用的主要技術進行必要的解釋和說明，幫助讀者了解這些技術的特點，以及其優勢和採用的原因。]

4.3 系統的設計相關考慮

[在該小節中，你可以對總體設計是考慮到的一些非功能因素進行描述，例如安全性、兼容性、對原有資源的利用等。]

5.主機系統設計方案

[如果在你所設計的系統中有使用到主機，那麼就應專僻一個章節來說明。這部分的內容主要是主機的選型，主機的詳細技術參數，你的選擇考慮、理由，也就是要達到說服業主採用你的選型方案。你可以從主機系統的產品技術白皮書上獲取這些資料，並且從性價比，使用情況等方面進行深入的描述。]

[如果需要，也可以提供多種不同的方案建議，並充分說明這些選擇的優劣點，供業主根據實際的需要進行選擇。]

[通常情況下，主機的性能、功能要求在招標書中會列出，因此你在描述的時候應該結合這些內容進行針對性的說明。]

6.軟體系統設計方案

[如果項目中包括計算機軟體應用系統的開發，則你應該專門單列出個章節進行描述。在這裡，你應該列出軟體系統的總體設計，各個子系統之間的關係，每個系統的設計考慮，以及將採用什麼作業系統、資料庫、中間件、開發工具，並且說明理由。]

[對於你所選擇的作業系統、資料庫、中間件、開發工具應該列舉出詳細的技術資料，你可以從相關的產品白皮書中獲得這些資料，並結合它們的優勢在該項目中應用的好處的角度多做一些闡述。]

[通常本章節中應該包括軟體系統總體設計，各個子系統的說明等小節。]

7.具體應用系統設計

[如果項目中包括一些如視頻會議系統、郵件系統、WEB系統等，則應該單獨地進行描述，可以根據其規模決定是都放在一個章節還是多個章節。主要內容就是產品選型，技術說明、推薦理由等。]

8.網絡架構方案

[如果系統中有計算機網絡部分，則應專門列出章節進行描述。在本章節中應該包括網絡架構的拓撲結構設計圖。並對其進行說明。]

[另外，還應該對於網絡中的各種設備，如路由器、交換機等提供相應的設計的選型、產品技術參數、推薦理由，分析的依據等內容。]

[如果涉及到綜合布線，則應該分一小節進行描述。]

9.系統的安全性與擴展性

[對於一些系統安全性、擴展性等項目十分關注的非功能因素，應該單獨地放置在一個章節內進行統一描述。主要包括採用的技術、措施，能夠達到的效果，以及與系統的綜合考慮。]

10.技術培訓與支持

[最後，還應該對項目的技術培訓與售後技術服務進行說明。]

10.1 項目培訓

[通常包括培訓目標、培訓人員、培訓內容、培訓方式等內容。]

10.2 售後服務

[通常包括應用軟體維護、現場維護、巡檢維護、備件管理、安裝規範以及售後服務響應體系的介紹。]

軟體過程規範示例

編者說明：

軟體過程管理中的一個很重要的工作就是制定項目、組織的過程規範，它是軟體開發組織行動的準則與指南。該文檔就是一個實際的過程規範的實例，通過該實例，相信對大家根據自身情況制定符合要求的項目過程規範、組織過程規範有很好的借鑑作用。

1.總則

最大限度提高Q&P（質量與生產率），提高Q&P的可預見性，是每一個軟體開發機構的最大目標。而Q&P依賴於三個因素：過程、人和技術，因此要實現Q&P的提高，除了加強技術能力，引進、培育更多優質技術人才之外，規範、改進機構的過程是一個十分重要的手段。我們希望通過在制定軟體過程規範標準，並在軟體開發實踐中不斷地完善、修訂，提高Q&P和Q&P的可預見性。

本規範採用CMM（軟體過程成熟度模型）的指導，吸收RUP、XP、MSF、PSP、TSP等過程規範指南的思想、方法及實踐，充分結合xxx技術開發部的實際情況，引入先進的技術、方法、工具，為公司的軟體開發工作提供一部詳細、可操作的過程指南。在本規範的第一版本中，主要包括管理過程和開發過程兩個部分，管理過程中包括項目管理過程、需求變更管理過程、配置管理過程。對於軟體開發項目中的其它的一些過程將在實踐中逐步補充、完善。

2.項目管理過程規範

項目管理過程主要包括三個階段：項目立項與計劃、項目實施、項目關閉。

2.1 項目立項與計劃

參與人員：技術開發部指定的項目負責人（包括前期負責人、正式的項目經理）、立項申請人、[相關最終客戶]以及實施該項目的開發組隊成員；

入口準則：接到經公司總經理或副總經理批准的市場部門的《軟體開發立項申請表》；

出口準則：立項申請人簽字確認了經修訂正後的正式《軟體項目計劃》，並通過《工作任務卡》下達了開發任務，開發工作正式開始；

輸入：經審批的《軟體開發立項申請表》、與需求相關的業務資料；

輸出：《軟體項目計劃》、《軟體需求規格說明書》、《開發任務卡》；

活動：

1. 接到《軟體開發立項申請表》後，技術開發部經理指定前期負責人，並告知立項申請人；

2. 前期負責人閱讀《軟體開發立項申請表》後，通過與立項申請人的溝通、閱讀立項申請人提交的材料、通過立項申請人與客戶直接交流等方式，了解項目目標、範圍與基本需求；並形成最初的《軟體需求規格說明書》；

3. 前期負責人會同技術開發部經理以及其它相關人員，制定最初的《軟體項目計劃》，並組織評審；

4. 向立項申請人提交最初的《軟體項目計劃》；

5. 最初的《軟體項目計劃》通過立項申請人的確認後，項目經理計劃安排需求分析；

6. 需求分析完成後，形成正式的《軟體需求說明書》，提交立項申請人確認；（需求分析過程參見開發過程規範部分）

7. 根據立項申請人確認後的《軟體需求說明書》，項目經理組織進行軟體高層設計，並對工作任務進行分解，並根據實際需要向技術開發部經理申請資源，組建項目組隊；

8. 項目經理根據工作任務分解，下發《工作任務卡》，並協同組隊成員進行任務估算；

註：工作任務包括模塊開發任務、其它任務（如安裝）；模塊開發任務主要包括：詳細設計、編碼和單元測試

9. 任務估算完成後，組隊成員向項目經理提交《個人進度安排》（以甘特圖的形式表示），項目經理根據每個組隊成員的《個人進度安排》修訂《軟體項目計劃》（必須包括總的計劃甘特圖），並提交立項申請人確認；

10. 立項申請人確定後，項目經理根據軟體項目計劃基線，補充《工作任務卡》，下發到每個組隊成員，開發工作開始。

項目立項與計劃過程的工作流程如下圖所示：

圖表1 項目立項與計劃工作流程圖

相關模板：

《軟體需求規格說明書》、《軟體項目計劃》、《工作任務卡》

說明：如果計劃確認、需求確認未通過，立項申請人與項目經理進行協商，進行修正，無法達成共識的，提交部門經理、總經理協調；

2.2 項目實施

參與人員：項目經理，項目組成員；

入口準則：項目計劃基線已建立，並通過立項申請人確定，帶有工作進度要求的《工作任務卡》已下發到每個項目成員；

出口準則：立項申請人在《驗收報告》上簽字確認；

輸入：《軟體需求規格說明書》、《軟體項目計劃》、《工作任務卡》；

輸出：經驗收測試的可交付的程序、原始碼及相關文檔。

活動：

1、 在開發期間，項目成員每周需上交一份《時間日誌》、《缺陷日誌》，每天向項目經理匯報工作任務進度；

2、 在開發期間，項目經理負責填寫《項目進度周報》報於技術開發部經理、立項申請人（格式不同，交予立項申請人的只需周報的第一頁，報予技術開發部經理的項目進度周報的第二頁為「跟蹤甘特圖」）；

3、 項目經理必須根據實際的進度情況，及時調整項目計劃，若發現進度延誤，需採取措施。

相關模板：

《軟體項目計劃》、《開發任務卡》、《時間日誌》、《缺陷日誌》、《項目進度周報》

2.3 項目關閉

參與人員：技術開發部經理或經理助理、項目經理，項目組成員、立項申請人、[相關客戶、公司總經理、公司副總經理]；

入口準則：立項申請人在《驗收報告》上確認；

出口準則：形成《項目總結》，完成項目績效考核，項目數據存入「過程資料庫」；

輸入：《時間日誌》、《缺陷日誌》、《項目開發計劃》；

輸出：《項目總結》、已完成的《項目績效考核表》、過程資料庫中的該項目記錄；

活動：

1、 項目經理主持召開項目總結會，交流項目實施過程中的心得體會，對項目實施中的成功處、不足處進行總結，並由項目經理形成《項目總結》；

2、 由技術開發部經理組織對該項目進行績效考核，並填寫相應的《項目績效考核表》；

3、 項目經理組織所有成員對項目過程中的文檔、源程序等資料進行整理、歸檔；

4、 由項目經理根據過程資料庫的需要，整理相應的數據，提交技術開發部經理，存入過程資料庫。

相關模板：

《項目總結》、《項目績效考核表》

3.開發過程規範

開發過程是提煉用戶需求，設計、構建和測試滿足這些需求的軟體並最終將其交付給客戶的過程。是軟體過程中的主體過程之一。當開發新的應用或計劃為現有的應用進行重要的增強時，需使用本規範所定義的開發過程執行。

項目管理過程是對開發過程進行計劃、監控/管理、總結的輔助過程，但由於項目管理是保證進度、質量的重要手段，因此在軟體項目中也是十分重要的過程之一。而需求管理過程與配置管理過程則是次重要的輔助過程，需求管理過程是一個需求變更管理的過程，以對變更進行統一的管理；配置管理過程的最重要工作就是版本控制，使得開發過程中的各種交付物能夠有機地形成一個個整體。

因此以上四個過程是交織進行的，均是為成功完成軟體項目的保障過程。

3.1 過程總述

現在比較通行的開發過程模型包括：瀑布模型、演化模型、原型模型、螺旋模型等。根據公司的項目特點、隊伍規模、組隊情況等實際因素，決定選擇最為簡單、易於掌握的瀑布模型為基礎，根據公司特點，進行合理的修改，使其成為公司本階段的軟體開發過程。

正如下圖所示，本規範將整個開發過程分為：需求分析、高層設計、詳細設計、編碼和單元測試、集成計劃與測試、系統測試、驗收測試與安裝、維護等八個階段。

圖表2 開發過程總圖

註：SRS：軟體需求規格 HLD：高層設計 DD：詳細設計

SRC：代碼 UT Plan：單元測試計劃

註：「歸檔」在配置管理過程統一說明。

3.2 需求分析階段

需求分析的主要目的是生成一個正確說明客戶所有需求的文檔。換言之，軟體需求規格（Software Requirement Specification，SRS）文檔是該階段的主要輸出。正確的需求分析和確定需求規格對一個項目的成功是非常關鍵的。許多在系統和驗收測試時發現的缺陷是在需求階段產生的。在驗收階段去掉需求階段產生的一個錯誤將比在需求階段本身去掉該錯誤要多花100多倍的費用。很明顯，在執行這階段時，正確地生成具有最少缺陷的SRS是非常必要的。

參與人員：項目經理，[分析員]，立項申請人，[客戶，最終用戶]；

入口準則：項目立項，最初的項目計劃已得到立項申請人的確認。

註：這裡所說明的需求分析階段是進行開發過程的需求分析階段，在技術開發部出具初步的項目計劃之前的需求溝通工作，不是該過程規範所定義的。最初的需求溝通工作可以參考本過程規範。

出口準則：立項申請人、[客戶]在《軟體需求規格說明書》上簽字確認；

輸入：《項目立項申請表》、最初的《項目計劃》，需求相關的資料；

輸出：經確認的《軟體需求規格說明書》；

活動：

整個需求分析過程主要包括以下幾個步驟：

圖表3 需求分析階段活動總圖

1、 首先，項目經理與分析員一塊，做好需求分析的準備，包括閱讀相關的背景資料，熟悉客戶的實際情況，準備用戶訪談計劃，準備會談問題清單等；

2、 然後通過面談、專題討論會等形式與客戶進行溝通，採集需求的詳細內容，澄清每一個需求點；從而界定出系統的目標和範圍；

3、 對所採集和澄清的需求進行分析，構建需求模型，從功能性、非功能性兩個方面進行需求分析，深入領會客戶需求；

4、 形成《軟體需求規格說明書》，建立軟體需求基線，並為軟體需求評審做好準備；

5、 由項目經理安排軟體需求評審，協同立項申請人、[客戶]進行需求評審；

6、 立項申請人[或客戶]在《軟體需求規格說明書》上確認。

相關模板：

《軟體需求規格說明書》

3.3 高層設計階段

高層設計是軟體開發過程中的一個重要階段，在這個階段將從計算機實現的邏輯角度開發針對用戶需求的解決方案。這一解決方案是一個高級的抽象方案。高層設計要設計出各主要部分，並說明他們在技術上如何工作：1）相互間的協作；2）所需外在的硬體和軟體環境；3）內在環境。也就是說，高層設計確定了組成產品的構件，定義了每個構件的功能任務，並且定義了構件間的接口及構件到運行環境的外部接口。

參與人員：項目經理，項目組員（設計團隊）；

入口準則：《軟體需求規格說明書》已通過立項申請人的確認；

出口準則：形成高層設計，實現任務分解，所有的問題得到解決；

輸入：《軟體需求說明書》

輸出：《高層設計說明書》（功能與資料庫設計）、詳細設計、編碼、文檔和用戶接口標準；

活動：

1、 制定詳細設計、編碼、文檔和用戶接口的標準；

2、 根據項目特點選擇運行的目標平台和開發工具；

3、 制定軟體的體系結構，定義邏輯和物理的對象模型，包括確定類、類的屬性、類方法、類之間的關係和對象間的動態交互。若採用結構化設計，則該活動應為功能設計；

4、 從需求規格說明書中的數據模型中得到物理資料庫結構，進行物理資料庫設計：包括確定表/記錄類型、域和其他部分。

5、 生成高層設計說明書，並組織設計評審。

相關模板：

《高層設計說明書》

3.4 詳細設計階段

在詳細設計階段，高層設計階段開發出的整體應用被分成幾個模塊（或構件）和程序。為每個程序（或構件）進行邏輯設計，然後歸檔作為程序規格，同時為每個程序（或構件）生成一個單元測試計劃。詳細設計階段的重要活動包括通用例程和程序的確定、框架程序的開發以及用於提高生產率的實用程序和工具的開發。

在詳細設計階段負責每個程序、模塊（或構件）的內部設計，確定其程序流程，並且可以通過使用設計語言、圖形流程圖（如活動圖、狀態圖）等，或通過簡單地寫敘述而將設計文檔化。

參與人員：每個模塊（或構件）的任務承擔人；

入口準則：《高層設計說明書》已通過評審；

出口準則：完成詳細設計，所有的問題得到解決，詳細設計與單元測試計劃文檔化；

輸入：《軟體需求規格說明書》、《高層設計說明書》、詳細設計標準

輸出：《詳細設計說明書》、《單元測試計劃》

活動：

1、 將高層設計中的每個程序（或構件）細分成小的組件；

2、 對每個小組件進行詳細設計，包括確定調用方法、輸入和輸出、程序邏輯、數據結構等；

3、 根據組件的邏輯，制定單元測試計劃，包括確定單元測試環境、測試用例、測試數據等；

4、 向項目經理（或高層設計者）提交詳細設計與單元測試計劃；

相關模板：

《詳細設計說明書》、《單元測試計劃》

剪裁說明：對一些小項目，詳細設計階段的活動1、2可以省略。

3.5 編碼和單元測試

在編碼子階段，根據詳細設計用程式語言編寫所需的程序。這個階段根據合適的編碼規範產生原始碼、可執行代碼以及資料庫（如果使用了資料庫）。這個階段的輸出是隨後測試和驗證的主體。而單元測試子階段則是根據詳細設計階段所制定出來的單元測試計劃進行測試，驗證每一個組件正確、可用。

參與人員：每個模塊（或構件）的任務承擔人；

入口準則：《詳細設計說明書》已通過批准，編碼規範已建立；

出口準則：成功執行所有單元測試計劃中的測試用例；

輸入：《軟體需求規格說明書》、《高層設計說明書》、《詳細設計說明書》、《單元測試計劃》編碼、用戶接口標準；

輸出：測試數據、原始碼、可執行代碼、《單元測試報告》

活動：

1、 根據詳細設計，按照編碼、用戶接口規範編寫程序；

2、 對程序進行代碼複查、編譯、調試，直到程序運行通過，符合詳細設計的要求；

3、 根據單元測試計劃進行單元測試，生成單元測試報告。

相關模板：

《單元測試報告》

3.6 集成計劃與測試

集成是把設計階段制定的，已通過單元測試的模塊構建成一個完整軟體結構的系統方法。可採用很多方式進行集成，集成計劃必須指定模塊集成的順序。在該階段，同時進行測試，以發現與接口相關的缺陷。集成按照集成計劃中制定的順序進行，並執行每個集成階段的相應測試用例。集成計劃描述了集成順序、額外需要的軟體、測試環境和資源需求。集成計劃與集成測試計劃通常一起完成。

參與人員：項目經理，集成團隊；

入口準則：經批准的《高層設計說明書》；

出口準則：集成計劃和集成測試計劃經過評審和授權；

輸入：《高層設計說明書》、源程序

輸出：《集成計劃》、《集成測試計劃》

活動：

1、 確定集成所需的環境，包括硬體的物理特性、通信和系統軟體、使用模式等；

2、 決定集成規程，確定將要集成的關鍵模塊，集成的順序，需要測試的接口等；

3、 開發集成測試計劃，確定測試用例和執行用例的規程，確定測試數據，確定期望輸出等。

相關模板：

《集成計劃》、《集成測試計劃》

剪裁說明：對一些小項目，集成計劃與測試階段可以省略。

3.7 系統測試

系統測試是依據需求規格驗證軟體產品有效性的活動。這個階段是為了發現那些只有通過測試整個系統才能暴露的缺陷。就像外部接口、性能、安全、配置敏感性、共存、恢復以及可靠性等屬性只有在這個階段才能判斷其是否有效。可以使用具有不同測試目的的一系列測試來驗證所有系統元素都已經正確地集成，系統能夠執行所有功能並滿足所有非功能需求。系統測試開始之前，必須在系統測試計劃階段詳細地制定計劃。

系統測試計劃工作從需求分析結束後就可以開始，一直到編碼時結束。

參與人員：項目經理，系統測試團隊；

入口準則：經確認的《軟體需求規格說明書》和經批准的《高層設計說明書》；

出口準則：系統測試計劃經過評審和授權，成功執行所有系統測試計劃中的測試用例；；

輸入：《軟體需求規格說明書》、《高層設計說明書》

輸出：《系統測試計劃》、《系統測試報告》

活動：

1、 決定所需的測試環境；

2、 決定系統測試的規程，包括：確定測試特性，如用戶接口、軟硬體接口、通信接口、主要業務過程；確定不需要測試的重要特性以及不測試的原因；確定關鍵測試；

3、 開發測試用例，包括確定每個測試用例以及執行它的規程，確定每個輸入、輸出數據的要求，確定預期的結果。

相關模板：

《系統測試計劃》、《系統測試報告》

剪裁說明：對一些小項目，系統測試階段可以省略，直接準備驗收測試，在驗收測試之前，開發組隊按驗收測試計劃做一次沒有立項申請人、[客戶]參加的預測試。

3.8 驗收測試與安裝

驗收測試和安裝階段的主要任務是將軟體產品集成到它的操作環境中，並在這個環境中經受測試，以確保它按需求執行。這個階段包括兩個基本任務：使軟體得以驗收和客戶處安裝軟體。驗收指的是由立項申請人、[客戶]根據早期準備的《驗收報告》而進行正式的測試，並對測試結果進行分析，以確定系統是否滿足驗收準則。當分析結果滿足驗收測試時，用戶接受軟體。安裝指的是把接受的軟體置於實際產品環境中。

註：《驗收報告》應附有驗收測試計劃

參與人員：項目經理，安裝團隊、立項申請人、[客戶]；

入口準則：成功地完成了系統測試（或成功地完成了驗收預測試）；

出口準則：立項申請人或客戶在《驗收報告》上簽署確認意見；

輸入：《軟體需求說明書》、測試後的軟體和《驗收報告》

輸出：簽署了確認意見的《驗收報告》和安裝後的軟體；

活動：

1、 根據《軟體需求說明書》，編寫驗收報告；

2、 與立項申請人、[客戶]一起按《驗收報告》執行驗收測試，包括：在驗收環境下安裝軟體、進行實況運行、協助客戶進行驗收測試、改正驗收缺陷、更新文檔以反映所有變更、獲得客戶的驗收確認；

3、 執行安裝，包括：在產品環境下安裝軟體、搭建產品環境、載入軟體和數據、進行實況運行、修改安裝缺陷、執行用戶培訓。

相關模板：

《驗收報告》

3.9 維護

維護支持階段是指已安裝的應用得到支持，直至其在生產環境中穩定運行的階段。

參與人員：項目經理，系統安裝人員；

入口準則：軟體在生產中運行；

出口準則：合同中指定的維護支持階段終止；

輸入：安裝後的應用、用戶文檔和《軟體維護申請表》；

4.需求變更管理過程規範

需求變更，這是個永恆的真理。需求變更的一個重要原因是系統周圍的世界在變化，從而要求系統適應這個變化。在項目生命周期的任何時候或者項目結束之後都可以有需求變更。與其希望變更不會來臨，不如希望初始的需求在某種程度上做得很好而使得沒有變更需求，最好是項目準備時想到對付這些變更，以防變更真的到來。不管做多少準備和計劃都不可能阻止變更，說項目在需求凍結後再開始不過是個神話罷了。

4.1 過程總述

需求變更管理過程定義了一系列活動，當有新的需求或對現有需求進行變更（我們可以稱它們都是需求變更）時就會執行這些活動。需求變更可以在項目執行的任何一個點上發生。需求變更會影響項目進度，甚至會影響已經生產出來的產品。越是在生命周期後期的需求變更，對項目的影響越嚴重。不可控的需求變更導致對成本、進度以及項目質量的負面影響，這些極可能嚴重危害項目成功的概念。

需求變更管理過程用來控制需求變更並減少他們對項目的影響。這個目標需要理解需求變更請求的隱含意義，以及變更帶來的總影響。同樣，也需要立項申請人、[客戶]意識到變更對項目影響的後果，使得可以友好地將變更反映到協商好的條款中。需求變更管理過程，從某種程序上說，試圖保證在需求變更影響下項目依然可以成功。

需求變更管理有兩個方面，一方面與立項申請人、[客戶]就怎樣處理變更達成一致，一方面是實際進行變更的過程。處理變更的整體方法必須與立項申請人、[客戶]達成一致。一般來說，它制定怎樣進行變更請求，當需要正式的批准時，為處理變更估計留出冗餘空間等等。在整個方法的背景下，當需求變更到來時，需要執行需求變更管理過程。

4.2 過程規範

參與人員：項目經理，立項申請人、[客戶]、開發團隊；

註：項目經理對將變更納入項目中所需的過程執行負主要責任。立項申請人、[客戶]以及開發隊伍也需要參與這個過程。

入口準則：收到立項申請人提交的《需求變更請求單》

出口準則：變更已列入新的《軟體需求說明書》，並體現在新的《軟體項目計劃中》；

輸入：《需求變更請求單》

輸出：根據《需求變更請求單》，在充分協商與的基礎上，提交新的《軟體需求說明書》，並提交《軟體項目計劃變更表》；

活動：

1、 記錄需求變更請求，記錄項中應包括變更請求數、變更的簡要描述、變更的影響、變更請求的狀態和關鍵數據；

2、 分析變更請求對工作的影響；

3、 估計變更請求需要的工作量；

4、 修改項目計劃，重新估計交付時間；

5、 對總的成本花費的影響進行估計；

6、 將修改過的項目計劃提交立項申請人，並獲得確認。

相關模板：

《項目計劃變更表》

5. 配置管理過程規範

軟體項目在其執行過程會產生大量的工件，包括各種文檔、程序、數據和手冊。所有這些工件都是易於改變的。這是軟體一個獨有的特點。正如「需求變更管理」章節中所述，在軟體項目中，在項目執行過程中的任何時候，需求本身都會發生變更。為避免項目在變更時失控，正確控制和管理變更是很必要的。配置管理（Configuration Management，CM）又稱為軟體配置管理，是項目管理中專用於關注系統地控制項目進行中發生的變更的那些部分，由用來識別機構軟體產品並控制其修改的一系統活動構成。

配置管理需要滿足項目基本目標之一：為客戶提交高質量的軟體產品。這個提交的產品，包括各種資源以及構成資源或目標代碼的目標文件，還包括以這些文件來構建工作系統的腳本以及相關文檔。在項目中，資源和文檔通常以很多獨立文件的方式來維護。

當項目進展時，文件發生了改變，產生了不同的版本。在種情況下，即使將項目的各部分組合起來，構建成系統，也是很困難的任務，怎樣保證合併的是源程序的正確版本以及沒有遺漏任何源程序？還有，怎樣保證傳送的文檔的版本是正確的，該版本和最終交付的軟體是一致？對於這類型的情況，必須正確跟蹤軟體開發過程中的各種中間產品、其版本以及軟體產品的版本。沒有這些信息，交付最終系統就成為繁重的任務。這個活動不是由開發過程完成的，而需要一個獨立的過程，那就是配置管理過程。

5.1 配置管理的目標

配置管理過程，需要達到以下目標：

1） 能夠隨時給出程序的最新版本；

2） 能夠處理並發的文檔、程序的更新/修改請求；

3） 能夠根據需要撤消程序的修改；

4） 能夠有效防止未授權的程式設計師對文檔、程序進行變更或刪除；

5） 能夠有效地顯示變更的情況。

5.2 配置管理過程規範

配置管理過程包括兩個主要階段：配置管理計劃、實施配置管理。

5.2.1 配置管理計劃

參與人員：項目經理，配置管理團隊；

入口準則：《軟體需求規格說明書》已經確認；

出口準則：完成項目配置管理計劃；

輸入：《軟體需求規格說明書》

輸出：《配置管理計劃》

活動：

1、 識別配置項，配置項的典型例子包括需求規格、設計文檔、原始碼、測試計劃、測試腳本、測試規程、測試數據、項目使用的編碼、用戶接口規範、驗收報告等；

2、 定義為配置項命名和編號的計劃：如果使用CM工具，那麼有時由工具處理版本編號，否則，在項目中必須明確地進行版本編號；

3、 定義CM所需的目錄結構；

4、 定義訪問控制；

5、 定義變更控制規程；

6、 確定CM工作人員的責任和權利；

7、 定義跟蹤配置項狀態的方法；

8、 定義備份制度

9、 定義發布制度；

10、 確定將配置項轉移到基線的原則。

相關模板：

《軟體配置管理計劃》

5.2.2 實施配置管理

參與人員：項目經理，配置管理團隊、開發項目組隊成員；

入口準則：《軟體配置管理計劃》已批准，項目開始；

出口準則：項目結束；

輸入：《軟體配置管理計劃》

活動：

1、 接受變更請求；

2、 Check out需要變更、修改的配置項，並進行修改；

3、 Check in變更、修改過的配置項。

6. 附件

附件包括各種文檔模板與工作指南。所有附件以單獨的文檔形式存儲，文檔名為xxxx模板、xxxx工作指南。具體包括：

6.1 文檔模板

6.1.1 項目管理類

《軟體項目計劃模板》、《工作任務卡模板》、《時間日誌模板》、《缺陷日誌模板》、《項目進度周報模板》、《項目總結模板》、《項目績效考核表模板》、《項目計劃變更表模板》、《軟體配置管理計劃》

6.1.2 開發過程類

《軟體需求規格說明書模板》、《高層設計說明書模板》、《詳細設計說明書模板》、《單元測試計劃模板》、《單元測試報告模板》、《集成計劃模板》、《集成測試計劃模板》、《集成測試報告模板》、《系統測試計劃模板》、《系統測試報告模板》、《驗收測試報告模板》。

6.2 工作指南

《軟體需求分析工作指南》、《軟體項目計劃工作指南》、《軟體需求管理工作指南》、《軟體配置管理工作指南》

網站定量評估的度量指標

度量指標	描述	獲得方法	評估注意事項
點擊數	訪問伺服器上某個文件的請求	日誌文件	目前該指標的有效性大大降低，因為一個頁面可能偽造成多個點擊。
頁面訪問次數	訪問伺服器上一個HTML頁面的請求	日誌文件	注意主機、代理伺服器和緩存可能會誤報頁面訪問次數
唯一用戶數	有不同IP地址或Cookie的用戶	日誌文件/資料庫分析	動態分配IP會導致統一數大於實際數，而代理伺服器會導致統一數小於實際數
用戶會話數	與網站連接的時間超過30分鐘而且沒有中斷的對話	日誌文件	可以在網絡伺服器上設定超時時間，默認設置為30分中。然而通過修改這個設置，使採集的結果產生偏差
用戶會話	平均的用戶會話長度	日誌文件	由於多個用戶共享一台計算機或由於使用代理伺服器上網，因此很難判斷一個用戶產生了會話，期間他離開了，而由另一個用戶接替這個會話
訪問網站的頂級路徑	當用戶訪問網站時，大多數人訪問頁面的順序	日誌文件	如果使用框架的話，可能會到「無人訪問的結果」
進入和離開頁面	大多數用戶進入或離開網站的頁面	日誌文件	有助於了解用戶是否從外部的連結進入網站，或從一個標籤頁進入，而非從網站主要進入
與其它網站互相連結的點擊數	常常用來測量廣告鏈條的情況	日誌文件(廣告伺服器)	用來評測一個廣告條的吸引力，不能用來評測品牌的知名度或連結的效果
涉及網站	聯繫最緊密的網站	日誌文件	用來了解網站最主要的流量從哪裡來
繁忙時間段	網站網絡伺服器使用率最高的時刻	日誌文件	用於計劃網站升級和對網絡進行維護、管理的依據
客戶/服務錯誤類別	客戶或伺服器產生錯誤的詳細情況	日誌文件	很多錯誤不一定是真正的錯誤
用戶瀏覽器和作業系統	用戶使用瀏覽器及作業系統的類型和版本	日誌文件	用來了解設計的技術規格和實際情況間的差距，可以對未來的規劃提供依據
用戶地域分布	地域分布統計	日誌文件	基於國家域名後綴的統計不是很可靠
網站響應時間	頁面下載時間和數據搜索時間	性能監控軟體	是一個很好的基準，網站隨著流量的增加，可以了解其性能變化
伺服器正常運行時間	網站可用時間的百分比	性能監控軟體	應該儘量使這個指標接近100%，對於那些以廣告為主要業務的網站更重要
註冊用戶數	帶有用戶個人詳細信息的註冊用戶總數	資料庫	要求用戶使用時需註冊和登錄，操作更麻煩
個性化應用	專家報告功能	資料庫分析	包括分析購買趨勢、銷售轉化率、用戶生活方式等。