需求建模( I)
建模和分析( I)
通用的建模问题
建模目的、组织
和非功能需求
建模的动机
? 主要执行官
? 航班如果取消,VIP首先要被升仓
? 打折机票应该向政治家们提供,因为
他们制订影响航线的决定
? 关于常旅客的信息不能透露给外面的
客户
? 主要的保密方面的官员
? 飞机运载的行包数与机上乘客的名单
相符合
? 旅客名单不应该向外界公开
? 旅客应该只能检票一次
? 旅行代理
? 代理负责预订的维持和取消
? 一个代理提供的票有不同的票价,需
要和航线销售部门协商
? 餐饮经理
? 机上带的食物由乘坐特定的仓位的旅
客的数量决定
? 乘坐飞机的预计的旅客数必须在起飞
以前 24小时给出
? 要求特殊食物的旅客必须在起飞前 24
小时指明他们的要求
? 机票销售经理
? 机票只有在付费的时候才出
? 对某种票价,机票可以一直保留并不
需要确认
? 当一种折扣票被预订,正常的提前预
订的需求不再有效
? 所有的票都要有涉及条款和出票条件
的背书
想象一下我们已经与一些投入者进行过交谈 …
我们怎么样从这里产生一个被一致接受的规格说明呢? …
建模有什么用?
? 建模能指导抽取
? 建模过程帮助你想出要问什么问题吗?
? 建模过程帮助将隐含的需求显式化吗?
? 即,它帮助你问正确的问题吗?
? 建模能提供对进展的度量
? 模型的完整性蕴涵了抽取的完整性吗?
? 即,如果我们填好了模型的每个部分,我们就做
完了吗?
建模有什么用?
? 建模能帮助发现问题
? 模型中的不一致性揭示什么有趣的事吗?
? 比如:不一致性可能对应为矛盾的或不可行的需求
? 比如:不一致性可能意味着术语、范围等的混乱
? 比如:不一致性可能揭示投入者之间的不同意见
? 建模能帮助我们检查我们对问题的理解
? 我们能检测模型具有我们期望的特性吗?
? 我们能根据模型的推理去理解它的结论吗?
? 我们能模拟这个模型,以便帮助我们将需求可视化 /检验需求的
有效性吗?
建模技术分类
? 为企业建模(本讲的内容)
? 目标和目的
? 组织结构
? 活动、过程、生产
? 主体和工作角色
? 为功能需求建模
? 结构视点(数据的结构)
? 行为视点
? 时间需求
? 为非功能需求建模
? 产品需求
? 过程需求
? 外部需求
信息建模,ERD
组织建模,I*,SSM,ISAC
目标建模,KAOS,CREWS
结构化分析,SADT,SSADM,JSD
面向对象分析:
OOA,OOSE,OMT,UML
形式化方法,Z,VDM
质量交易,QFD,win-win
特殊的非功能需求:
时间 Petri网(性能)
任务模型(可用性)
概率 MTTF( 可靠性)
企业建模方法:进一步分类
? 软系统方法
? 涉及整个组织,从各个不同视点分析问题
? 产生不止规格说明,还包括:组织结构修改计划、任务结构、目的、以及对环
境的理解
? 例子,SSM,ISAC
? 基于知识的方法
? 利用知识表示框架建立可执行的领域模型,包括静态和动态方面
? 例子,RML,Requirements Apprentice,Nature
? 目的论 方法
? 需求实际上就是目标,所以要为目标层次建模
? 关心“为什么”的问题,而不是,什么 /如何, 的问题
? 用 情景 作为 目标怎样能够被满足的具体例子
? 例子,KAOS,I*,CREWS,…
模型的形式
? 自然语言形式
? 绝对的表达能力和灵活性
? 非常难以捕获模型的语义
? 用于需求抽取,或为便于沟通进行模型的标记等方面比较好
? 半形式化表示(如:图,表,结构化英语等)
? 捕获结构和一定的语义
? 可以实施一定的推理,一致性检查,模拟,等等
? 比如:图、表、结构化英语、等等
? 形式化表示
? 非常精确的语义,外延推理成为可能
? 离开应用领域还有很长的距离
? 注意:需求形式化主要是为了认知的考虑,因此与计算机科学的形式化
有点不同












模型的特征
? 独立于实现
? 模型不是数据的表示、数据的内
部组织、等
? 抽象
? 抽取根本的方面
? 比如,那些不经常变化的东西
? 形式性
? 无二义的语法
? 丰富的语义理论
? 可构造性
? 为了应付复杂性和规模,能够构
造模型的片段
? 构造性能支持沟通
? 容易分析
? 有能力分析出二义性、不完整
性和不一致性
? 可跟踪性
? 能够交叉索引元素
? 能够连结设计、实现、等
? 可执行性
? 能够模拟这个模型,以便将它
与现实进行比较
? 最小性
? 在模型框架中无概念的冗余
? 即,在如何表达什么事情上,
不需要进行额外的选择
建模第一步:元建模
?元模型要表达什么?
? 该模型关注什么问题?或者要捕获什么
现象?
? 对如何细化模型存在何种引导?
? 在模型上可以进行什么样的分析?
元模型决定需求关注点 事实
事件活动
承认修改
触发
关于领域的命题
使得应用领域中的事实
发生变化的活动
应用领域中
状态的改变
元模型决定需求关注点
? 关注的概念:事实、活动、事件
? 寻找领域的事实,并表示出来
? 寻找领域事件,并表示出来
? 寻找领域活动,并表示出来
? 建立联系:事实与事件、活动与事实、事
件与活动
? 验证约束是否满足
实体关系图
? EDR图
? 广泛用于信息建模
? 简单、容易使用
? 注意:这只是一种表示法,
而不是一种方法
? 被用在许多场景中
? 领域概念
? 在目标模型、情景等中涉
及的对象
? 系统中要表示的数据
? 对信息系统而言
? 元模型
实体关系图
? 关注点:
? 实体:演员、电影
? 实体由属性来描述
? 关系:演员 演 电影
? 关系的度:
? 一对一
? 一对多
? 多对多
实体1
属性
描述
关系 实体2
属性
描述
实体关系图
? 产生关系数据模型
? 比如,用三个表表示
? 演员表
? 电影表
? 演员 -电影表
演员
年龄
姓名
国籍
被选为
演员
电影生产者
发行
日期
导演 电影名
ISAC
? 信息系统工作和变
化分析( ISAC)
? 于 70年代在瑞典被
开发出来
? 强调用户、开发者
和倡议人之间的合

? 开发者的作用在于
辅助这个过程进行
? 适用于信息系统:
不适用于控制系统
? ISAC过程
? 变化分析
? 该组织想要什么?
? 该组织关于这个变化有多灵活?
? 活动研究
? 我们应该将哪个活动(重新)组织进信
息系统?
? 信息系统具有哪种优先级?
? 信息分析
? 每个信息都有哪种输入和输出?
? 每个信息系统上的数量需求是什么?
? 实现
? 我们用哪种技术来实现信息系统?
? 每个信息中哪个活动是手动的,哪个活
动是自动的?只是一些指导性的原则
软系统方法( SSM)
? 背景
? 70年代后期发展起来
? 理念:现实是社会构造的,因此需求不是客观的
? 适合的情景
? 问题情景是模糊的(不是结构化的),并且解决方案不是很
容易就搞清楚的
? 存在冲突:
? 计算机化的影响可能会是负面的(比如:新系统的引入会降低
生产率,由于它剥夺了雇员的动力)
? 计算机化的全面实施可能需要进行工作的彻底重构
软系统方法( SSM)
? 硬系统
? 人是问题的被动观察者
? 系统的不同元素之间有良定的关系
? 软系统
? 强调的是客户的价值,而不是技术、资金等
其它方面的价值
软系统方法( SSM)
? 方法
? 用不同的视点来分析问题情景
? 确定需求的过程是一个讨论、讨价还价和构造的
过程
? 这个过程产生的不仅仅是规格说明,还有:
? 修改组织结构的计划
? 任务结构
? 目的
? 对环境的理解
SSM方法:七步骤
1,发现问题:非系统性的、松散的、自由地提出问题,特别是关键
人物提出的问题
2、表达问题的情景
? 画一个详细的图
? 考察问题的主题(用自然语言来描述)
3、相关系统和根定义的选择
? 目的:定义与问题情景相关的概念上的系统,每个这样的系统有一个
根定义
? 根定义是人类活动系统的简明的描述
? CATWOE分析支持这个过程
? C,Customers; A:Actors; T:Transformation; W:Weltanschauung; O,
Owner; E,Environmental Constraints
SSM方法:七步骤
4,对每个根定义建立一个概念模型
? 对这个根定义的系统中,需要用来达到这个变迁的人类活动
? 表达活动之间的相关性(带有活动和资源流的,面向过程的模型)
5、将这个 概念模型与现实世界进行比较,发现变化点
? 按顺序提问 —— 基于模型的问题
? 事件重构 —— 取以前的事件并将它们与模型进行比较
? 一般的比较 —— 考察与当前的情景不同的模型的特性
? 模型迭加 —— 两个模型点对点的比较
6、识别可行的和想要的变化
? 三种类型的变化:结构的、过程的、属性的
? 投资者决定那些变化是真正需要的
7、提出达到这个变化建议
SSM建模
1, 体会药品
开销是如何
出现的
2, 获得关于
预算的信息
3, 体会管理人
员和医生在控
制药品开销方
面的作用
4, 决定如何收
集关于药品开
销的信息
5, 收集关于药
品开销的信息
6, 决定如何记录信
息,使管理人员和
医生对照预算控制
药品开销成为可能
7, 记录关于药
品开销的信息
8, 使记录对管
理人员和医生
是可用的
监控1 - 8 采取控制行为
定义系统有效
性等评价标准
体会医院对这
个系统的期望
根定义:
“一个医院系统,提供药品开销的
记录,以便管理人员和医生为了满
足预定的预算而采取的行为可以合
在一进行。”
客户:行政管理人员、医生
参与者:没说
变迁:需要知道药品的开销 ?需要
满足记录的信息
观点:监测药品的开销是可能的,
并且对联合的控制活动是合适的
所有者:医院
环境:医院的机制、行政管理人员
和医生的角色、定义好的预算
I*框架
? 背景
? 90年代早期发展出来
? 为需求工程中询问 ‘ 为什么 ’
类的问题提供结构
? 为信息系统的组织上下文建

? 以, 有目的的参与者, 的表
示为基础
? 模型的两个部分
? 战略依赖模型( SD模型):
为参与者之间的关系建立模

? 战略解释模型( SR模型):
为参与者的关注点和兴趣点
建立模型
? 方法
? SD模型展示参与者之间的依赖关

? 目标 /软目标依赖 —— 为了要达到
一个目标,一个参与者依靠另一
个参与者
? 资源依赖 —— 一个参与者需要从
另一个参与者处获得资源
? 任务依赖 —— 一个参与者需要另
一个参与者执行一个任务
? SR模型展示每个参与者内的目标
之间的交互关系
? 展示任务依赖
? 展示任务和目标之间的, 达到目
的的方法, 的关联
战略行为者
? 有目标、信念、能力、承诺
? 相互依赖为实现目标、执行任务、丰富资

? 半自治的 —— 不是全知和可控的
战略相关关系
行为者 A
I want

行为者 B
I can

D D被修好的车
如何构建 SD模型
? 识别 ACTORS
? 识别 ACTORS之间的依赖关系
? 资源依赖
? 任务依赖
? 目标依赖
? 软目标依赖
KAOS方法
? 背景
? 90年代早期发展:起源于面向目的论的需求
建模
? 特点:基于元模型的需求获取
? 过程:
? 以目标为导引构造与 /或树结构的目标层次
? 在元模型的引导下从目标导出可操作的需求
KAOS,基于目标的方法
? 什么是目标
? 目前没有特别明确的定义
? A goal is a non-operational
objective that the composite
system must meet
? 没有按照对象和系统的
Agent的行为来定义
? 可以用与 /或树表示
? 分系统目标和私有目标
G
G4
G3G2
G1
KAOS,基于目标的方法
? 按目标模式分
? 实现性目标 (Achieve),P ??Q( 当前或某个将来的
状态成立)
? 维持性目标 (Maintain), P ? Q( 当前并且所有将来
成立)
? 终止性目标 (Cease),P ???Q
? 避免性目标 (Avoid),P ? ?Q
? 优化性目标 (Optimize),最大化 /最小化 (目标函数 )
KAOS,基于目标的方法
? 按目标表示的需求分
? 满足性目标:满足 Agent的请求
? 信息性目标:让 Agent通知对象状态
? 鲁棒性目标:从人类 Agent的错误或自动 Agent的崩溃
中恢复
? 一致性目标:维护复杂系统自动部分和物理部分的一
致性
? 安全性目标和私密性目标:在受限的状态下,维护
Agent处于安全和可观察的状态中
KAOS:基于元模型的方法
KAOS,元模型概念
? 目标(如前所述)
? 对象:领域中所关心的事情,其实例会按状态而进化
? 分实体、关系、事件(按照自治的、从属的、或者瞬时的来分)
? 行为:对象上的输入 /输出关系,定义状态变迁,由事件
触发或终止
? Agent,一种对象,作为行为的执行者
? 约束:可操作的目标,可以按由某个 Agent可控制的状
态来构型的目标
? 情景:期望发生的行为的组合,并行、顺序、重复、选
择等组合模式
KAOS:元模型片段
KAOS,策略 +领域模型
? 策略:定义遍历元模型图来获取实例的方法
? 获取目标结构,标识目标涉及的对象
? 初步标识可能的 Agent,和这些 Agent能够执行的行为
? 将目标可操作化为约束
? 对象和行为的求精
? 强化行为和对象的条件,以保证约束
? Agent其它职责的标识
? 将行为实际地赋予负责的 Agent
KAOS,策略 +领域模型
? 领域模型:关于资源管理系统、交通系统、
通讯系统等领域中所涉及的不同层次的目
标、约束、对象、行为和 Agent
? 用与需求同样的规格说明语言描述
? 用 ISA层次组织成领域知识库
KAOS:领域知识及其作用
领域知识库
预定义的目标类型
预定义的目标归结模式
?标识系统目标、它的类型和模式
?根据目标类型和模式重用领域知识,涉及对象的
实例关系,产生目标归结,形成目标树
?标识目标之间的冲突,如果某个归结导致过多冲
突,则需要寻找其它归结方案
KAOS:获取目标结构
KAOS:识别可能的 Agents
AGENT Capability ACTION
建立‘ Agent--Capability--Action’的实例
目标结构中叶子目标涉及的对象
?重用 领域知识库中的行为模版 ?识别对应状态变化的行为,包括
pre-condition和 post-condition
KAOS:将目标操作化为约束
GOAL Operationalization CONSTRAINT
AvailabilityNotified
实例化
KAOS:求精对象和行为
? 定义约束时可能引入新的对象和行为
? 其中可能存在还在第 1,2步没有识别的实
体、关系、事件、以及状态转换
? 需要重新定义对象和行为
KAOS:保证约束得以满足
? 定义一组推理规则
? 将每个行为的前置条件、后置条件、以
及触发条件与约束进行比较
? 用上述推理规则求出该行为的加强前置
条件、后置条件、以及触发条件
KAOS:识别其它的职责
AGENT Responsibility CONSTRAINT
约束与 AGENT联系的条件:
?保证约束满足的行为属于该 AGENT能力范围
?按照行为的需求(前置条件、后置条件、触
发条件),该 AGENT可以执行该行为
KAOS:将行为赋予 AGENT
AGENT Perform ACTION