目录
2.1 理解需求
需求就是系统(更广义的说法是项目)必须提供的能力和必须遵从的条件
例:用户能够搜索所有的数据集合或者从中选择一部分进行搜索
许多需求是非功能性的,只能够描述系统的属性或者系统环境的属性。 例:系统能够在1分钟内处理100次交易。
缩写FURPS 描述了需求的主要类别:
2.2
基于用例的需求描述
m
1.
参与者、场景、用例
Ø
参与者(
actor
):是某些具有行为的事物,可以是人(由角色标识)、计算机系统或是组织。
Ø
场景(
scenario
):是参与者和系统之间特定的活动和交互,也称为用例实例(
use case instance
)。场景是使用系统的一个特定情节或用例的一条执行路径。
什么是用例
Ø
“一组用例的实例,其中每个实例都是系统执行的一系列活动,这些活动产生了对每个参与者而言可观察的返回值”
Ø
描述了从参与者角度看系统(黑盒子)做了什么
Ø
用例模型本身不是面向对象建模技术
m
2.
用例的好处
Ø
从用户的角度获取操作性需求
Ø
对系统的功能进行清晰而一致的描述
Ø
系统测试的基础
Ø
提供了从功能需求跟踪到系统中真正的类和操作的能力
m
3.
理解用例
Ø
用例是需求,而且主要是功能需求。
Ø
用例是需求,而不是功能或者特征列表。
Ø
用例是文档,而不是图,用例建模主要是写文字,而
不是画图。
Ø
用例
Use Case:
一组相关的成功和失败场景集合,用
来描述参与者如何使用系统实现其目标
m
4.
用例的表示法
Ø
摘要:简介描述用例,通常只给出主成功场景。
Ø
非正式:用若干非正式段落来描述用例,通常给出多个不同场景。
Ø
详述:详细描述用例,通常给出所有的步骤及场景,并给出前置和后置条件等细节。
m
绪言
Ø
范围:系统用例,业务用例
Ø
级别:用户目标级别,子功能级别(可被许多用例重复使用的)
Ø
主要角色
Ø
涉众
Ø
前置条件和后置条件
m
主成功场景和步骤(或基本流程)
m
扩展(或替代流程)
m
特殊需求:非功能性需求,质量属性或约束
m
技术和数据变元表:用户对如何实现系统的要求
m
范围:业务用例
m
级别:用户目标
m
主要参与者:学生
m
涉众及其关注点:
Ø
—
学生:希望能网上选课,并可以准确获知待选课程和待修学分,并快速完成选课。
Ø
—
教务管理员:希望准确记录每个学生的选课情况,并能自动筛选统计选修每门课程人数,方便进行课程班的设立和授课教师的安排。有较强的容错能力。
Ø
—
教师:希望方便准确查询选课学生的名单。
m
前置条件:教务管理员已经设立好待选课程,并开发网上选课。
m
后置条件:记录学生的选课信息,更新选课数据库。
m
主成功场景
(
基本流程
)
:
Ø
1.
学生输入学生证号以及个人密码;
Ø
2.
系统识别学生身份的有效性;
Ø
3.
系统对学生进行注册识别;
Ø
4.
系统显示学生本学期的待选课程
Ø
5.
学生自己要上的课程并确认;
Ø
6.
退出时,系统给出所选课程列表及相应学分合计。
m
扩展(替代流程):
Ø
2a.
学生身份检查失败,提示重新输入(
3
次机会)。
Ø
3a.
注册识别失败,提示没有注册(尚未交学费)的学生不能选课。
Ø
5b.
选择课程确认失败,所选几门课程中在上课时间上发生冲突时,系统提示重选。
m
特殊要求:
Ø
1.
能同时允许
2000
以上人同时进行选课;
Ø
2.
系统应具备较强的数据恢复能力;
Ø
3.
选课期间每个
2
小时数据备份一次
m
技术和数据变元表:
Ø
1.
支持网上选课。
Ø
2.
能自动进行上课时间是否冲突以及选课学分是否满足要求的判断。
m
发生频率:
Ø
每学期末发生频率高约
20000
人次,其他时间不选课。
m
5.
用例的作用
Ø
可作为计划的基础。可以估算实现每个用例所需的时间和资源
Ø
可用来捕获功能需求。它们是分析、设计和实现的基础
Ø
可作为软件测试的基础。测试人员可将那些在用例中描述的消息序列以及动作序列作为测试脚本来验证系统的功能
Ø
可作为文档的基础
2.3 用例的获取
m
1.
主要过程
Ø
(
1
)选择系统边界
Ø
(
2
)寻找参与者
Ø
(
3
)确定每个参与者的目标
Ø
(
4
)定义用例
m
2.
确定系统边界
可能的系统:
Ø
整个组织:如一个企业;
Ø
一个组织的某个部门:如企业的财务处;
Ø
计算机系统的硬件
/
软件边界:如企业的进、销、存计算机管理系统。
系统边界作用:
Ø
定义系统问题域的目标、任务、规模及系统提供的功能。
Ø
系统中所有元素与系统外事物的分界线
m
3.
寻找参与者
参与者是与系统交换数据的实体。参与者可以是用户,外部的硬件或者另外一个系统。
m
1
)参与者的识别。可通过以下问题进行寻找:
Ø
系统的主要客户是谁?
Ø
谁从该系统中获取信息?
Ø
谁向系统中提供信息?
Ø
谁来安装系统?
Ø
谁来操作系统?
Ø
谁来关闭系统?
Ø
在预定的时刻,是否有事件自动发生?
Ø
谁使用或者删除系统中的信息?
Ø
系统从何处获得信息?
m
2
)参与者的分类
Ø
主要参与者:从系统获取信息的用户,是执行系统主要功能的参与者。(何种服务、业务需求、时间、性能及接口等)
Ø
次要参与者:仅仅给用例提供某种服务。(何种服务、时间、性能、接口等)
m
3
)参与者的职责
Ø
启动者:何种事件、时间因素、接口
Ø
服务者:何种服务、接口、时间、数据量等
Ø
接收者:何种信息、接口
Ø
辅助者:何种服务、接口
m
4
)参与者和系统边界的关系
![](https://img-blog.csdn.net/20171201131427442?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveW9uZ2NoYW9jc2Ru/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
m
5
)参与者的规约模板
什么是用例
不是画图。
来描述参与者如何使用系统实现其目标
2.3 用例的获取
可能的系统:
系统边界作用:
参与者是与系统交换数据的实体。参与者可以是用户,外部的硬件或者另外一个系统。
一般而言,为每一个用户目标定义用例
整个系统就只有一个用例!!!
系统中可能有成百上千个用例!!!
根据用例产生的阶段,可把用例分为业务用例和系统用例。
2.4 用例图
用例图是表达用例和参与者及其之间关系的载体。
由主题(subject)、
参与者、用例、
关系组成。
参与者类和用例类之间的关系是关联关系,它指明了参与者类和包含用例类的系统之间的通信关系
1)包含关系(include)
一个用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为做为自身行为的一部分,这被称作包含关系。
扩展关系是从扩展用例到基本用例的关系,它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。以下情况,可使用扩展用例:
a.表明用例的某一部分是可选的系统行为;
b.表明只在特定条件(如例外条件)下才执行的分支流;
c.表明可能有一组行为段,其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
3)泛化关系(Generalization)
一个用例也可以被特别列举为一个或多个子用例,这种关系称作泛化关系:
参与者之间可以存在泛化关系。
给定一个系统,会有一些事物存在与它的内部,一些存在与外部。存在于系统内部的事物的职责是完成系统外部事物期望系统提供的行为。
所有存在与系统外部并于系统进行交互的事物构成了该系统的语境(context)。语境定义了系统存在的环境。
对系统语境建模,所强调的是围绕在系统周围的参与者。
语境建模策略
需求是系统的设计特征、特性或行为。陈述系统的需求,相当于陈述系统外部的事物与系统之间建立的一份合约,该合约声明了希望系统做什么事。大多数情况下,并不关心系统怎么做。
需求建模策略
一个结构良好的用例图,应满足一下要求:
绘制用例图的策略