前言：
如果你的UML图第一章还是用例图请你继续看下去；如果你不知道业务分析图和活动图的关系，请你继续看下去；如果你的机房无论是重构还是合作出现遗漏功能（我重构的时候就把操作员工作记录查询给漏了）请你继续看下去。
一、需求分析的误区
事实上，我机房合作是做了很久很久，事实上代码我们早就敲完了，但是我还是坚持不去结束项目，原因很简单，我想通过机房真正的对于软工有所了解和体会。机房合作的时候我犯了一个致命的错误，我是按照功能分析需求的。举个例子：
机房有一个操作员工作查询记录的功能，我当时只是草草幻想如果是对机房负责人采访的场景：“我需要一个能够查询操作员工作记录的功能。”
事实上这个想法漏洞百出，首先，我们之前重构的系统已经是有一个“正在值班老师的功能”。其次，为什么操作员工作记录是运用组合查询。
我对这些问题思考了很久，当我重新再进行需求分析的时候，我才发现原来我上面错误的想法来源于我一上来就画了用例图。我傻傻的以为，客户说我要这个这个这个功能，我就直接在用例上加上行了。事实上，我根本没有进行需求分析，我只是按照我建好的系统找一个好的借口而已。
二、以业务流程与活动图为开端
“那到底是哪个图为开始？”我的回答是“业务流程与活动图为开端。”在需求分析中，我们首先要了解用户的工作流程，画出他们的活动流程。比如，在机房收费系统教师在管理员可能是这样描述：
“平时值班老师把一天收上来的钱交给我，我首先是要根据今天值班老师名单看是否已经交齐，然后需要进行汇总核对，如果出现问题，我要去具体问一下今天值班老师值班的工作，然后才能分析出账目不对的原因，如果没有问题，那我就可以给老师开账单。”
我这段话可能存在着很多的漏洞（原谅我模拟的不够完美），但是如果你细心就能够发现，“具体问一下今天值班老师值班的工作”这个活动与“操作员工作记录”，有很大的关系，事实上，我正是通过这个活动转换成系统提供的“操作员工作记录”服务的。
也就是说在我们所理解的用例图前面还是有个活动图作为开端的。
那业务流程和活动图有什么关系呢？我就用我现在合作的图来解答这个问题。
这两图上面的是业务流程图，下面是活动图，事实上，这只是一个总体的业务流程，里面包括上下机业务流程，但是当你点击上下机业务流程时候，就会出现我下面的活动图。换而言之业务流程图和活动图是组合在一起的。
笔者认为，一般获取用户的需求都是通过采访等等，是以一个活动业务流程作为主线，用户在业务流程基础上详细描述不同环境的不同需求。
————未完待续