标签：需求 一个 元素 系统 用例 UML 参与者 描述
-
定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。(定义系统范围、获取功能性需求)
-
一个场景就是一个用例的实例
-
一个完整的用例由参与者，前置条件，场景，后置条件构成。
-
用例的特征
-
用例是相对独立的：不能达到参与者的完整愿望不能称为用例。
-
用例的执行结果对参与者是可观测和有意义的(PS:如一个后台进程监控参与者在系统里的操作，并在参与者删除数据之前执行备份操作。虽然他是系统的一个必须组成部分，但它在需求阶段却不应该做为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，它应该作为系统需求在补充规约中定义而不是一个用户需求)
-
事情必须由参与者发起，不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。
-
用例必须由动宾短语形式出现。
-
一个用例就是一个需求单元，分析单元，设计单元，开发单元，测试单元，甚至部署单元。
-
用例和功能的误区
-
功能是计算机术语，用来描述计算机的而非定义需求的术语。
-
功能实际描述的是输入-计算-输出，典型的面向过程分析模式，因此把用例当作功能点的做法实际是在做面向过程的分析。
-
本质上来说功能和用例完全不同。
-
事物是什么（结构性观点，即客观存在）？事物能做什么（功能性观点，事物的可利用价值，不能够说明事物在某种情形下的真正价值，也就是缺乏上下文环境）？人们能够用这个事物做什么（使用者观点，说明事物对于使用者的意义）？
-
对于还不存在的事物，如软件，不能从结构观点去描述，也不能从功能观点去描述。
-
总结
-
功能是脱离使用者的愿望而存在的。
-
供能是孤立的，给一个输入，通过计算就有一个固定的输出，只要按下开关灯就亮。用例是系统性的，描述谁在什么情况下通过什么方式开灯结果是什么。
-
如果非要从功能的角度解释用例，用例可理解为一系列“功能”的组合。UML没有功能这个词。
-
业务用例
-
专门用于需求阶段的业务建模
-
业务范围不等于需求，软件需求真正的来源是系统范围，也就是系统模型，业务模型是系统模型的最重要输入。
-
不再计算机中实现的业务就可以不进入系统范围，也就是可以不把它作为一个需求。
-
业务用例实现
-
用于需求阶段的业务建模，为业务领域建立模型采用这种版型。
-
就是一个业务用例的实现，一个用例可以有多种实现方式。
-
用例实现是联系模型和系统实现之间的桥梁。
-
用例粒度
-
业务建模阶段：每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。
-
概念建模阶段：每个用例能描述一个完整的事件流为宜。可以理解为一个用例描述一项完整业务中的一个步骤。
-
系统建模阶段：能够描述操作者与计算机的一次完整交互为宜。（在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。一个系统的业务用例定义在10到50个之间，总体原则是同一个需求阶段，所有的用例的粒度应该是同一个量级。）
标签：需求,
一个,
元素,
系统,
用例,
UML,
参与者,
描述
From： https://www.cnblogs.com/mach-arch/p/16924736.html