很多需求分析人员一提到用例，第一反应就是画用例图：小人、椭圆、连线。画完图，就以为用例分析做完了。但Ivar博士当年创造用例方法时，想的根本不是画图。他有一次突然想：为什么老在系统内思考要什么功能，不站在系统外来看看呢？这一想，就创造出了用例这一全新方法。
用例的本质，不是用例图，而是思考方式：站在系统外，看用户要用系统达成什么目的。简而言之，用例即业务场景、使用场景。
用例即业务场景
什么是业务场景？在一个信息系统中，业务流程是不同岗位之间通过协作满足外部服务请求的过程。而业务场景，是以某岗位为主完成的、相对独立的、可以汇报的业务活动。
举个例子。体检流程中，体检者交费、医生体检、服务人员发报告，这些是业务流程。但站在某个岗位看：收费人员完成收费，这是一个业务场景；体检医生完成体检并记录结果，这是另一个业务场景。每个场景相对独立，可以单独汇报。
所以，用例的粒度，从某种角度而言，是由组织分工决定的。分工不同，用例的边界就不同。
多大才是合适的用例？
这是困扰很多实践者的问题。《编写有效用例》提出分层用例，更让人困惑。其实，困惑来源于对业务场景、使用场景的理解。一个完整的业务场景应该是独立的、可汇报的、可暂停的单元。
-
独立的：不依赖其他场景就能说清楚。 -
可汇报的：能向别人讲明白“谁做了什么、得到了什么”。 -
可暂停的：做到一半有事离开，回来还能接着做，不会前功尽弃。
用这个标准检验常见用例。
“用户登录”是用例吗？从系统角度，它是个功能。但从用户视角，用户登录是为了干别的事，登录本身不是目的。你不会登录完就心满意足地离开。所以，登录通常不是一个完整的业务场景，它只是其他场景的前置步骤。如果把它单独作为用例，粒度就太细了。
“用户注册”呢？同理，注册完还要用系统，注册本身不是终点。除非注册本身就是目的，比如某些网站注册即完成。
“提交订单”呢？在电商系统中，用户浏览商品、加入购物车、提交订单、支付，这是一连串动作。如果以“提交订单”为用例，用户提交完就离开，订单还没支付，场景不完整。更合适的用例可能是“购买商品”，包含从选商品到支付完成的完整过程。
不带业务流程的项目，用例就是用户使用场景
对于不带业务流程的项目或产品，用例就是一个用户的使用场景，也是一个相对独立的、可以暂停的场景。
比如搜索引擎。你不会输入一个关键词就离开，即使离开，也肯定是临时有事。所以“输入关键词”不是一个完整的使用场景。完整场景可能是“搜索并找到答案”：输入关键词、浏览结果、点击链接、阅读内容。这才是一个独立、可汇报、可暂停的单元。
再比如，即时通讯软件。发一条消息算用例吗？发完消息，用户还在等回复，场景没结束。更完整的用例可能是“与某人完成一次对话”：发送消息、接收回复、继续交流，直到对话结束。这才是一个完整场景。
总结
用例的本质是用户视角的需求观，强调目的和场景。用例图只是表达方式，不是本质。一个合适的用例，就是一个完整的、独立的业务场景。粒度由组织分工决定，判断标准是：独立、可汇报、可暂停。理解了这一点，用例分析就不会再困惑。
最后，四句诗总结：
用例本质是场景，用户视角看端详。
独立汇报可暂停，粒度分工定短长。
参考书目：有效需求分析 ，作者： 徐锋，出版社： 电子工业出版社
