目 錄
1. 引言 1
1.1. 背景 1
1.2. 參考資料 1
1.3. 假定和約束 1
1.4. 使用者的特點 1
2. 功能需求 1
2.1. 系統範圍 1
2.2. 系統體系結構（二層架構的系統可剪裁本小節） 1
2.3. 系統總體流程 2
2.4. 需求分析 2
2.4.1. ******x(功能需求名稱) 2
2.4.1.1. 功能描述 2
2.4.1.2. 業務建模 2
2.4.1.3. 用例描述 3
2.4.1.4. 使用者介面 5
2.4.2. ******x(功能需求名稱) 5
3. 非功能需求 5
3.1. 效能要求 5
3.1.1. 精度 5
3.1.2. 時間特性要求 6
3.1.3. 輸人輸出要求 6
3.2. 資料管理能力要求 6
3.3. 安全保密性要求 6
3.4. 靈活性要求 6
3.5. 其他專門要求 6
4. 執行環境規定 6
4.1. 裝置 6
4.2. 支援軟體 7
4.3. 介面 7
4.4. 控制 7
5. 需求跟蹤 7
6. 簽批單 7
1. 引言
1.1. 背景
說明：
a．待開發的軟體系統的名稱；
b．本專案的任務提出者、開發者、使用者及實現該軟體的計算中心或計算機網路；
c．該軟體系統同其他系統或其他機構的基本的相互來往關係。
1.2. 參考資料
列出本說明書中引用和參考的資料，如：
a．本專案的經核准的計畫任務書或合同、上級機關的批文；
b．屬於本專案的其他已發表的檔案；
c．本檔案中各處引用的檔案、資料、包括所要用到的軟體開發標準。 列出這些檔案資料的標題、檔案編號、發表日期和出版單位，說明能夠得到這些檔案資料的**。
1.3. 假定和約束[可選]
列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限、裝置條件、使用者的資料準備和交流上的問題等。
1.4. 使用者的特點[可選]
列出本軟體的終端使用者的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使用頻度。這些是軟體設計工作的重要約束。
2. 功能需求
2.1. 系統範圍
明確概要地說明使用者對系統、產品高層次的目標要求，如系統開發的意圖、應用目標、作用範圍以及其他相關的背景材料。
如果所定義的產品是乙個更大系統的乙個組成部分，則應說明本產品與該系統中其他各組成部分之間的關係，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯絡和介面。
2.2. 系統體系結構（二層架構的系統可剪裁本小節）[可選]
以圖+文字結合的方式描述系統的總體架構。
以下應提供系統總體架構圖：
以下對系統總體架構進行描述：
2.3. 系統總體流程
以圖+文字結合的方式說明系統的總體流程。
圖一是計畫合同管理系統的總體流程圖。
圖一2.4. 需求分析
需求分析的目的是獲取或描述系統需求中的每乙個功能需求，並通過分析確定系統能夠做什麼？誰來使用這個系統？
· 建立用例模型：發現角色和用例，並確定角色之間的關係、用例之間的關係，以及角色與用例之間的相互關係
· 描述用例：角色與系統如何互動的規格說明。
2.4.1. ******x(功能需求名稱)
2.4.1.1. 功能描述
功能編號：
功能需求：從使用者業務的角度描述功能需求。
2.4.1.2. 業務建模
從視覺化的角度--用例圖--描述功能需求
圖二是綜合計畫管理系統合同編輯業務的功能需求用例圖。
圖二2.4.1.3. 用例描述
以文字的方式描述每乙個用例中角色與系統相互互動的規格說明。
1、 ******(用例名稱)
描述物件 描述內容
識別符號 用例的唯一識別符號
說明 對用例的概要說明
參與者 與該用例相關的參與者列表，以及參與者的特點
頻度 參與者訪問此用例的頻率
狀態 通常分為：進行中、等待審查、通過審查或未通過審查
前置條件 乙個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足
後置條件 乙個條件列表，如果其中包含條件，則這些條件將在用例成功完成以後得到滿足
被擴充套件的用例 此用例所擴充套件的用例（如果存在）
被包含的用例 此用例所包含的用例（如果存在）
基本操作流程 參與者在用例中所遵循的主邏輯路徑，即當各項工作都正常進行時用例的工作方式
可選操作流程 在變更工作方式、出現異常或發生錯誤的情況下所遵循的路徑
修改歷史記錄 修改人 ： 修改日期：修改原因：
問題 如果存在，則為與此用例的開發相關的問題或操作專案的列表
以下是綜合計畫管理系統中的合同編輯功能需求中的合同增加用例描述：
描述物件 描述內容
識別符號 ipms0101
說明 增加一條合同記錄
參與者 合同編輯人員--熟悉合同管理業務
頻度 狀態 通過審查
前置條件 1. 參與者具有合同增加的許可權2. 參與者已選取對應的計畫記錄3. 當前計畫總投資≥sum(該計畫下已簽合同價)
後置條件 1. 資料庫中更加一條合同紀律2. 可執行合同原件掃瞄用例3. 可執行合同付款增加用例4. 可執行合同修改和合同刪除用例
被擴充套件的用例 無
被包含的用例 無
基本操作流程 請參見圖三的合同增加流程
可選操作流程 當使用者確認合同增加時發現異常時，系統提示合同增加無效的提示
修改歷史記錄 修改人 ： 修改日期：修改原因：
問題 1. 合同編碼的具體約定2. 合同型別、資金**、合同受委託方字典表的具體設計
圖三 合同增加活動流程
2、***xx(用例名稱)
……2.4.1.4. 使用者介面
概要描述功能對應的使用者介面風格，採用原型生命週期的專案也可以提供原型介面拷貝。
2.4.2. ******x(功能需求名稱)
……3. 非功能需求
3.1. 效能要求
3.1.1. 精度[可選]
說明對該軟體的輸入、輸出資料精度的要求，可能包括傳輸過程中的精度。
3.1.2. 時間特性要求
說明對於該軟體的時間特性要求，如對：響應時間；更新處理時間；資料的轉換和介面更新傳送時間等的要求。
3.1.3. 輸人輸出要求
解釋各輸入輸出資料型別，並逐項說明其**、格式、數值範圍、精度等。對軟體的資料輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。
3.2. 資料管理能力要求[可選]
說明需要管理的文捲和記錄的個數、表和文捲的大小規模，要按可預見的增長對資料及其分量的儲存要求做出估算。
3.3. 安全保密性要求
使用者對系統所應具備的故障處理能力、處理方式及故障後的系統恢復、資料恢復等要求，對系統防止機密資料被非法侵入、修改及丟失的要求。
3.4. 靈活性要求[可選]
說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：
a．操作方式上的變化；
b．執行環境的變化；
c．同其他軟體的介面的變化；
d．精度和有效時限的變化；
e．計畫的變化或改進。
對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。
3.5. 其他專門要求[可選]
如使用者單位對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、異常處理要求、執行環境可轉換性的特殊要求等。
4. 執行環境規定
4.1. 裝置
列出執行該軟體所需要的硬裝置。說明其中的新型裝置及其專門功能，包括：
a．處理器型號及記憶體容量；
b．外存容量、聯機或離線、**及其儲存格式，裝置的型號及數量；
c．輸入及輸出裝置的型號和數量，聯機或離線；
d．資料通訊裝置的型號和數量；
e．功能鍵及其他專用硬體
4.2. 支援軟體
列出支援軟體,包括網路和硬體裝置平台、作業系統平台、資料庫系統平台以及編譯（或彙編）程式和測試支援軟體等。
4.3. 介面[可選]
說明該軟體同其他軟體之間的介面、資料通訊協議等。
4.4. 控制[可選]
說明控制該軟體的執行的方法和控制訊號，並說明這些控制訊號的**。
5. 需求跟蹤
需求跟蹤的主要目的是保證所有的需求都得到分析，以承諾需求-分析需求對應表（prs_srs表）的方式描述已分析需求對已承諾需求的覆蓋情況。prs_srs表的格式請參見軟體需求管理過程規範（supl-manu-srs-001）。
6. 簽批單
我已閱讀上述軟體需求規格說明書，我將嚴格遵守說明書中的條款，並保證全力支援該規格說明書的實施。
執行主管:
日期技術主管:
日期專案組長:
日期使用者代表:
日期開發人員代表:
日期小組成員:
日期小組成員:
日期
需求分析的文件模板的書寫方式
軟體需求分析是軟體定義階段的最後一步，是確定系統做哪些工作，也就是對系統提出完整，準確，清晰，具體的要求。軟體需求分析的任務是 深入描述軟體的功能和效能，確定軟體設計的約束和軟體痛其它系統元素的介面細節，定義軟體的其它有效性需求。解決目標系統 做什麼 的問題。軟體需求分析可分為需求提出，需求描述以及...
需求分析模板
軟體工程 2010 02 25 16 23 24 閱讀1510 字型大小 大 中小 軟體客戶需求權利書 1.要求分析人員使用符合客戶語言習慣的表達 2.要求分析人員了解客戶系統的業務及目標 3.要求分析人員組織需求獲取期間所介紹的資訊，並編寫軟體需求規格說明。4.要求開發人員對產品的實現及需求都要提...
需求分析模板
目 錄 1.引言 1 1.1.背景 1 1.2.參考資料 1 1.3.假定和約束 1 1.4.使用者的特點 1 2.功能需求 1 2.1.系統範圍 1 2.2.系統體系結構 二層架構的系統可剪裁本小節 1 2.3.系統總體流程 2 2.4.需求分析 2 2.4.1.x 功能需求名稱 2 2.4.1....