实践是最好的老师
对于一个概念，知道它是什么有可能很简单，但是知道如何正确的运用它就不是一件很容易的事情，用例就是这样。
用例可以从用例图、用例简述、用例规约和用例实现几部分。
用例图描述了软件系统为用户或者外部系统提供的服务，用例图最重要的元素是参与者和用例，参与者是与系统交互的角色或系统，它既可以是使用系统的用户，也可以是和系统有直接交互关系的系统。用例描述了系统能为外部参与者提供的功能，用例的名称应该从参与者的角度进行描述，并以动词开头，这样可以通过‘读图’清晰的获得用例图的语义。
用例图通过确定与本系统交互的角色或外部系统、描述系统必须提供的功能的方式，清晰的界定了系统的功能范围。
用例简述是指通过简单的文字对用例的功能进行描述，一般而言，用例简述应该包含成功场景的简单描述。
用例简述是一项非常轻便的技术，很多敏捷方法都通过类似用例简述的技术捕获和交流需求，如极限编程中的用户故事卡、特征驱动开发中的特征等。
如果想对系统的功能进行范而不深的描述，可以采用‘用例图+用例简述’的方式。
用例规约是对用例的详细描述，一般包括简要说明、主事件流、备选事件流、前置条件、后置条件和优先级等。用例规约主要目的是界定软件系统的行为需求。
使用用例规约时应该注意的事项：
1． 用例规约是以用户未中心展开的。
2． 用了规约不仅关注正常流程，也关注异常流程。
3． 很多需求是不需要进行用例规约的，直接使用用例简述就可以了。
4． 不要拘泥于用例规约的格式，可以根据具体需求，添加或者删减。
5． 用例规约中不应该包括用户界面原型，两者可以是平行进行的。
用例实现是从功能需求向设计方案过度的纽带，通过分析一组关键用例的用例实现，可以获得未来系统的理想化的职责模型，它的重点是识别组成软件系统的高级职责块、规划它们之间的关系，这个职责模型是规划架构机制、满足高质量属性要求的武器。
要开发一个软件系统，不同层次的涉众提出需求时所站的立场不同，层次也不同。用户方的决策层会站在组织高度，从业务层面提出需求；用户更关心自己的工作如何完成、需要哪些功能来进行辅助；而最后要开发的，是实实在在的软件要提供的行为。这就是需求的3个层次：
- 业务需求：组织要达到的目标。
- 用户需求：用户使用系统来做什么。
- 行为需求：开发人员需要实现什么。
用例图从总体上反映了用户需求，而用例简述和用例分别是行为需求的简化描述和详细描述，用例实现则属于设计范畴。
用例图作为功能需求的范而不深的总体描述，是比较稳定的。
用例简述中不涉及细节，因此也是比较稳定的。
用例规约通过交互序列的方式描述功能需求，受需求变化影响比较大。
参考文献
《软件架构设计》 温昱