一个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 这个镀金模块最终的下场是，原来的代码全部删除，重新按照原先的设计开发了一遍。