專案編號：
專案名稱：
密級：文件編號：
版本資訊： v1.0
建立人：
建立日期：
審核者：
批准人：
批准日期：
編輯軟體：microsoft word 2003中文版
檔案狀態： √草稿
正式發布
正在修改
北京天大天科科技發展****
版權所有
文件修訂記錄
*變化狀態：a——增加，m——修改，d——刪除
文件審批資訊
主要內容
1 引言 4
1.1 編寫目的 4
1.2 背景範圍 4
1.3 術語定義 4
1.4 參考資料 4
1.5 讀者範圍 4
2 調研情況介紹 4
3 需求範圍 4
4 總體需求 4
4.1 系統組成 4
4.2 系統的邏輯崗位及職責 5
4.3 系統業務流程 5
5 功能需求 5
5.1 功能清單 5
5.2 功能規範 5
5.2.1 功能綜合說明 5
5.2.2 功能詳細定義 5
6 系統介面描述 6
6.1 使用者介面 6
6.2 硬體介面 6
6.3 軟體介面 6
6.4 通訊介面 6
7 非功能需求 6
7.1 效能需求 6
7.2 安全性要求 7
7.3 對軟硬體環境的要求 7
7.4 其它需求 7
8 附錄1 7
8.1 原型 7
8.2 採用建模工具所形成的模型檔案 7
8.3 調研相關資料和檔案 7
8.4 同類產品簡介 7
8.5 需求分析過程中制定的相關規範或模板 7
9 附錄2：需求確認表 8
說明：編寫這份需求規格說明書的目的。
說明：a. 待開發的軟體系統的名稱；
b. 本專案的任務提出者、開發者、使用者及實現該軟體的計算中心或計算機網路；
c. 該軟體系統同其他系統或其他機構的基本的相互來往關係。
列出本檔案中用到的專門術語的定義和外文的首字母組詞的原片語。
列出用得著的參考資料，如：
本專案的經核准的計畫任務書和合同、上級機關的批文；
屬於本專案的其他已發表的檔案；
本檔案中各處引用的檔案、資料，包括所要用到的軟體開發標準。列出這些檔案資料的標題、檔案編號、發表日期和出版單位，說明能夠得到這些檔案資料的**。
指出預期讀者。
可採用**形式簡明地描述調研過程，如下表：
其中的調研輸出結果可能包括兩類文件資料：一是使用者的原始資料，如報表樣張或者使用者的內部資料等；二是經過分析和整理的檔案，如調研報告或者會議記錄等。一般把這些資料作為需求規格說明書的附件處理。
說明本需求規格說明書是否包含了立項階段所涉及的所有功能。
如果是合同專案是否包括合同所有需求，及合同以外擴充套件的需求。
說明整個系統的組成和系統執行機理；概述每個子系統的功能，並說明子系統之間的關係。
不同的單位實際的崗位名稱和職責可能不相同，在做需求分析的時候需要加以抽象形成邏輯工作崗位並對每個崗位的職責加以描述。
在邏輯工作崗位及職責確定之後，需要進一步歸納使用者的業務情況。每一項業務都由乙個或者多個崗位的人按照一定順序來完成，可以採用業務流程圖來描述每一項業務。
功能需求是描述乙個產品或專案該做什麼，該提供什麼功能，該完成什麼任務的總結、是整個需求規格說明書的核心。對於功能需求的描述，通常要求下列內容：
採用列表形式列舉產品的所有需求，每個需求均需標識，並需要確定每個功能的優先順序，如可能還應估計每個功能項所需開發時間（包括設計和編碼時間）。
標識號採用層次化命名。需求優先順序建議分為1、2、3級，其中1級為最高端，表示必須實現的功能。
功能清單可以採用下面的**表示：
編寫需求規範之前應該先制定與當前開發的專案/產品相適用的模板，然後根據這個模板來對需求清單中的所有功能進行描述。可以包含下列內容：
包含下列內容：
（1） 使用者的邏輯崗位。
（2） 業務背景。即使用者在什麼情況下使用該功能。
（3） 業務規則。比如演算法
（4） 後續描述中用到的術語解釋
本部分的描述步驟如下：
（1） 分析當前需求需要的使用者介面。一些功能可能需要多個使用者介面；還有一些需求雖然都在乙個使用者介面中，但介面過於複雜，象這種情況需要拆分為幾部分，每部分單獨描述。建議給每個介面（或者介面的一部分）按照一定規則編號。
（2） 針對每個使用者介面需要說明下列內容：
a) 介面完成功能簡介
b) 介面資料描述。對介面中的所有資料項詳細定義，一般需要包含下列內容：資料項名稱、資料項說明、資料型別及限制規則、資料**、預設值等。
c) 介面操作描述。對介面中所有可能的使用者操作詳細定義，一般需要包含下列內容：操作項名稱、操作過程描述、操作過程中隱含的系統處理、操作的限制條件（即什麼情況下該操作失效）等。
規定應用程式必須支援的介面/介面。它應非常具體，包含協議、埠和邏輯位址等，以便於按照介面/介面需求開發並檢驗軟體。（僅指外部介面）
說明軟體將實現的使用者介面。
指出軟體所支援的所有硬體介面。
此節說明軟體系統中與其他構件之間的軟體介面。這些構件可以是購入的構件、取自其他應用程式重新利用的構件。
說明與其他系統或裝置（如區域網、遠端序列裝置等）的所有通訊介面。
需要對軟體靜態和動態兩個方面的效能作出定量規定。
可能包含如下內容：
● 所支援的併發使用者數。
● 容錯要求, 如異常操作後應如何處理，如編制預算過程中突然中斷時應能自動恢復或保護上一次編制狀態。
● 資料的處理能力要求，如可處理的檔案和記錄數,表及檔案的大小規模, 資料增長情況。
● 對資料儲存的空間的要求。
● 正常或極端情況下，對使用者操作響應速度的要求。
如：美化介面等；
在需求分析階段經常用到一些模型來輔助說明，如果採用結構化分析技術，通常使用資料流程圖、實體聯絡圖；而採用物件導向的分析技術，通常使用例項圖、順序圖、協作圖和狀態圖。
如調研報告、會議記錄以及調研過程中獲取的使用者原始資料等。
如原型風格說明、功能規範模板、使用者調研規範等。
本需求文件建立在雙方對需求的共同理解基礎之上，是後續的開發的依據，是使用者驗收的依據。經甲乙雙方確認簽字後，最終確定。如果需求發生變化，請提出正式書面要求，並且雙方協商成本、資源和進度等。
還款確認書
國家助學貸款還款確認書 編號 國家開發銀行湖南省分行 經對 國家助學貸款借款餘額明細表 的核實，結合本人畢業後就業情況，特做如下確認和承諾 一 本人確認自年月日以來，從貴行共獲得國家助學貸款金額合計 大寫 人民幣 二 本人承諾，從畢業的年月1日 含1日 起至年月日按與貴行簽訂的借款合同償還該期限內的...
成交確認書
深圳市土地使用權掛牌出讓 出讓人 深圳市國土資源和房產管理局法定代表人 張士明 位址 深圳市福田區振興路建藝大廈 競得人 法定代表人 競得人 法定代表人 競得人 法定代表人 競得人 法定代表人 競買標誌牌號 出讓人於 2005 年 12 月 8 日至 2005 年 12 月 22 日，在深圳市土地房...
作品確認書
第五屆佳能 感動典藏 攝影大賽 作者姓名中文 英文 手機號碼 固定 號碼 郵政位址 郵政編碼 職業 職員 個體經商 學生 自由職業者 專業攝影師 無業 其它 性別男女 身份證號碼 所使用的相機 canon eos digital 機型 使用鏡頭 canon digital ixus 機型 canon...