在上一篇文章，通过用例了解系统设计范围中，我们提到了一个概念：最外层用例，同时也描述了建立最外层用例的好处。
这里给大家提供一个比较权威的最外层用例的建立方法。
声明：此部分内容摘自《编写有效用例》
1） 以一个用户目标最为开始
2） 提问“这个目标对主执行者AA（最好在外部）提供什么服务？”执行者AA是我们想要收集的用例的最终执行者。
3） 找出最外层设计范围S，使得AA仍然在S之外。给S命名。通常，我们能找到三个最外层设计范围
l 公司
l 组合软件系统
l 被设计的具体软件系统
4） 找出最终主执行者AA在设计范围S中的所有用户目标
5） 找出执行者AA对系统S具有的概要目标GG
6） 为执行者AA对系统S的目标GG编写概要用例。
即使在规模最大的系统中，通常也有4~5个这样的最高层用例，他们概括了3~4个最终主执行者AA的利益
l 对公司而言：客户
l 对组合软件系统而言：市场部
l 对软件系统本身而言：安全部
最外层用力对于在总体上将工作联系起来很有帮助，所以极力推荐。当然，最外层用例不能为开发组提供被创建系统的功能需求。
今天的内容还是接着上一篇：了解用例–用例编写的学习，建议不懂的朋友可以先了解一下
范围用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已完成的设计工作相区别。
一般可以采用4个工具来确定项目提供服务的范围：
- 构想陈述：汇集了全部需要讨论的内容，有助于首先决定哪些东西在范围内，哪些东西在范围外。
- 设计范围图
- “内/外”列表
- 执行者-目标列表
这四个工具的形式或者是图，或者是文档，或者是表格。
稍后会提供表格样式给大家参考。
通过以上工具可以完整的了解系统提供功能的范围，从而保证系统或功能所提供的服务是最有效，没有浪费或重叠。
用例的范围
每一个功能及情景的描述都存在一个范围： 比如QQ的QQshow，用户所有的操作只会出现在QQshow这个系统中，不会影响到其他模块，只有当保存形象并关联的时候，才会给其他系统提供数据进行展示。
举例：为一个新的服务/系统开发前所做的准备应该包括哪些流程？
- 确定系统提供的功能及用户目标： 首先通过以上工具，对系统的服务及功能进行讨论及描述，最终确立这个系统所要提供的全部功能，保证功能的有效性及高效性，没有“鸡肋”功能！
- 编写业务用例及概述级别的系统用例：业务用例是用来描述这个服务在公司（即线下）所需要走的流程，比如业务员与客户的接触，遇到问题客服的应对，需要有财务参与的涉及到费用的流程；系统用例最好的程度是撰写一个最外层用例，用来确保每一个子功能点都被描述进来不被忽视，同时减少花费在细节设计中的时间。
- 最外层用例：通常，一个用例总可以找到一个更广的设计范围，而主执行者仍然处于这个范围之外。如果不断扩大该范围，可以找到一个临界点，一旦越过这个临界点，主执行者就会被包含在范围之内，这个临界点就是最外层用例。
- 现在我们确定了系统功能的范围，确保了业务流程的合理并顺利，确认了整个系统提供的功能及流程已实现最终的收益或目标，我们开始从系统的最外层用例中细分每一个可扩展的环节，撰写功能点的子用例。
- 最终讨论确认每个用例，进入开发过程。
本篇结束
访问更多关于用例的文章
原创： 猪猪
转载请注明链接！谢谢
由于工作需要，javascript学习暂时搁置，先进行用例编写的学习。有空会继续学习javascript。
用例这个概念最开始接触是由于了解UML，开始了解和赞叹用例的强大。再加上现在工作的需要，开始集中精力学习用例。
今天第一篇：了解用例
1. 什么是用例？用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。通俗点讲，用例可以作为系统需求交付给技术，同时可以用用例来衡量及测试最终的产品功能进行验收。
而为了不同水平程度的人交流及理解用例的方便性，首选用例格式应该是文本方式。
2. 用例的作用：
用例可以激发项目组针对系统的讨论;
可以用来记录实际需求；
可以记录一个功能点需求；
可以记录一个组织的业务过程；
3. 用例需要注意的几点：
一个编写良好的用例应该具有良好的可读性，这里可以借用UML里面的一个概念“可驳倒性”；
用例是由多个句子组成，所有句子都采用同一种语法形式——一个简单的执行步骤；
4. 用例编写者必须掌握而且时刻提醒自己的三个概念：
范围： 真正被讨论的系统是什么
主执行者： 谁有要实现的目标？
层次： 目标的层次是高还是低？
用例需要具备的组成部分：
执行者： 任何具有行为的人或物
范围： 界定被讨论的系统行为的契约；
前置条件和保证： 在用例执行之前和之后必须满足的条件；
主成功场景： 一切顺利的情况；
扩展： 场景执行过程中的不同情况；
部分内容参考《编写有效用例》