注意事项：实际工作中，系统执行者和系统用例是一起识别的。
一、不要把执行者和权限管理混淆。用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。
b. 系统用例：系统用例的定义是系统能够为执行者提供的，涉众可以接受的价值。
用例识别要点：做需求的目的不是为了安慰自己或者走过场，而是让产品更加好卖，不以这个为出发点的需求工作是没有意义的。即使再难，也只能从涉众的视角来定义需求，切不可贪图方便选一个自己熟悉的视角了事。
一、系统用例可以看做系统执行者和系统之间买卖的平衡点，期望和承诺的平衡点。系统用例可以把需求提升到思考系统“卖什么”的高度。（搞清自己的“用例”，认清自己的定位。）
二、思考用例的过程就是发现价值的过程。
三、“粒度”的问题。开发人员切勿玩弄“粒度原则”、“分层技巧”，应该把屁股挪到涉众那边去，揣摩涉众的心理，实事求是的写下来。
对于判断“用例是否用对”的标准：是否加强了和涉众的联系，如果不是，那就用错了。
业务建模映射出系统用例的识别方法：在业务序列图中，从外部指向所研究系统的消息可以映射为该系统的用例。
识别系统用例的注意事项：
一、主执行者和辅执行者：主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来。场景：主执行者要执行用例，需要辅执行者的帮忙。
二、切勿把到辅执行者的箭头误解为数据传送的方向。
三、主辅执行者是针对某个用例来说的，一个系统在这个用例中充当主执行者，也可以在另一个用例中充当辅执行者。一般说来，辅执行者是人肉系统的情况比较少，更多时候是另一个非人智能系统。
四、用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然是越多越好。
五、需求是不考虑“复用“的，如果在考虑”复用“，要紧惕自己是不是已经转换到了设计视角来思考问题。
六、针对不同执行者、不同业务流程，系统提供的价值可大可小，无论大小均是用例。
七、用例的命名。用例命名采用"动宾结构"，宾语前可以加定语，把一句话的主语砍掉，剩下的可以做用例的名字。
常见错误：踏实研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样的系统用例是不会骗人的。
一、把步骤当作用例。Include（包含）关系的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个大用例Include一个小用例。
二、CRUD问题。把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字或者把四种操作合并称为“XX管理”。
三、玩弄“复用”：用例的执行者不同，背后的涉众利益也有差别，不能简单的合并复用为某一个操作。
四、多个主执行者指向同一个用例。如果用例图已完成，对于这种错误的修改，可以通过泛化出抽象的执行者或者分成几个不同的用例的方法来修改。后一种更常见。
五、玩弄”层次“。切勿偷换"研究对象"，也切勿”把愿景当系统功能“。
六、玩弄”子系统“：用例很多时可以将用例分包，但用例包是在系统的外部对系统功能所做的划分，而子系统则是根据内部部件的耦合和内聚切割得到。
七：模糊的价值：系统往往无法承诺执行者预期的价值时，则该价值不是执行者的用例。主执行者执行用例时，若是需要辅执行者提供实时的帮助后才能进行，则用例正确，否则用例错误。
关于“XX管理”的用例：这种用例无法从业务流程中映射，但系统需要它们来支撑。也只有对于这种支撑的管理基本数据的用例，才用“XX管理”来打扫战场。"XX管理"这样的用例往往是给管理员管理基本数据用的，而且都是千篇一律。
软件工程的“底层”：怎样才能使这段代码更容易维护和扩展？这段代码达到的功能和性能对涉众意味着什么？
2). 系统用例规约：也就是以用例方式组织的需求规约，我们需要通过书写用例规约把用例背后封装的各种相关需求表达出来，并用类图展示用例的各项内容。
用例包含的内容：
a. 前置条件和后置条件：用例通过前置条件、后置条件以契约的形式表达需求。可以想象成：在满足前置条件的开始，按照说明的路径步骤走，就能达到后置条件。
后置条件分类：最小后置和成功后置。最小后置指在用例失败的情况下也要满足的约束，而成功后置指用例成功时系统需要满足的约束。