转：
编写有效用例笔记-第一章 引言
http://tommwq.tech/blog/2020/11/16/212
用例描述了系统（System under Discussion, SuD）对利益相关方的请求所作出的反应。发出请求的利益相关方也叫做主执行者（primary actor）。主执行者和系统进行交互，以达成某个业务目标，获得某些利益。根据执行者的请求和请求涉及的条件，系统将执行不同的行为序列。这样的行为序列叫做场景（scenario）。用例是多个场景的集合。编写用例的目标就是让相关方的利益得到适当的保护。这里提到的系统，不仅仅指软件系统。任何具有行为的东西，比如一家公司，也可以是系统。对于这种情况，用例锁描述的，就是这家公司的业务过程。
用例可以用流程图、UML用例图、伪代码等等方式来表达。但文本是用例最好的表达方式。使用文本进行表达时，不需要处理用例逻辑之外的东西（比如画图），增删修改也非常方便。优秀的用例需要具备良好的可读性。要达到这一点，在编写用例的时候要时刻注意3个概念：范围（scope）、主执行者和层次（level）。范围确定了要讨论的系统是什么，主执行者确定了谁有业务目标，层次确定了目标层次是高还是低。这三个概念应当贯穿于用例和用例中的每一个句子。
| 执行者 | actor | 任何具有特定行为的人或物。 |
| 项目相关人员 | stakeholder | 对被讨论系统的行为有特定兴趣的人或物。 |
| 主执行者 | primary actor | 启动与被讨论系统的一次交互活动，从而达到某一目标的人或物。 |
| 用例 | use case | 规定被讨论系统行为的契约。 |
| 范围 | scope | 界定被讨论的系统。 |
| 前置条件和保证 | precondition and guarantee | 在用例执行之前和执行之后必须被满足的条件。 |
| 主成功场景 | main success scenario | 一切顺利的情况。 |
| 扩展 | extension | 场景执行过程中出现的不同情况。 |
用例的层次分为用户目标（user-goal）和概要（summary）目标。通过一个次处理可以完成的目标是用户目标，需要多次处理才能完成的目标是概念目标。
用例的用途有很多，包括：
- 用来描述业务过程。
- 用来讨论未来系统的业务问题。
- 作为系统的功能性需求描述。
- 将系统设计结果文档化。
根据用途不同，用例的编写可以较为随意，或者比较详细。如果拿用例来记录需求，有两点必须要注意：一、用例就是是需求，不需要将用例转换为其他需求方式。二、用例不是全部的需求。用例只记录需求中关于系统行为的部分，用例不会详细的描述外部接口、数据格式、业务规则、词汇表、性能指标等。
用例的价值主要体现在两点。首先，用例可以用来评估项目的成本和复杂度，并指导工作方向。其次，用例记录了大量的异常情况，可以提高开发速度和软件质量。
按照从粗到细的顺序，用例可以分为4中粒度：
- 执行者和目标。用例列出系统所支持的执行者及目标。
- 用例概述和主成功场景。描述主成功场景。
- 失败情况。讨论所有可能发生的失败情况。
- 失败情况处理。讨论如果处理这些失败情况。
系统使用叙述（usage narrative）是一个具体的使用系统的例子，用于帮助设想系统的行为。系统使用叙述描述了一个虚构但具体的使用者和系统交互的完整过程，并试图捕获使用者的心理状态：他为什么想要这么做。叙述不是用例，但为用例进行了铺垫。叙述和用例的另一个区别是，叙述中执行者的名字是具体的，用例中执行者的名称是抽象的。
转：
编写有效用例笔记-第一章 引言
标签：讨论,场景,系统,执行者,目标,用例,第一章,引言 来源： https://www.cnblogs.com/wangtcc/p/14728774.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。