一個OA項目，原來的需求文檔已經面目全非了，得益于版本管理，找到了需求差異分析前的最后一個版本：
3.1.2.6. 安排其他用戶日程
? 用戶在查看同事日程安排頁面中點擊“添加日程安排”按鈕
? 系統顯示日程安排添加頁面
? 用戶選擇時間，填寫事務詳情，預計需要時間，選擇事務類型，是否公開
? 用戶點擊“提交”按鈕
? 系統檢查時間沖突
? 時間上沒有沖突
? 系統記錄新事務
? 系統顯示操作成功頁面
? 存在時間沖突
? 系統提示存在沖突的事務，提示是否修改事務
? 用戶確認添加
? 系統記錄新事務
? 系統顯示操作成功頁面
? 用戶選擇修改事務
? 系統返回到日程安排添加頁面
寫完這個版本之后我出差去做需求差異分析，其他同事則按照暫定的需求文檔開始做編碼（時間緊迫，設計被跳過了，后來的設計文檔都是從
代碼反向工程處理的）。
在我出差期間，有個同事提出了，一個日程安排在某些情況下應該可以指派給多個同事，因此產生了一個“日程草稿”的概念，即一個日程可
以先起草然后再反復指派給多個用戶。負責開發這一模塊的兄弟們覺得大有道理，于是照此開發。
出差回來后我更新了需求文檔，但是這一部分用戶并沒有提出異議，因此沒有修改。直到上周開發基本完成，這周一開始做SIT。這時我才發現原來我現在要安排一個日程的話一定要先起草一個“日程草稿”再把它指派給自己或者別人。這就好比我要發個email，就要先寫個email保存到草稿箱里面，再去草稿箱里面把它找出來發。
這當然是不能接受的，于是要求兄弟們按盡可能少的修改工作量進行修改，也就是說把保存草稿再取出草稿這個過程包裝起來，自動保存后直
接指派出去。但是由于檢查時間沖突并做出響應的流程并不是為草稿設計的，不得不修改了流程、設計并重新編碼。今晚和兄弟們一起加班修正這個問題，希望明天可以開始SIT.
“一個日程安排在某些情況下應該可以指派給多個同事”是一個沒有被確認的需求鍍金，在沒有被仔細考察的時候就輕率的被依以設計，造成了今天的困境。
jackei 發表于
2005-01-19 10:19 AM 這就是為什么一直在強調在測試過程中，超出已經明確定義的需求的功能也同樣是軟件缺陷，因為這中新增的功能是未經確認的，另外，對于項目來說，也增加了一些原本可控的風險之外的新的風險。昨天還在同大家解釋這個問題，看來emu幫我找到了一個更好的例子^_^
emu 發表于
2005-01-21 5:08 PM 超出已經明確定義的需求的功能也同樣是軟件缺陷？
從來沒有從這個角度考慮國問題，有意思。
實際情況是我們常常沒有充分明確的需求定義。第一步規范不起來，后面就只有越走越遠了……
emu 發表于
2005-04-22 11:55 AM 這個鍍金模塊最終的下場是，原來的代碼全部刪除，重新按照原先的設計開發了一遍。