Use Case 真是个好东西

   做了十多年开发、3年设计了，都是根据口传或.doc来作为需求的，但也没有遇到太大的问题，直到去年和今年的网通集团的一个项目的设计和开发历程，让我越来越对需求感到迷惑。

    不知道这个项目算不算复杂，需求和设计阶段就不说了，从去年10月份开始封闭开发，平均11个人（有2个中间走了，又加入了新人代替），直到现在，终于准备用户测试了。但公司内部测试部提的bug还有400多个，所以可以想象这次测试只是项目的一个中间阶段，用户预计5月底上线，我们也朝这个目标努力。

    越是到了项目的后期，象我们现在，需求问题越明显，原来的.doc需求文档里到底有多少个需求和功能？其实原来的.doc需求很象是用户的业务规范，到底哪些是系统要实现的功能？哪些是体外可以操作的，都搞不清。所以经常为一个需求问题争执：项目经理一个意见，需求人员一个意见，设计人员还有内部实现的担忧，开发人员也已经实现了一个版本了，是否要修改？修改成什么样子？

    需求想想办法了。原来一直做开发和设计，本不想再涉入需求管理，但形式所逼，不能靠别人了，只能自己来。我买了本Use Case的书，这一周看一章，觉得收获挺大。如果项目真能把需求用Use Case方式都列出来，那么系统的功能就很清楚了，至少明白了用户需要使用系统完成什么工作，而不只是我们根据用户的业务规范来猜测。

    先写到这里吧，有时间再交流！