1.1使用用例的时机
将软件开发分为分析-设计-实现这三大步骤的话，用例主要用在分析阶段。也就是说用例是一种系统分析技术。
分析：是为了说明系统是什么，并说明这个系统会做哪些事。
设计：是为了说明系统如何工作，也就是说明系统应该如何一步一步地做到在分析阶段所承诺的事情。
实现：就是按照系统设计，真正的开始编写代码。
通常，系统分析师使用用例之后，主要会有两个结：其一是用例图，其二是用例叙述。
1.2一睹用例图的长相
用例图：
图中小人为参与者，代表系统外部的用户
椭圆为用例，代表系统内部对外提供的服务项目
方框图则表示系统
用例叙述：
用例订购书籍
事件流程：
1.当会员选择订购书籍时，这个用例就会启动
2.会员输入他的姓名和地址
3.会员输入欲购买的书籍的书号
4.系统提供书籍说明与每一本数的价格
5.当会员输入欲订购的书号时，系统会持续保留订购的累计金额
6.会员输入信用卡付款的信息
7.会员确认订购
8.系统核对信息，保存订购信息，并且把付款信息转交给会计系统。如果信息有任何不正确的地方，系统就会提示会员修正该信息。
9.当付款信息确认后，订购交易会标记为“已结账”，交易代号会回传给会员，而且这个用例即告终结。如果付款没有确认，系统会提示会员修正付款信息或取消。如果会员选择修正该信息，则轨道上述的第6个步骤。如果会员选择取消，则该用例即告终结。
1.3绘制用例图
确立系统边界，就是先划定一个系统范围，晚点再来推敲系统范围内该做的细节。确立边界就像剁鸡一样，需要的留下来，不需要的剁掉。所以系统分析师要做好下面两件事：
1.找出位于系统外部的事物，画小人。我们不需要开发位于系统外部的事物，但是需要考虑建立接口，让系统内外可以通过接口传递信息。就好像我们虽然不要鸡头，但是还是需要知道鸡头和鸡身连接的关节在哪里！
2.找出位于系统内部的事物，话椭圆。这些这是我们需要考虑开发的部分。
所以确立系统边界的具体做法就是：分内外，向系统内找用例，向系统外找参与者。
1.3.1.找参与者
参与者是位于系统外部的用户、联网的其他系统、硬件设备或者数据库，它们并不是系统的一部分，所以开发团队不需要构建这些参与者。不过由于参与者会与系统互动、参与用例，以便获得特定的服务或结果，所以潮流发团队需要为它们设计接口，以便它们能够顺利地通过接口与系统交换信息。
虽然参与者的图标是人型图标，但不代表只有人类用户可以扮演参与者，位于系统之外并且会与系统交换信息的人或物（如与系统联网的系统，硬件设备，数据库等），都有可能成为系统的参与者。
那么到底先找参与者好？还是先找用例好？如果一定要有一个先后参与者的话，笔者建议先找参与者。
主要原因有：
1.参与者用例明显。
2.参与者的个数远比用例的个数少。
3.找到一个参与者，就可以找到一堆用例。
4.参与者是系统外部任务的代表，所以当然要先找出参与者，才能够从参与者的角度去寻找用例。
如何下手寻找参与者呢？可以参考如下的问题：
1.谁会来使用这个系统？
2.谁会来安装这个系统？
3.谁会来启动这个系统？
4.谁会来维护这个系统？
5.谁会来关闭这个系统？
6.哪些系统会来使用这个系统？
7.谁会从这个系统获取信息？
8.谁会给这个系统提供信息？
9.在预先设定的时间到达时，有什么事情会自动发生吗？
10.哪些系统会与这个系统联网？
11.是否有硬件设备会与这个系统联网？
12.哪些数据库会与这个系统联网？
13.公司内部有哪些人员会使用这个系统？
14.公司外部有哪些人会来使用这个系统？
15.当特定的时间或事件发生时，这个系统需要自动通知什么人，或者是自动通知其他系统吗？
这情况真多啊，其实也未必覆盖完全，自己多做考虑就好了。
1.3.2.找用例
用例是系统的一项行为，它能够生成参与者可评价的结果。
这句话包含如下两个重点：
1.用例是系统的行为，所以它将包含着时间的概念，它会花费一段时间，具有一个执行过程。因此，当系统分析师描述用例时，要特别注意它所经历的一连串操作，而且这一连串的操作，正式参与者与系统之间的互动。
2.用例不仅能够，同时也必须，生成可以供参与者评价的服务或结果。也就是说，用例执行结束时，必须有一项明确的结果，并且参与者要能够接受这项结果。
参与者和用例之间有关系线，代表参与者将参与这个用例.
找到参与者之后，再找到用例就容易多了。我们可以针对每一个参与者寻找相关的用例。同样的我们可以问问自己下列问题，对于寻找用例帮助很大：
1.参与者想要从这个系统获得什么样的功能？
2.这个系统存储信息吗？哪些参与者将建立、读取、更新或删除这些信息？
3.当系统内部状态有变化时，这个系统需要通知参与者吗？
4.是否有什么外部事件是这个系统需要知道？当这些外部事件发生时，哪些参与者会通知这个系统？
5.这个系统需要定期执行什么操作吗？
6.当发生了某些重要的外部事件时，这个系统需要自动执行什么操作吗？
7.这个用例的名称够明确吗？是否能把从这个用例的名称，直接判断出它的结果？
8.这个用例会有许多不同的结果吗？还是这些结果，其实是在不同的时间点产生的？
不过特别要提醒的是，这个系统边界并不是这样定下来就不会改变了。事实上，在开发的过程中，随时都有可能回过头来修改这张用例图，但是别担心，修改的频率和幅度会随着项目时间的增加而迅速放缓。同时，你也会因为使用用例越来越纯熟，而下刀越来越精确。
参与者的特性：
1.参与者位于系统外部，它不属于系统的某一部分，所以我们不需要去构建参与者。
2.只有会使用系统、会跟系统互动、会跟系统交换信息的，才是系统的参与者。
3.参与者会启动、参与用例，所以找到参与者，就可以引导我们找到用例。
4.我们虽然不需要构建参与者，但是却需要考虑接口。系统需要提供接口让参与者使用，或者系统需要用到参与者提供的接口。