创建USE CASE的原则
用例是短文
用例可以是一个场景，包括动作和互交。
用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。
用例里不要有系统设计
用例里不要有界面设计
用例里不要有特性列表
用例里不要有测试
用例应该描述行为需求
用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。
用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。
use case评价标准
是否每个Use Case 都包括至少一个actor？
是否每个Use Case 都独立于其他Use Case？
是否每个Use Case 都有一个简单的行为或事件流？
是否每个Use Case 都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。
用户是否容易理解Use Case 的名称和描述。
使用 use case 十大误区
1． 系统的boundary 没有定义或经常改变；
2． 从系统观点而不是actor观点来定义Use Case；
3． Actor的名称不一致；
4． Use Case 定义过多；
5． Use Case 和actor之间的关系象蜘蛛网一样错综复杂；
6． Use Case的说明太长；
7． Use Case的说明不清楚；
8． Use Case没有正确的描述功能需求；
9． 用户无法理解Use Case；
10． Use Case 无法正常结束。
不要将Use Case 说明书与用户接口设计相混淆
转自:
http://www.itisedu.com/phrase/200603042249305.html