请教，关于使用了框架的系统分析设计过程

不好意思，不知道这个问题可以发这里不。

系统是一个人力资源管理系统，使用的是struts+hibernate框架

我想的分析设计过程：
1  需求分析：系统主要功能（大概16个）、用例图（16个）、用例细化（这个不知道到底是用文字描述用例好些还是用活动图？）；
2  领域分析：根据需求分析提取实体类、控制类、边界类，较复杂的用例用顺序图表示；
3  系统总体设计（体系结构（struts、hibernate、分层）、开发工具、数据库设计（ER图、设计数据表）
4  系统详细设计和编码： 把分析阶段的类转为实际设计的类，顺序图、分层（表示层、业务逻辑层、持久层）编码。


主要是一直开发过程都不是很规范，原本没有用uml分析设计的，现在逐步用uml图，缺少实际应用经验，不知道我象以上这样分析设计可以吗？

先谢。

好细啊....项目几百人在作?

我觉得不可以，一个人力资源管理系统居然联顺序图也用上了，难道业务逻辑真的很复杂吗，uml来理清需求是可以的，但是在具体开发中还是不要用uml，我觉得顺序图的作用其实在这种系统中是体现不出来的，如果流程复杂的话可以写一点program spec，uml也不能滥用（客户要求除外）

用手画出图来
看哪个更能表现出你想要表达的意思
把图给个程序员看,让他陈述一下工作内容
如果没问题就可以了

图是为了交流
不是为了留档

up会害死人的
浪费大把的人力和财力
uml也不能这样用吧

到底怎么用？ 这种系统的oo分析和设计过程是怎么样的呢？文档细到什么程度呢？
只要用例图和用例描述可以吗？

整个用例图，复杂的整个活动图，就可以拉。个人意见。

oo分析是门很大的学问，3言2语说不清呀，文档的话如果逻辑不是很复杂可以不写，如果逻辑复杂的可以写点开发文档，用例图和用例描述就可以了，然后根据用例描述把页面原型开发出来，再根据用例描述和页面原型进行oo分析，等你的原型出来后你脑海肯定就有了oo模型的原始图，然后再提炼提炼就差不多了，小系统做这么多够了

以能沟通为标准
如果老是出悟会那么多加文档
如果大多都很清楚了那就很够了

XP开发时用的图,很多
但很少有变电子版存档的...
都是手工绘制的...
只有明白了才画
不明白不画,再调研
画了就尽量让人能看懂

画用例图是可以的，可能更加明确需求 但是不要在上面花太多时间
接下来就是分析用例了，从中找出领域对象以及服务接口
最后就开始编码啦 采用TDD方式：写测试/测试通过/重构

最怕把大量时间放在需求、分析、设计 最后写出的代码全是垃圾