系统全局分析，分析粒度保持在模块管理，目的是获得系统的全局认识。第一节是从业务的角度获取需求和用例，第二节是从系统的角度获取需求和用例，我称这个粒度为一级用例，第三节和第四节是在前两节的用例基础上分析主流程和对象。
.、业务用例在软件项目里，业务范围和系统范围是不同的。业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都是客观存在的。系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集，但是一些系统功能则会超出业务范围，例如操作日志，有没有操作日志并不影响业务目标的达成，客户也不一定会提出这个要求，但从系统角度出发，操作日志会使得系统更加健壮。——来自《大象—ThinkinginUML》在引入计算机系统之前，业务也一直跑得很顺畅，因此在初始阶段，不引入系统的角度，纯粹站在业务的角度，分析业务的主流程场景，获取业务用例。获取业务用例需要分析出业务主角和用例，业务主角即参与到业务流程中的角色，例如采购员、售前客服等。用例即业务主角需要在业务流程中完成的事情，这里需要注意用例的粒度，我经过思考，系统全局分析阶段，建议使用管理一类事物的粒度，例如销售订单管理，这个粒度仅供参考。
开始获取业务用例，以下是一段商家工作内容的场景。店长小明想开一家网店，在商品上架销售前，小明做了以下准备工作，①在淘宝注册一个店铺；②选择想要做的品类和卖的商品，并维护商品信息；③找合作快递公司，用于发货给客户；④找仓库，用于存储采购的商品；⑤店长还需要