需求文檔是否需要用戶簽字

在軟件開發中，需求分析和需求管理一直被認爲是軟件開發成功與否的關鍵。 
  
在CMMI中，需求管理是CMMI2級的過程域，需求開發是CMMI3級的過程域。 
  
在瀑布型生命週期當中，安排了需求分析階段，一般也安排需求分析里程碑評審。 
  
瀑布型生命週期存在了很多年，曾經幾度寫入到軟件開發的國際標準、國家標準當中。 
  
  
由於瀑布型生命週期如瀑布般順流而下，在設計階段開始後，根據需求文檔的結果來開 
展工作，要求需求文檔的結果比較清晰、穩定。所以對於需求確認，往往地採用簽字的 
方式，希望各方慎重、全面、充分的確定需求。 
  
簽字確認需求文檔這個做法幾乎成爲一個標準過程，在大大小小的軟件開發中出現。  
  
那麼軟件工程發展了這麼多年之後，發現經簽字確認的需求仍然有大量的變更，不禁要 
問：需求文檔需要簽字確認嗎？ 
  
在軟件沒有開發的時候，分析需求需要各類想象，對於目前一般規模的商業軟件（全部 
12人月工作量以上）而言，而無論做得如何仔細，就算訪問所有的干係人，也不能把所 
有環節全部考慮到。而在軟件開發的過程中，時間在推移，隨着時間的推移，用戶的需 
求會不斷的發掘、修正；開發人員對軟件需求的認知也是隨時間推移而漸漸的清晰。而 
隨着軟件的開發部署，經過初步的使用，變更的要求、升級的要求就自然的產生了。 
  
所以需求在變化，或者說需求在演化，這是客觀規律。 
  
在需求的演化之中，簽字確認有用嗎？ 當然有用，用處是在這個簽字的一瞬間保留了需 
求的一張快照，這張快照對於履行合同是有用的，在短期內指導後續的工作，但是除此 
之外並沒有太大的用處。因爲這演化中的需求會漸漸地與這張快照不一樣。 
  
傳統的瀑布型生命週期中就需要設計需求變更管理流程，每一次的變更都需要多方的籤 
字確認。爲了維護一致性，還需要追溯需求文檔、設計文檔、代碼、測試用例的一致性 
。需求變更成爲不少項目風險的最大來源，成爲大量項目不成功的最大原因。 
  
簽字的另一個問題是簽字很麻煩，對於甲方而言，簽字意味着責任，往往要拖到最後， 
認爲各方面都沒有問題後才能簽字。而需求分析或變更都是後續工作的前提，簽字的拖 
期也將推遲後續工作的開展。 
  
因此簽字確認需求文檔的弊端有： 
  
1，  簽字不能真正的確認需求。 
  
2，  簽字過程慢。 
  
所以，值得回過頭來反思：簽字確認的需求有用嗎？有沒有更好的方式？ 
  
如果需求文檔寫在軟件運行之後，那麼以軟件運行的截屏爲主體的需求文檔肯定比軟件 
運行之前想象之中的需求文檔更加精準，而且書寫文檔所費工作量大大減少，而且這個 
需求文檔經過簡單的轉換，就可以成爲用戶文檔。 
  
怎麼可能在沒有需求文檔的情況下，把軟件開發出來？ 
  
完全有可能。回想下當年讀書的教研組，回想下自己的編程經歷，總有至少那麼幾次， 
在種種的原因下，在沒有需求文檔的情況下，軟件已經編寫好了。也許那個軟件規模小 
些，質量不是太好，但確實是沒有需求文檔的情況下把它編了出來。 
  
所以沒有需求文檔是可以把軟件開發出來的。 
  
爲了保證這樣的軟件達到要求，顯然需要另外的手段。筆者認爲最要緊的手段是快速地 
將運行的軟件給用戶試用或觀看，收集用戶的反饋，根據用戶反饋再修改。這是敏捷軟 
件開發所倡導的“短迭代”和“可運行”+“反饋”。 
  
不簽字的需求文檔有如下的好處： 
  
1，  快！記錄關鍵的需求，不必求全，細節可以在軟件運行後再來確認和補充。 
  
2，  容易與用戶溝通，達成口頭認可，就可以開展後續工作。 
  
顯然這裏有這樣的一個要求： 
  
需求的提供方需要不斷澄清和講述需求是什麼樣，要不斷回答“這樣行不行？”，要提 
出“不是這樣的，應當…”。 
  
如果開始時不留詳細文字，號稱要敏捷，而在過程中開發方與需求提供方又沒有頻繁的 
溝通，那麼誰來保證開發的東西是不是用戶想要的？ 
  
   
  
以下的最近發生的實例。 
  
AB公司試圖管理自主產品的許可證發佈，保障軟件不被盜版，並進行統計，要利用已經 
有的AI系統擴充這部分功能。新功能主要分成2塊：1，產品管理，2，許可證發佈 
  
在產品管理裏主要維護產品和產品版本的信息。許可證發佈中，根據已經有的產品版本 
來申請許可證，產品開發部門審批後，IM系統能夠自動生成許可證。 
  
爲了開發這部分功能，在2010年，項目組首先書寫了長達86頁的《產品管理模塊功能需 
求規格書》，歷經了2次會議評審後，進行開發。 
  
在2010年12月開發了第1版後，發現仍然有不足，還需要添加其它功能，也有一些修改。 
  
  
對於2011年開始的修改，項目組在產品經理的建議下，不打算書寫或修改需求功能規格 
書，採用敏捷開發的部分方法來處理。 
  
下面是2011年1月17日到2月22日，產品經理陸續寫給項目組的“原始需求”： 
  
ID      標題    創建時間 
  
205453  經過審批的許可證，許可證申請者可以直接打印蓋有章的書面許可證書  2011-2 
-22 14:28 
  
204436  每個許可證有唯一的編號  2011-2-12 8:45 
  
204348  合理化建議能夠提供導入功能。    2011-2-10 15:42 
  
203959  IM系統能夠讓普通寶信員工簽發最長半年的許可證    2011-1-26 9:58 
  
203958  自主產品加入內部定價    2011-1-26 9:36 
  
203957  自主產品的開發部門分管領導應當設置      2011-1-26 9:23 
  
203956  自主產品有不再應用的狀態        2011-1-26 9:21 
  
203908  自主產品版本含許可證模式信息，申請許可證時不可以改變許可證模式  2011-1 
-25 10:38 
  
203455  許可證發佈時同時記錄最終用戶聯繫人（包括email)和相應合同總金額和產品銷 
售金額（如果有的話）    2011-1-17 15:35 
  
項目組在2月21日那個周開始了針對以上8個原始需求的迭代，計劃3月31日做完上線。 
  
在這個期間，產品經理每隔2~3天就會到開發現場觀看開發情況，提出意見和建議，有時 
一天之內會去多次。 
  
也利用即時通訊工具與開發人員交流，總共留下了217條對話記錄。 
  
項目組搭建了一個測試環境，產品經理從3-14開始進行試用。 
  
在過程中，通過email，產品經理髮出的變更有： 
  
3-14 許可證流程中取消“提出部門領導預審許可證申請”步驟 
  
3-15 許可證審批流程可以email+短信提醒 
  
3-15 對於產品開發部門審批這個環節，能夠設置2人或多人可以審批。 
  
3-15自主產品管理頁面中 “許可證申請審批人” 改名爲“產品負責人”。在許可證申 
請審批時，產品負責人可以有代理人。 
  
3-21內部使用許可證的最長期限是1年 
  
3-29希望產品檢索頁面能提供中文全文的模糊檢索或提供根據部門檢索。 
  
3-29增加產品開發負責人的字段及相應的聯繫信息，原“產品負責人”應爲“審批人” 
。審批人有A角，原代理人改爲審批人B角。 
  
在過程中，開發人員記錄到的來自於產品經理的意見有： 
  
1       生成導出紙質許可證 
  
2       直接生成許可證（臨時許可證 ） 
  
3       紙質導出  過期時間 如果永久有效 顯示爲永久 
  
4       最終用戶聯繫人 （可能是非寶鋼的人員） 
  
5       許可證統計（依賴關係也統計出來） 
  
6       在許可證申請表上面 ，版本改爲 不必填。最終用戶聯繫人 聯繫方式必填 
  
7       許可證審批是 相應字段必須必填（提出人不必填，審批人必填） 
  
8       許可證審批人可以修改 不控制只讀 
  
9       許可證頁面基本信息頁面佈局調整（項目名稱或事由 與 編號 的位置 對調等） 
  
10      許可證用途  內部使用（有效期控制1年） 
  
11      自主產品和自主產品第一個版本 增加快速入口（並控制相應權限） 
  
12      自主產品添加產品代理人字段，產品名錄 應必選 
  
13      許可證用途  臨時使用 （直接簽發許可證 有效期3個月） 
  
14      許可證 需要添加 許可證數量 這個字段（用於統計，缺省是1）  
  
15      產品英文簡稱，產品代碼不允許重名 
  
16      提交了 自主產品登記後，到達了任務中心 頁面  ，這個不好。回到“自主品登記” 
頁面爲好 
  
17      許可證模式中 需要新加一種 “eCop許可證” 
  
18      impp50 添加負責人 代理人 聯繫方式 
  
19      控制產品負責人和產品代理人 權限 
  
20      email和短信提醒 
  
21      進行中的自主產品登記列表（菜單） 
  
22      電子許可證（依賴關係的產品名稱不正確） 
  
23      許可證申請表 頁面中的 運行所在的操作系統 中 添加多一個選項：其它（電子許可 
證 裏爲OTHER） 
  
24      被依賴簽發的產品能在產品跟蹤管理中查詢出來，查詢條件增加“許可證用途” 
  
4月1日，在沒有需求說明規格書，當然不需要簽名的情況下，這個功能模塊上線，不過 
尚有幾處修改沒完成，總體達到了實用。 
  
以上文字就是在2011-4-1上線版本留下的最主要文字。 
  
如果仍然要求有需求規格說明書，4-1以後再來寫需求規格說明書，那是很方便的事情， 
而且各方簽字會很爽快。