需求規格書編寫完成后如何讓客戶快速、順利地確認簽字？這是個常見問題，每個軟件項目經理和需求工程師都遇到過，要解決這個問題要從甲方客戶與軟件工程師兩個方面進行分析和找答案。

從客戶方面看，存在兩個問題：一是要看得懂需求文檔、二是要能放心地簽字。提出需求的客戶可能不是軟件方面的專家，他是從自己熟悉的業務視角提出的需求，但他可能不清楚這個需求實現后的應用模式（原型、操作等），擔心自己考慮不周簽了字，待開發完成后與設想不同時要擔責任，所以遲遲不肯簽字（人之常情）。

從軟件工程師方面看，已經理解了需求、給出了方案，甚至做出了原型給客戶演示，每個功能都是和客戶確認過的，客戶為什么還有擔心而不敢簽字呢？

回答這個問題前，再來確認一下需求文檔的用途及要求。需求文檔有兩個基本用途：

■用途1. 需求文檔是對用戶提出需求的記錄、分析、設計（業務）結果，是向客戶確認需求和設計成果的依據，也是最終客戶驗收系統的依據；
■用途2. 需求文檔是向技術開發工程師做系統需求交底的資料，是后續設計（技術）、開發、測試的依據；

也就是說這份文檔需要同時滿足兩個方面的要求，即：客戶及開發工程師。既要讓客戶看得懂（偏客戶業務的表達）、還要讓開發工程師能作為依據（偏軟件專業的表達）。這就產生了矛盾。怎么解決這一對矛盾呢？

由于需求文檔的內容較多，這里僅用原型的文檔例子來說明如何做好需求文檔并獲得客戶的確認和簽字。可以根據客戶業務的復雜程度，從三個層面向提出需求的客戶進行說明。

一、記錄形式的結構化
首先“需求規格書”的記錄要采用結構化、標準化的形式，這個記錄要做到對原型界面上的字段進行一對一的說明，由于是“一個字段、對應一條說明”，不存在有含義隱蔽的、難以理解的大段文字說明，這樣客戶就容易理解、確認，可下圖所示的是一組記錄需求規格內容的模板樣例（需求規格書，簡稱4件套）。

注：需求規格書（簡稱4件套）的使用方法參見第13章功能的詳細設計。其中：
■模板1—業務原型：給出界面業務內容的布局、字段的位置。
■模板2—控件定義：用表格方式記錄所有字段的名稱、字段內容、相關規則等。
■模板3—規則說明：用文章體的方式對該原型內的復雜規則進行詳細的說明。
■模板4—邏輯圖形：用圖形方式表達該功能內用文字難以說明的復雜邏輯關系。

二、業務邏輯的驗證
第一層的方法，是對每個原型內的字段、規則等進行了獨立的描述，當業務邏輯、多原型之間的關系、業務場景等非常復雜時，僅僅給出單獨的原型說明不足以讓客戶放心，這時可以增加“業務用例”的方式進行多原型的聯合驗證，以證明多原型間數據邏輯關系的正確，下圖為業務用例的設計示意圖。

注：業務用例導圖的設計方法參見第21章用例設計。

三、應用場景的驗證
需求記錄的格式標準化了、原型間的邏輯關系清楚了，如果客戶還不能完全放心的話，可以在最后進行“應用用例”的驗證，應用用例可以向客戶展示完成的系統外觀是什么樣、怎么操作、系統怎么運行、以及系統的易用性是否可以讓不同崗位的用戶滿意等。

注：應用用例導圖的設計方法參見第21章用例設計。

上述三個層面的內容說明，對復雜的系統僅僅有文字說明、原型有時還不足以讓客戶放心，還需要注意需求記錄格式的可確認性、系統對復雜業務場景以及系統操作的適用性等。按照上述三個層面的要求做出的需求文檔，把原型的功能從里到外都表達清楚了，客戶應該可以放心地簽字了。這樣的記錄形式不但滿足了客戶的簽字要求，同時也符合續開發工程師對需求文檔的編寫粒度、質量的要求。（根據軟件項目的復雜程度，確定是否使用業務用例和應用用例的驗證）。

當然，還有一個對軟件工程師非常重要的要求，那就是平時與客戶建立起相互信賴的關系也是非常重要的，客戶對你的專業水平、責任心的認可，在簽字時也起著看不見的重要作用。

注：以上方法和圖形的詳細說明詳見拙著《大話軟件工程—需求分析與軟件設計》一書。

總結

以上是生活随笔為你收集整理的如何让不懂信息化的甲方客户看懂需求文档，并确认签字？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。