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