需求是什么？需求是系统必须提供的能力和必须遵从的条件。

　　用例是什么？用例是文本形式的情节描述，广泛用于需求的发现和记录工作中。用例不是图形，而是文本。用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。用例我们可以理解为更为一层抽象一层的概念，我们可以理解用例是一组相关的成功和失败的场景集合。场景是什么？是参与者和系统之间的一系列特定的活动和交互，也称为用例实例。场景是用例的一条执行路径或者一个特定的情节。所以我们可以把用例看做是这些失败或者成功场景背后的抽象。

　　那么为什么使用用例呢？用例的价值在哪呢？用例的价值之一强调了用户的目标和观点，其次用例为我们后续制品的产生提供了必备的输入。

　　需求我们认为的可以分为很多种，例如功能性、行为性、可支持性、可靠性。当然这只是认为的这么划分，那么用例是什么呢，用例为我们发现需求提供了一种工具和一种途径，所以用例是需求，完成用例的同时是在完成需求的明确和文本描述。

　　我们是不是有一些参考准则来发现用例呢，既然用例失败和成功场景（参与者和系统之间一系列的交互活动）的背后的抽象和归类，我们是不是有指导思想来指导我们对这些所有的场景进行归类然后寻找背后共同的抽象呢？当然有

　　1、准则：以无用户界面的约束的本质风格编写用例

　　一本质风格编写用例，摒除用户界面并且关注参与者的意图，言下之意有两点：不要去考虑系统的界面，不要让系统的界面要实现什么功能这种方式来编写用例，这点不应该考虑，我们应高从参与者的意图出发，他的目标是什么？

　　2、编写简洁的用例？

　　3、编写黑盒用例？

　　人们可以规定系统规定系统必须做什么(行为和功能性需求)，而不必决定系统如何去做。实际上“分析”和“设计”的区别在于“什么”和“如何”的差异，但是中间有个粒度的问题，是如何权衡的问题，这是经验范围内的事情了，不再我们讨论范围之内。我们的任何的学习只是提供一种指导思想，这中间中庸的权衡是经验范围的事情，所以这个决定是仁者见仁、智者见智了，属于经验范围的事情了，像维特斯根坦，他不也说了他所说的对象属于经验范围的事情。

　　4、采用参与者和参与者的目标的视点

　　用例反映了需求，反映了用户的目标和观点，所以从参与者和用户的角度出发是对的，参与者和用户并不一定是人，记住这点。用例是一组用例实例，每个用例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。用例的名称应该反映了用户的目标。用户的目标一般都具有可量化的结果。

　　如何发现用例

　　选择系统的边界--寻找主要参与者--确定参与者的目标--定义满足用户目标的用例。

　　有时候系统的边界如果本身并不是很好找的，我们可以通过寻找主要参与者来帮助我们确定系统的边界，不要盲目的写下任何的目标，要知道用例是需求，价值之一是反映用户的观点，所以先先先，我们学会去发现主要的参与者，然后根据参与者来去定目标。那我们怎么去发现主要的参与者呢？我的思路，我们的指导思想呢？我们还是利用那句话，问题驱动的方式，有哪些问题可以帮助我们找到主要的参与者呢？

　　1、谁来启动和停止系统？

　　2、谁来完成用户管理和安全管理？

　　3、谁来完成系统管理？

　　4、“时间”是参与者吗？因为系统要响应时间事件而完成某些活动。

　　5、系统失败时是否存在监控进程将系统重新启动？

　　6、软件升级是如何处理的？是“推”模式还是“拉”模式

　　7、除了人作为主要参与者外，还有其他外部的软件或者自动机器系统调用该系统的服务吗？

　　8、谁来考察系统活动或者性能？

　　9、谁来考察日志？是否可以远程检索？

　　10、系统发生错误或者故障时应通知谁？

　　老板测试（是不是有核心价值）、业务基本过程测试（不能跨越多个会话）、规模测试(不能是单独的一小步)