《需求說明書》是需求階段最關鍵的產出物，我們公司測試部的同事常常抱怨，有的項目的需求說明書看到末尾還是不清楚系統要做什麼，無法寫出測試案例。我想我們很多人，尤其是工作經驗不多的人，對需求說明書要寫些什麼東西也是糊裡糊塗的，即使能夠從RUP的教材上搬出來一些名詞，也往往不理解其中的內涵。我把我的經驗寫下來，放在部落格上，一方面自我總結，另一方面，希望和大家討論，共同提高。 以前我們學過各種各樣的軟體工程理論以及具體的操作方法，我也不記得這些書籍或者資料裡面是如何講解需求說明書的寫法的。可能是我當時沒有認真學習，也可能是當時對很多東西並不理解，死記硬背一些東西過會兒就忘了。 我認為，需求說明書首先要描述目標系統的背景、功能概述、系統邊界、和其他系統的關係、系統的運行環境要求等等。然後針對目標系統的每一個功能逐一詳細描述。詳細描述需要說清楚如下四個要素：<!--[if !supportLists]-->1、 <!--[endif]-->該功能的商務程序，<!--[if !supportLists]-->2、 <!--[endif]-->該功能的商務規則<!--[if !supportLists]-->3、 <!--[endif]-->該功能的操作介面<!--[if !supportLists]-->4、 <!--[endif]-->該功能涉及的業務實體
商務程序：商務程序說明這個功能的辦理步驟、以及每個步驟有哪些角色參與。建議商務程序用活動圖表並輔以文字加以描述。
商務規則：商務規則是指業務辦理過程中的一些約束條件，包括前台介面校正規則和後台商務邏輯規則。商務規則一般用文字描述，建議緊接著商務程序圖，針對商務程序圖中的每個操作環節，逐一描述其商務規則。
操作介面：操作介面是要說明，系統建成之後，使用者面對的操作介面的布局以及介面元素。有些人喜歡用visio畫原型介面，我本人建議用html做原型。用html有兩個好處。<!--[if !supportLists]-->第一， <!--[endif]-->逼真。可以做到原型系統的介面以及操作模式和驗收後的真實系統非常接近。這樣使用者就容易對系統產生直觀的認識，需求階段提意見也提得更準確，可以大大減少需求的不確定性。<!--[if !supportLists]-->第二， <!--[endif]-->用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 功能名稱13.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. 附錄
本文出自 “非也” 部落格，請務必保留此出處http://feiye.blog.51cto.com/126688/40405
