使用业务序列图原因：
一、活动图只关注人，序列图把人当作系统。活动图描述流程时，往往会忽略了非人工系统的责任。
二、活动图表示动作，序列图强迫思考动作背后的目的。序列图不但表达非人工系统的责任，也揭示出某个岗位对外暴露的责任，序列图可以在业务建模和系统建模的过程中始终贯彻“对象协作以完成用例“的思想。
三、活动图更“灵活”，序列图更不“灵活”。“很容易画”的活动图容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图强迫开发人员通过alt、loop等结构化控制片段描述业务流程的方式去思考，通过故事来思考待开发系统的位置。
业务序列图要点：
一、消息代表责任分配而不是数据流动。在序列图中，焦点是对象之间的责任和写作，数据流是作为消息的输入输出参数存在的。建模人员不但要看到数据的流动，还要找出背后的责任。消息代表对他人提供的服务，如果没有指定目的可以用“处理...”来命名，消息名称中不需要带“请求”二字，箭头已表明请求的意义。
二、聚焦于系统之间的协作。业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人肉系统。建模的基本原则是抽象级别的一致，勿需细化到每一步操作。
三、只画核心域相关的系统。一个智能系统要不要成为序列图上出现的业务实体，要根据“它是否核心域内的系统”来判断。
四、把时间看作特殊的业务实体。这样便可以映射到系统用例的时间执行者。注意，时间是外系统，世上只有一个时间系统，定时器是其他系统用来和时间大交道的边界类，定时器会有无数个。
a.绘制现状业务序列图：现状好比拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。根据不同的业务用例，会有多个业务序列图。
应避免的错误：
一、把“现状”误解为“纯手工”。业务流程中有人工系统也有非人工的系统，新系统的需求需要通过研究业务现状，再结合愿景推导得出。
二、以待开发系统为中心拼凑流程。业务建模时，摄像机应该一路跟随着实现业务用例的流程去拍摄，如实反映拍摄的故事，各个系统知识流程中的一个零件。业务建模就是要从业务流程中待到代开发系统的位置，证明该系统对实现业务用例是有帮助的。
b.绘制业务交互概述图：将各个业务用例的序列图串联起来。
c.改进业务序列图：挑选一个最值得改进的业务序列，阐明原因，然后空降一个系统，画出改进后的序列图，从而得到第一批用例。注意UML建模不是为了“先建模后需求在分析”的顺序而使用，而是迅速定位最值得改进点，得到最有价值的用例，先开发。这才是敏捷。
改进途径：
一、物流变信息流。为降低流转成本，尽可能把物流变成信息流，在需要物的时候才将信息变成物。
二、改善信息流程。可以依靠引入一个新的系统来达到在多个信息系统之间实现信息传递和协调。
三、封装领域逻辑。通过将人脑中的领域逻辑提炼封装到信息系统中，使人脑得到解放。在绘制业务流程时，非常重要的改进点是：一定要注意画出人脑中的思考逻辑，避免白开水一样的业务流程。前两条改进，系统内部封装逻辑不复杂，效率高，而做到第三条，就可以靠软件的功能就能卖钱。
四、阿布思考法。
改进思路是：1.假设有足够的资源去解决问题，得到一个完美的方案；2.用手上现有的资源去山寨这个完美方案。例如：中国组织最得力的会议是靠人脑组织的全国人民代表大会，做会议软件的话可以山寨一二。
“创新的需求是从观察和思考的汗水中来，不是把拍脑袋闭门造车的所谓‘头脑风暴‘当作调研”。
2-系统建模：与业务建模不同的是研究对象，业务建模的对研究对象是组织，而系统建模的研究对象是系统。
1.画出系统用例图：有了业务建模的铺垫，系统用例实际上以呼之欲出。
1). 系统用例图：
a. 确定系统执行者：系统执行者的定义是在所研究系统外，与该系统发生功能性交互的其他系统。有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图映射即可得到系统执行者。
理解要点：
一、系统外：系统执行者不是所研究系统的一部分，而是该系统边界外的一个系统。这里的边界指的是责任的边界而非物理的边界。
二、交互：系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者。系统执行者和重要无关，系统执行者只关注谁和这个系统接口，而正真和重要相关的概念是涉众。用例必须在它的路径、步骤、补充约束中考虑这些涉众的利益。
三、功能性交互：执行者和系统发生的交互是系统的功能需求。
四、系统：系统可以是人肉系统，也可以使一个智能系统，甚至是一个特别的外系统——时间。
业务建模映射出系统执行者的方法：与系统交互（存在实的消息线）的人肉系统或其他系统即为系统的执行者。
注意事项：实际工作中，系统执行者和系统用例是一起识别的。
一、不要把执行者和权限管理混淆。用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。
b. 系统用例：系统用例的定义是系统能够为执行者提供的，涉众可以接受的价值。
用例识别要点：做需求的目的不是为了安慰自己或者走过场，而是让产品更加好卖，不以这个为出发点的需求工作是没有意义的。即使再难，也只能从涉众的视角来定义需求，切不可贪图方便选一个自己熟悉的视角了事。
一、系统用例可以看做系统执行者和系统之间买卖的平衡点，期望和承诺的平衡点。系统用例可以把需求提升到思考系统“卖什么”的高度。（搞清自己的“用例”，认清自己的定位。）
二、思考用例的过程就是发现价值的过程。
三、“粒度”的问题。开发人员切勿玩弄“粒度原则”、“分层技巧”，应该把屁股挪到涉众那边去，揣摩涉众的心理，实事求是的写下来。
对于判断“用例是否用对”的标准：是否加强了和涉众的联系，如果不是，那就用错了。