运营商的系统，不会每年让都这么大规模的让你折腾，是的，这次机遇难得！目前参加的项目，需要对原系统推翻重来，无论从数据模型，还是技术架构上，都需要进行大规模的升级改造。

    由于系统业务的复杂，虽然需求明确，前期需求分析也做的很充分，但开发人员还是需要对照原系统的代码来开发业务逻辑。因为需求分析得再细，也细不到某个前台录入的数据，应该特殊处理到某个字段。

     因此开发起来效率不高，而且业务不满足的风险极大！

     公司在需求管理方面，可以说投入不可谓不大，有专门的人，购买专门的系统来管理，但通过这次系统升级发现，之前的需求管理对这次一点帮助没有，最多是保存了些原来客户提的需求文档。做分析的时候还可以，但真正指导开发，还是有一定差距！问题到底出在什么地方？怎么样的需求管理，才能把当前系统的情况完整展现出来？

     我也不知道，我只能把现在的情况描述下来，希望有经验的人士给点意见，在此多谢先：
     （1）需求分析：把整理的需求文档汇总，1-2年下来，这些文档有几个G，一个人看下来简直是不可能的任务，分模块后，一般每个模块有个需求小组来完成需求分析工作，输出业务模型（概念数据模型），更多是让这些人（将来的组长）熟悉自己要做的业务细节。
     （2）概要设计：主要的工作是细化概念数据模型，成物理模型。
     （3）详细设计：我们基本没有，因为这个工作量太大，一般到概要设计，出数据模型后，边开发，边做详细设计，这时还会继续维护物理数据模型。
     （4）代码开发：人员流动很大，新员工很多，很多不熟悉业务，不知道要做的东西干什么的，技术和业务培训会经常进行。这时，问题来，架构设计后，开发人员对照着原代码的逻辑进行写程序，因为需要了解原来的程序怎么走的，为什么这么判断，这个工作很烦躁且必须，因为你不能丢掉原来的功能点和业务限制。

     （5）测试：这也是问题，问题就是用例的粒度很粗，没有特别熟悉业务的人员，因此业务限制的缺失无法测试得到！

      这么看来，还是功能点的详细设计没有做好，业务限制没有整理出来，如果通过非常明细的测试用例来指导开发呢？