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