谈到用例，可能很多人比较熟悉，但是也有不少人不会真正的使用。接下来根据一段时间的累积和看书了解，总结如下，难免有误，还望批评指正，共同进步。
用例是需求阶段的产物，是为了帮助获取和挖掘系统需求用的。
首先，我们看什么是需求，需求是系统或项目必须提供的能力和必须遵从的条件（参考文献：JBR99）。需求管理不主张采用瀑布
的观点，即在编程之前项目的第一个阶段就试图完全定义和固化需求，一般更推崇一种使用系统地方法来寻找、记录、组织和跟踪
系统不断变化的需求（RUP）。传统的瀑布方法中，试图于开发之前定义所谓的‘完整’的需求或规格说明是不现实的，即使定义
了也可能是不完整的。需求分析最大的挑战是寻找、沟通和记住什么是真正需要的。
进化式需求和瀑布式需求
瀑布模型在20世纪60-70年代被运用于软件项目的早期进行需求分析，被认为是普遍的和有效的，但从80年代开始，这种方法逐渐
证明是拙劣的，并导致了大量项目的失败。根源是将软件项目和大规模制造业项目视为同等。而后者是可预测的，且具有低变更率
。但是软件属于具有高变更率的，具有大量的新奇事物，需要大量的发现和探索。据统计，软件项目的平均需求变更率为25%，因
此，任何试图在一开始就固定或定义所有需求的方法都具有本质上的缺陷。这里引用[Thomas01]对1027个软件项目失败因素的研究
，尝试瀑布实践是导致这些项目的失败的主因。其中82%的项目都将其列为头等问题。结论是任何假设需求一旦形成文档后就不会
再有显著变更的方法具有本质上的缺陷，花费大量时间和工作量以便最大程度的定义需求是不合适的。一种折中的方法是：结合早
期时间定量的迭代开发，进行迭代和进化式需求分析，并且引入频繁的涉众参与、评估和对局部结果的反馈。
需求的种类：
在UP中需求按照"FURPS+"模型进行分类，其含义如下：
功能性：特性、功能、安全性
可用性：人性化因素、帮助、文档
可靠性：故障频率、可恢复性、可预测性
性能：响应时间、吞吐量、准确性、有效性、资源利用率
可支持性：适应性、可维护性、国际化、可配置性
+是指一些辅助性的和次要的因素。比如：实现，接口，操作，包装，授权等
如何组织需求：
UP提供的可选制品，主要包括：
用例模型：一组使用系统地典型场景。
补充性规格说明：基本上是用例之外的所有内容。
词汇表：以简单的形式定义重要的术语。
业务规则：通常描述许多应用应该遵守的规则。
等
用例：
用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。用例会影响软件项目的众多方面，包括OOAD，同时它也是后续
一系列后继过程的输入。
注意：用例不是图形，而是文本。读者要能区分用例和用例图。用例的本质是通过编写使用系统实现用户目标的情节来发现和记录功能性需求。
参与者、场景和用例
参与者是某些具有行为的事务，可以是人、计算机系统或组织。
场景是参与者和系统之间的一系列特定的活动和交互，也称为用例实例。是使用系统的一个特定情节或用例的一条执行路径。
例如：使用现金购买商品，使用信用卡购买，或金额不够购买不成功等都是场景。
用例和用例模型
用例是文本文档，而非图形；用例建模式主要是编写文本的活动，而非制图。
用例模型可以包含用例图。
用例的动机：
在软件项目中，缺少用户参与是项目失败的主要原因。任何有利于用户的参与的方法都是值得的。用例就是这样一种优秀的方法，
使用户或领域专家自己编写用例成为可能。
用例的另一个价值是强调用户的目标和观点。
如：谁使用系统？他们使用系统地典型场景是什么？目的是什么？
用例就是需求
主要是说明系统如何工作的功能性或行为性需求。在统一过程和其他现代方法中，用例被推荐作为发现和定义需求的核心机制。
请记住：用例是真正的需求（尽管不是所有的需求）。
参与者的三种类型：
主要参与者
协助参与者
幕后参与者
用例的三种常用形式：
摘要：简洁的一段式概要，一般使用在早期需求分析中，需要快速了解主题和范围，可能只需要几分钟编写。
非正式：非正式的段落格式，几个段落覆盖不同场景。
详述：详细编写所有步骤及各种变化。同时具有补充部分，如前置条件和成功保证等。
编写用例的一些准则
准则：以无用户界面约束的本质风格编写用例 ---以本质风格编写用例，避免具体风格的用例。
准则：编写简洁的用例 ---你不喜欢阅读有大量的文字描述的文档吧。。。
准则：编写黑盒用例 ---分析和设计的区别就在于“什么”和“如何”的差异。
准则：采用参与者和参与者目标的视点 ---用例的核心
准则：如何发现用例
1。选择系统边界
2。寻找主要参与者
3。确定主要参与者的目标
4。定义满足用户目标的用例
用例名称应该以动词开头，动词+名次短语的形式。
用例图：
UML提供了用例图表示法，用来描述用例名称和参与者及其之间的关系。用例图和用例关系在编写用例的工作中是次要的，用例是文本文档，编写用例意味着编写文本。
