《專案名稱》
需求分析說明書
版本 <1.0>
[注：用方括號括起來並以藍色斜體（樣式=infoblue）顯示的文字，它們用於向作者提供指導，在發布此文件之前應該將其刪除。按此樣式輸入的段落將被自動設定為普通樣式（樣式=body text）。
][本文中《專案名稱》、《公司名稱》為自動更新字段。更新操作步驟如下：
開啟選單「檔案」-「屬性」
將主題中的《專案名稱》修改為具體的專案名稱
將單位中的《公司名稱》修改為具體的公司名稱
ctrl+a，選中全文，按f9替換。
對頁首與頁尾中的文字，先開啟檢視-頁首與頁尾選單欄，ctrl+a選中，按f9替換。]
修訂歷史記錄
目錄1. 簡介 4
1.1 目的 4
1.2 背景 4
1.3 定義、首字母縮寫詞和縮略語 4
1.4 參考資料 4
2. 任務概述 4
3. 功能需求 5
3.1 《功能需求一》 5
3.1.1 功能要求 5
3.1.2 資料流程圖 5
3.1.3 資料字典 5
3.1.4 許可權劃分 5
3.2 《功能需求二》 5
4. 效能需求 5
4.1 資料管理能力要求 5
4.1.1 《時間特性需求》 5
4.1.2 《吞吐量需求》 6
4.1.3 《容量需求》 6
4.1.4 《資源利用情況》 6
4.2 靈活性 6
4.3 其他專門要求 6
5. 介面 6
5.1.1 使用者介面 6
5.1.2 硬體介面 6
5.1.3 軟體介面 7
5.1.4 通訊介面 7
6. 執行環境規定 7
6.1.1 裝置 7
6.1.2 支援軟體 7
6.1.3 開發環境 7
需求分析說明書
為提高衛生行政管理部門和醫院在護理管理方面的決策科學性，改變以往手工報表方式，運用資訊科技和網路通訊技術，實現全市醫院護理管理資料整合利用，建立一種區域網路環境下的醫院護理管理模式。
長期以來，醫院護理管理是一種粗放型的管理，管理層次低，智慧型化水平低，且多處於簡單的手工操作階段，需要耗大量的人力、物力。各個醫院在處理護理工作數質量指標等資料時，嚴重依賴紙介質，每年資料彙總時，需要攜帶大量的紙質報表報送給衛生廳，而衛生廳的處理也以來於手工處理，效率不高，同時也極易產生錯誤。
隨著網路資訊科技在醫院管理與醫療、護理領域的應用，這為開展全市醫院護理統一的管理帶來了生機。依照國家相關衛生資訊標準，將醫院護理人員檔案、護理質量管理、護理日常管理、護理報表管理等納入於計算機管理並通過網路聯機資訊共享，為醫院管理者、衛生行政主管部門及時獲取資訊，掌握醫療機構護理動態情況，在行業內統一規範化管理提供一種先進手段，建立一種區域網路環境下的醫院護理管理模式，提高管理效率和效益。
[本小節應提供正確理解此 srs 所需的全部術語的定義、首字母縮寫詞和縮略語。這些資訊可以通過引用專案詞彙表來提供。]
[本小節應完整列出此 srs 中其他部分所引用的任何文件。包括：本專案的經核准的計畫任務書或合同、上級機關的批文；屬於本專案的其他已發表的檔案；本檔案中各處引用的檔案、資料、包括所要用到的軟體開發標準。
每個文件應標有標題、報告號（如果適用）、日期和出版單位。列出可從中獲取這些參考資料的**。這些資訊可以通過引用附錄或其他文件來提供。]
[srs 的這一節應說明影響產品及其需求的一般因素。本節並不列出具體的需求，而只是提供在第 3 節中詳述的各種需求的背景，以使這些需求便於理解。所包括的內容有：]
目標[敘述該項軟體開發的意圖、應用目標、作用範圍以及其他應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其他有關軟體之間的關係。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。
如果所定義的產品是乙個更大的系統的乙個組成部分，則應說明本產品與該系統中其他各組成部分之間的關係，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯絡和介面。]
使用者特徵
[列出本軟體的終端使用者的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使用頻度。這些是軟體設計工作的重要約束。]
假設與約束
[列出進行本軟體開發工作的假定約束，例如經費限制、開發期限等。]
[srs 的這一節應包含所有的軟體需求，其詳細程度應使設計人員能夠設計出可以滿足這些需求的系統，並使測試人員能夠測試該系統是否滿足這些需求。此節以自然語言風格表達需求說明。對於許多應用程式，此節會成為 srs 包的主體部分，所以應仔細考慮此節的組織方式。
此節通常按特性來組織，但也可能會有其他適用的組織方式，例如按使用者或子系統組織的方式。功能性需求可能包括特性集、效能和安全性。]
[需求的背景，應用場合，操作人員特徵]
[詳細的功能特徵描述。]
[本功能涉及到的一級或多級資料流程圖。說明輸入什麼量，經怎樣的處理，得到什麼輸出]
[資料的含義，及型別、取值範圍、精度、格式等約束]
[說明該功能所涉及到的操作人員的許可權]
[需求的背景，應用場合，操作人員特徵]
[詳細的功能特徵描述。]
[本功能涉及到的一級或多級資料流程圖。說明輸入什麼量，經怎樣的處理，得到什麼輸出]
[資料的含義，及型別、取值範圍、精度、格式等約束]
[說明該功能所涉及到的操作人員的許可權]
[需求的背景，應用場合，操作人員特徵]
[詳細的功能特徵描述。]
[本功能涉及到的一級或多級資料流程圖。說明輸入什麼量，經怎樣的處理，得到什麼輸出]
[資料的含義，及型別、取值範圍、精度、格式等約束]
[說明該功能所涉及到的操作人員的許可權]
[需求的背景，應用場合，操作人員特徵]
[詳細的功能特徵描述。]
[本功能涉及到的一級或多級資料流程圖。說明輸入什麼量，經怎樣的處理，得到什麼輸出]
[資料的含義，及型別、取值範圍、精度、格式等約束]
[說明該功能所涉及到的操作人員的許可權]
[說明該軟體的時間特性要求、吞吐量、容量、資源利用情況等要求]
[說明該軟體的時間特性要求，如對：響應時間、更新處理時間、資料的轉換和傳送時間、解題時間等的要求]
[說明吞吐量，例如每秒處理的事務數]
[說明系統容量，例如系統可以容納的客戶或事務數]
[說明資源利用情況，如記憶體、磁碟、通訊等，要按可預見的增長對資料及其分量的儲存要求作出估算]
[說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：
操作方式上的變化；
執行環境的變化；
同其他軟體的介面的變化；
精度和有效時限的變化；
計畫的變化或改進]
[說明特殊要求，如使用者單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、執行環境可轉換性的特殊要求等。]
[此節規定應用程式必須支援的介面/介面。它應非常具體，包含協議、埠和邏輯位址等，以便於按照介面/介面需求開發並檢驗軟體。]
[說明軟體將實現的使用者介面。]
[此節指出軟體所支援的所有硬體介面，其中包括邏輯結構、實體地址、預期行為等。]
[此節說明軟體系統中與其他構件之間的軟體介面。這些構件可以是購入的構件、取自其他應用程式重新利用的構件，也可以是為此 srs 範圍之外的子系統開發，但該軟體應用程式必須與之互動的構件。]
[說明與其他系統或裝置（如區域網、遠端序列裝置等）的所有通訊介面。]
[此節應列出執行該系統所需要的軟體、硬體環境]
[列出執行該軟體所需要的硬裝置。說明其中的新型裝置及其專門功能]
[列出支援軟體，包括要用到的作業系統、編譯（或彙編）程式、測試軟體等]
[列出開發語言、開發工具、資料庫工具等]
需求規格說明書編寫規範
待建設的系統名稱，原有系統描述,原有系統存在的問題，新系統解決方案描述。可根據專案 合同或規範內容進行概況或引用，說明本次系統整合專案的設計目標。這一部分概述了正在定義的產品以及它所執行的環境 使用產品的使用者和已知的限制 假設和依賴。可以引用 合同 規範 把簡單的使用者需求描述成產品需求，並分析技...
測試分析報告編寫規範 原版
專案名稱 測試分析報告 作者完成日期 簽收人簽收日期 修改情況記錄 目錄1 引言 1 1.1 編寫目的 1 1.2 背景 1 1.3 定義 1 1.4 參考資料 1 2 測試概要 1 3 測試結果及發現 1 3.1 測試1 識別符號 1 3.2 測試2 識別符號 1 4 對軟體功能的結論 2 4.1...
可行性分析報告編寫規範
目錄1.目的 2.適用範圍 3.術語及縮略語 4.編寫規範 4.1 排版規範 4.2 模板使用 5.引用檔案 5.1 nw602101 檔案編寫導則 6.附錄 可行性分析報告的編寫目的是說明實現該軟體專案或軟體產品在技術 經濟和社會條件方面的可行性 評述為了達到開發目標而可能選擇的各種方案 說明並論...