一、用例的相关概念(what)
用例是文本形式的情节描述,用以说明某参与者使用系统以实现某些目标。
注意:用例不是图形,而是文本。很多初学者认为用例就是用例图
用例是对一组动作序列(其中包括它的变体)的描述,系统执行该动作序列来为参与者产生一个可观察的结果值。这个动作序列就是业务工作流程,项目的涉众都能理解,基于它所进行的讨论,能较好地完善这个序列。
用例特别适用于描述用户的功能性需求,它描述的是一个系统做什么(what),而不是说明怎么做(how)。用例不关心系统设计,编写用例的最昂贵的错误包括太多细节和用户界面说明,使得用例变长,难以阅读。
二、为什么要使用用例(why)
1. 有利于开发者与用户之间进行交流。编写用例的难度比较低,开发者和用户都可以编写,而且可以基于用例进行交流。(很多项目就是因为需求不清楚,最后导致失败)
2. 用例强调了用户的目标和观点。用例中提出的问题是“谁使用系统、他们使用的典型场景是什么、他们的目标是什么”。所以用例要比待开发系统的特性清单更强调以客户为中心。
三、怎么样使用用例(how)
用例的三种形式:
1. 摘要:简介的一段式概要,通常用于主成功场景,一般在早期需求分析中使用。
2. 非正式:用几个段落覆盖不同场景,一般在早期需求分析中使用。
3. 详述:详细编写所有步骤及各种变化,同时具有补充部分,在需求细化过程中使用。
详述的内容及各部分的解释是:
1. 范围:界定所要设计的系统,比如是将企业和收款系统作为当前范围,还是只是将收款系统作为当前范围
2. 级别:主要分为用户目标级别或子功能级别,用户目标级别是通常用的级别。两者的主要区别是当若干常规用户共享重复的子步骤时,将其分离出来。
3. 主要参与者:调用系统服务来完成目标的主要参与者。
4. 涉众及其关注点列表:界定了系统必须要做的工作。该项回答了以下问题:用例应该包含什么,答案是:用例应该包含满足所有涉众关注点的事物。在编写用例其余部分之前就确定涉众及其关注点,能够让我们更加清楚地了解详细的系统职责。
5. 前置条件和成功保证:前置条件:给出在用例中场景开始之前必须永远为真的条件。成功保证:给出用例成功结束后必须为真的事物。
6. 主成功场景和步骤(或基本流程):描述了满足涉众关注点的典型成功路径。它通常不包括任何或分支。
7. 扩展(或替代流程):描述了其他所有场景或分支,包括成功和失败路径,
8. 特殊需求:如果有与用例相关的非功能性需求、质量属性或约束,那么应该将其写入用例。其中包含需要考虑和必须包含在内的质量属性(如性能、可靠性和可用性)和设计约束(通常对于I/O设备)。
9. 技术和数据变元表:描述技术变元,这些变元是关于必须如何实现系统的,而非实现系统的哪些功能。比如说pos系统的输入必须是读卡器和键盘。
至于使用用例图和活动图在这里暂时不做介绍