《需求說明書》是需求階段最關鍵的產出物，我們公司測試部的同事常常抱怨，有的項目的需求說明書看到末尾還是不清楚系統要做什麼，無法寫出測試案例。我想我們很多人，尤其是工作經驗不多的人，對需求說明書要寫些什麼東西也是糊裡糊塗的，即使能夠從
RUP
的教材上搬出來一些名詞，也往往不理解其中的內涵。我把我的經驗寫下來，放在部落格上，一方面自我總結，另一方面，希望和大家討論，共同提高。
我認為，需求說明書首先要描述目標系統的背景、功能概述、系統邊界、和其他系統的關係、系統的運行環境要求等等。然後針對目標系統的每一個功能逐一詳細描述。詳細描述需要說清楚如下四個要素：1、
該功能的商務程序，2、
該功能的商務規則3、
該功能的操作介面4、
該功能涉及的業務實體
商務程序：
商務程序說明這個功能的辦理步驟、以及每個步驟有哪些角色參與。建議商務程序用活動圖表並輔以文字加以描述。
商務規則：
商務規則是指業務辦理過程中的一些約束條件，包括前台介面校正規則和後台商務邏輯規則。商務規則一般用文字描述，建議緊接著商務程序圖，針對商務程序圖中的每個操作環節，逐一描述其商務規則。
操作介面：
操作介面是要說明，系統建成之後，使用者面對的操作介面的布局以及介面元素。有些人喜歡用
visio
畫原型介面，我本人建議用
html
做原型。用
html
有兩個好處。第一，
逼真。可以做到原型系統的介面以及操作模式和驗收後的真實系統非常接近。這樣使用者就容易對系統產生直觀的認識，需求階段提意見也提得更準確，可以大大減少需求的不確定性。第二，
用
html
做的原型可以直接在編碼階段採用，既減少工作量，又使得產品與需求偏離不會很大。
業務實體
業務實體是指商務程序中的各個環節操作的表單、資料等對象。需求階段明確了業務實體以及業務實體的屬性非常有利於後續的資料庫設計。 需求說明書說清楚了“四要素”，實際上就說清楚了如下問題：業務的辦理流程是什嗎？業務辦理條件是什嗎？操作員通過怎麼樣的介面辦理該業務？系統最後操作哪些資料、產生哪些表單？
基於需求的四要素，需求說明書的目錄結構一般是這樣的。 1.
引言
1.1
編寫目的
1.2
範圍
1.3
項目背景
1.4
主要業務名詞和術語定義
1.5
參考文獻
2.
需求概述
2.1
使用者當前系統
2.2
目標系統
2.3
與其他系統的關係
2.4
邊界定義
2.6
系統功能模型概述
2.8
目標系統運行環境要求
3.
詳細需求
3.1
功能名稱1
3.1.1
商務程序
3.1.2
商務規則
3.1.3
業務介面
3.1.4
業務實體
3.2
功能名稱2
3.2.1
商務程序
3.2.2
商務規則
3.2.3
業務介面
3.2.4
業務實體
4.
與其他系統的介面說明
5.
效能要求
5.1
運行效能
5.2
可維護性
5.3
可移植性
5.4
故障處理要求
5.5
不允許發生的事件
6.
附錄
