需求工程的方法
过程、方法和技术
描述的重要性
建模的作用
需求工程的维度
? 表示维（代表需求的可维护、可验证的程度）
? 非形式的：自然语言
? 半形式的：图形语言（如,UML,DFD,等）
? 形式的：数学或逻辑语言（如,Z,等）
? 内容维（代表需求工程的进行程度）
? 模糊的客观世界现象
? 明确的需求规格说明
? 一致性维
? 代表某个投资者的观点
? 得到全部投资者的认可
需求工程的三维视图
非形式 非形式 形式
规格说明
表示
一致的程度
模糊
一般
完全
个人观点
公共的观点
表示维
内容维
接受度维
再论描述的重要性
? 软件开发：获取描述 +逐步精化
? 需求：是过程的起点
需求 代码设计
系统
需求
问题
描述
什么, 怎样、相互转化
? 传统地，需求应该说明‘什么’而不
说明‘怎样’
? 但是这不很容易区分：
? 一辆小汽车做什么？
? 一个 WEB浏览器做什么？
? 在某个抽象层次上的‘怎样’形成下
一个层次上的‘什么’
? Jackson&Zave的工作提供了一个区分：
? ‘什么’涉及系统的目的
? 对系统来说是外部的
? 是应用领域的特性
? ‘怎样’涉及系统的结构和行为
? 对系统是内部的
? 是机器领域的特性
需求
需求
需求
设计
设计
设计
系统
子系统
单元
什么
什么
什么
怎样
怎样
怎样
关注于问题
? 问题先于解决方案
? 硬件和软件都能正常运行，但它起的作用却不是所想要的
? 对提早发现潜在的困难有帮助，困难越后发现越难解决
? 计算机系统和现实世界的关系
计算机系统
计算机系统
以外的世界
解决方
案在此
问题在此
世界和计
算机之间
的连接
需求处于环境之中
? 机器
? 我们称要被开发出来的软件系统为机器
? 硬件是为了运行软件而存在的，因此是机器的一部分
? 应用领域
? 机器将与它所处的环境发生交互
? 建立机器为了实现现实世界中的某个目的
? 定义机器的环境，就是定义应用领域
? 应用领域常常是人类活动的系统
? 实现的决策是出于那些在应用领域中没有基础的需求
? 例子：字典要存放在 Hash表中；病人记录要存放在一个面向对
象数据库中
需求的环境
零售企
业系统
客户
银行帐
户部门
仓库
供应商
订购，付
款
帐单
信用状态
帐单，查
询
订购
财务报告
发货通知
运送报告
需求的环境
借书
还书
续借
需求就是描述
? 指代：
? 环境中的实体：为它规定一个名字
? 观察到的现象：告诉你怎样识别它，并为它规定一个
名字
? 指代通常是非形式的，但它将一个模糊的现象映射到
一个形式的（或者说可表达的）语言上
? 定义
? 为一个术语给出形式的定义，使这个术语能在其它描
述中使用
? 定义或多或少是有用的，但它却是没有对错的
需求就是描述
? 可反驳的描述：领域的特性
? 陈述领域的某种特性，这种特性在原理上是可反驳的
? 可能实际上并不会去反驳它，但应该有这样的意识
? 可反驳性依赖于对我们正在描述的领域中的这个被指
代的现象的一种询问
? 一个粗略的框架
? 是要被开发出来系统描述的一个尝试性描述
? 允许包含未定义的术语
例子
? 指代：
MOTHER(X,M),表示 M是 X的母亲
? 定义：
CHILD(X,Y),:= MOTHER(Y,X)?FATHER(Y,X)
? 可反驳的描述：
对所有 M和 X有,MOTHER(X,M) ??MOTHER(M,X)
? 粗略的框架：
每个人实际上都只属于一个家庭
描述的语气问题
? 描述的不同语气
? 直述：给出一个事实
? 询问：问一个问题
? 命令：传递一个命令
? 假设：陈述一种可能
? 希求：表达一种愿望
需求是希求式的
? 需求一定包含“应该做什么,
? 对需求工程来说，一般应该有的语气：
? 领域特性：直述式语气
? 需求：希求式语气
? 语气随开发进程不断变化
需求描述 需求的表示维坐标
语言 语言的形式化程度
需求的内容维：模型
?现实中的三类模型
? 图示模型：一个雕塑，可视化
? 类比模型：一架模型飞机，使能测
试经验的决策
? 分析模型：表示社会经济的一组数
学方程，使能分析所描述的系统的
可能行为
需求中的模型
分析模型
类比模型
理解问题，为问题世界的相关部分建模
映射为实现，比如：用数据库存放信息
模型的抽象性
?模型不仅仅是描述
? 它具有自己的现象，和它自己的关于这些现
象之间的关系
? 只有当模型的现象按一种系统的方法对应到要被
建模的领域的现象时，这个模型才是有用的。
?模型是描述的抽象
模型的抽象性
作者 写 小说 记录A 记录B
X = 小说，Y = 作者
P=写
X = 记录A,Y = 记录B
P=A B
对每个X 至少存在
一个Y 使得P ( X,Y )
应用领域
对应用领
域的指代
共同的
描述
模型领域
对模型领
域的指代
建模中隐含的危险
? 一个模型绝对不会是完美的：两个方面的危险
? 存在模型中的现象不在应用领域中出现
? 存在应用中的现象不在模型中出现
应用领域
对应用领
域的指代
共享的
描述
模型领域
对模型领
域的指代
只在应用
领域中成
立的特性
只在建模
领域中成
立的特性
如何应对现实世界的复杂性
现实世界的复杂性 模型的方面性
抽象的好处：简洁、可操作
抽象的代价：片面
结构化原理
结构化原理之一：划分
? 划分：捕获聚合 /part-of关系
? 例子：
? 目标：开发一个航天飞机
? 划分：
? 引导和导航
? 数据处理
? 命令和控制
? 环境控制
? 仪表
? ……
? 注意：这不是设计，这只是一个问题分解
? 实际的设计还有一些组件，这些组件和这些子问题没有关系
? 然而，问题分解的选择可能将反映在设计中
结构化原理之二：抽象
? 抽象：
? 通过忽略一些细节来
发现概念之间的相似
性的方法
? 关注于现象之间的
“普遍 /特殊”关系
? 分类：将具有某个
相似点的实体定义
成一组，作为一个
单一的类的成员
? 泛化：表示,is-a”
关联中的不同类之
间的相似性
? 例子
? 需求：处理航天飞机的故障
? 可以将不同故障按不同故障类来组织
? 按照故障的位置
? 仪表故障
? 通讯系统故障
? 处理器故障
? ……
? 按照故障的表象
? 没有来自设备的响应
? 不正确的响应
? 自检失效
? ……
? ……
结构化原理之三：投影
? 投影
? 分离模型的不同方面为多个视点
? 与建筑图纸中使用的投影概念相同
? 例子
? 需求：为航天飞机和地面系统之间
的通讯系统建模
? 独立的模型：
? 消息序列
? 数据包格式
? 错误校正行为
? ……
? 注意
? 投影和划分是相
似的
? 划分定义 part-of
关系
? 投影定义 view-of
关系
? 划分假设划分出
来的组件相对独
立
过程、方法、技术 ?
? 一种 表示法 是用于表达的表示语言，如,Z,一界逻辑、
UML
? 一种 技术 规定如何进行一个特定的活动，以及如何描述
特定的表示法中活动的产品，如，数据流图
? 一个 方法 针对如何进行一组活动，提供一个技术上的规
定，关注于技术的集成和使用技术的指南，如,OMT，
JSD
? 一个 过程模型 是如何控制一组活动的抽象描述，关注活
动之间的资源使用和相关性
? 一个 过程 是过程模型的一个实例，这个过程模型描述了
一个或多个 Agent的行为和它们对资源的管理
过程、方法、技术 ?
?需求工程方法适合于需求工程过程？
?每种方法适合不同的步骤范围
? 它们适合于何处常常不是很明确
?方法从它们的关注点和覆盖面上很不相同；
? 覆盖面：抽取、建模、分析
? 关注点：目标、行为、视点
现象
? 涉及一点点哲学
? 现象学：研究在观察世界
时表现为存在的东西的学
说
? 本体论：研究实际上真的
存在的东西（独立与任何
的观察者）
? 认识论：研究人能够知道
（或者他们相信）的东西
? 世界观：一个世界的视点，
定义一个观察者想要（很
可能要）观察到的现象的
集合
? 任何方法都体现一个特定
的视点
? OO将世界看成带能响应外
部刺激的内部状态的对象
集合
? SA将世界看成是变换数据
的过程
? 自然语言也定义一个视点
? 一种方法通过限制你能够
描述的现象的集合，来限
制你将观察到的 …
? … 因此你能够建模的东西
模型驱动的方法
?举例：结构化分析、信息系统工程、面向
对象分析
?强调画出图示的系统模型，来对现实系统
和解系统建立文档并验证，最后系统模型
成为设计和实现的蓝图
?模型举例：数据流图、结构或层次图、组
织图
结构化分析
?技术要点：
? 模型驱动：数据流
? 过程为中心：过程，与过程相关的输入、输
出和文件
? 用于：
? 分析存在的系统
? 定义新系统的业务需求
结构化分析：数据流图
俱乐部会员
俱乐部会员
仓库
过程：
会员订购
帐号
定单
会员订购响应
要被填写的定单
修订自动定单
过程：
积分订购
积分订购
要被填写
的定单
过程：
自动订购
存在的定单信息
要被填写
的定单
信用率分值和限制
信用分值和限制
信用分值和限制
信息系统工程
?技术要点：
? 模型驱动：实体关系图
? 数据为中心：强调在对过程和接口进行之前
进行数据需求的研究和分析
? 过程敏感：借用了结构化分析中的数据流图
表示过程模型
? 用于：
? 规划、分析和设计信息系统
信息系统工程：实体关系图
会员定单 会员 合约
俱乐部促销产品
购买
按此存放 在此下注册
建立
倡议特性
诱发
面向对象分析
?技术要点
? 集成数据和过程关注点，构成对象
? 集成不同的视角：结构的和行为的
? 统一建模语言：图形语法
累积式分析方法
?特点：强调原型的构造，以便迅速地标识
新系统的业务和用户需求
?原型：小规模、不完整的、作为工作样板
?在快速应用开发（ RAD） 中常用，但 RAD
需要自动工具
几种累积式分析方法
?发现原型
? 通过获取用户对原型的反馈来标识用户的业
务需求
?快速体系结构分析
? 从存在的系统或发现原型中导出系统模型
?逆向工程技术
? 阅读存在的数据库、应用程序、和用户界面
等的代码，自动产生等价的系统模型
需求发现方法
?特点：
? 前两种方法：试图表达用户对新系统的需求
（用模型或原型）
? 需求发现方法：从用户群体中识别或精确化
系统问题和对解决方案的需求
常用需求发现方法
? 事实发现技术：
? 主要技术：
? 存在的文档的样本分析、
? 相关文献及其它相关解
决方案的分析、
? 对当前系统的观察、
? 问卷调查、
? 面谈、等。
? 缺点：不可估计、时
间开销大
? 联合需求规划（ JRP）
? 特点：
? 支持多方人员共同参与，
是联合应用开发（ JAD）
的一部分
? 为参加人员提供共同工
作的环境，加速工作进
程
? 通常与模型驱动的方法
一起使用，还和快速应
用开发方法学结合使用
业务进程重设计方法
?问题：大多数信息系统只是将存在的业务
系统自动化
?特点：结合全面质量管理和连续进程改进
?结果：
? 新的系统
? 基于商用成品软件（如 ERP等）推行业务进
程重设计
过程、方法和技术
描述的重要性
建模的作用
需求工程的维度
? 表示维（代表需求的可维护、可验证的程度）
? 非形式的：自然语言
? 半形式的：图形语言（如,UML,DFD,等）
? 形式的：数学或逻辑语言（如,Z,等）
? 内容维（代表需求工程的进行程度）
? 模糊的客观世界现象
? 明确的需求规格说明
? 一致性维
? 代表某个投资者的观点
? 得到全部投资者的认可
需求工程的三维视图
非形式 非形式 形式
规格说明
表示
一致的程度
模糊
一般
完全
个人观点
公共的观点
表示维
内容维
接受度维
再论描述的重要性
? 软件开发：获取描述 +逐步精化
? 需求：是过程的起点
需求 代码设计
系统
需求
问题
描述
什么, 怎样、相互转化
? 传统地，需求应该说明‘什么’而不
说明‘怎样’
? 但是这不很容易区分：
? 一辆小汽车做什么？
? 一个 WEB浏览器做什么？
? 在某个抽象层次上的‘怎样’形成下
一个层次上的‘什么’
? Jackson&Zave的工作提供了一个区分：
? ‘什么’涉及系统的目的
? 对系统来说是外部的
? 是应用领域的特性
? ‘怎样’涉及系统的结构和行为
? 对系统是内部的
? 是机器领域的特性
需求
需求
需求
设计
设计
设计
系统
子系统
单元
什么
什么
什么
怎样
怎样
怎样
关注于问题
? 问题先于解决方案
? 硬件和软件都能正常运行，但它起的作用却不是所想要的
? 对提早发现潜在的困难有帮助，困难越后发现越难解决
? 计算机系统和现实世界的关系
计算机系统
计算机系统
以外的世界
解决方
案在此
问题在此
世界和计
算机之间
的连接
需求处于环境之中
? 机器
? 我们称要被开发出来的软件系统为机器
? 硬件是为了运行软件而存在的，因此是机器的一部分
? 应用领域
? 机器将与它所处的环境发生交互
? 建立机器为了实现现实世界中的某个目的
? 定义机器的环境，就是定义应用领域
? 应用领域常常是人类活动的系统
? 实现的决策是出于那些在应用领域中没有基础的需求
? 例子：字典要存放在 Hash表中；病人记录要存放在一个面向对
象数据库中
需求的环境
零售企
业系统
客户
银行帐
户部门
仓库
供应商
订购，付
款
帐单
信用状态
帐单，查
询
订购
财务报告
发货通知
运送报告
需求的环境
借书
还书
续借
需求就是描述
? 指代：
? 环境中的实体：为它规定一个名字
? 观察到的现象：告诉你怎样识别它，并为它规定一个
名字
? 指代通常是非形式的，但它将一个模糊的现象映射到
一个形式的（或者说可表达的）语言上
? 定义
? 为一个术语给出形式的定义，使这个术语能在其它描
述中使用
? 定义或多或少是有用的，但它却是没有对错的
需求就是描述
? 可反驳的描述：领域的特性
? 陈述领域的某种特性，这种特性在原理上是可反驳的
? 可能实际上并不会去反驳它，但应该有这样的意识
? 可反驳性依赖于对我们正在描述的领域中的这个被指
代的现象的一种询问
? 一个粗略的框架
? 是要被开发出来系统描述的一个尝试性描述
? 允许包含未定义的术语
例子
? 指代：
MOTHER(X,M),表示 M是 X的母亲
? 定义：
CHILD(X,Y),:= MOTHER(Y,X)?FATHER(Y,X)
? 可反驳的描述：
对所有 M和 X有,MOTHER(X,M) ??MOTHER(M,X)
? 粗略的框架：
每个人实际上都只属于一个家庭
描述的语气问题
? 描述的不同语气
? 直述：给出一个事实
? 询问：问一个问题
? 命令：传递一个命令
? 假设：陈述一种可能
? 希求：表达一种愿望
需求是希求式的
? 需求一定包含“应该做什么,
? 对需求工程来说，一般应该有的语气：
? 领域特性：直述式语气
? 需求：希求式语气
? 语气随开发进程不断变化
需求描述 需求的表示维坐标
语言 语言的形式化程度
需求的内容维：模型
?现实中的三类模型
? 图示模型：一个雕塑，可视化
? 类比模型：一架模型飞机，使能测
试经验的决策
? 分析模型：表示社会经济的一组数
学方程，使能分析所描述的系统的
可能行为
需求中的模型
分析模型
类比模型
理解问题，为问题世界的相关部分建模
映射为实现，比如：用数据库存放信息
模型的抽象性
?模型不仅仅是描述
? 它具有自己的现象，和它自己的关于这些现
象之间的关系
? 只有当模型的现象按一种系统的方法对应到要被
建模的领域的现象时，这个模型才是有用的。
?模型是描述的抽象
模型的抽象性
作者 写 小说 记录A 记录B
X = 小说，Y = 作者
P=写
X = 记录A,Y = 记录B
P=A B
对每个X 至少存在
一个Y 使得P ( X,Y )
应用领域
对应用领
域的指代
共同的
描述
模型领域
对模型领
域的指代
建模中隐含的危险
? 一个模型绝对不会是完美的：两个方面的危险
? 存在模型中的现象不在应用领域中出现
? 存在应用中的现象不在模型中出现
应用领域
对应用领
域的指代
共享的
描述
模型领域
对模型领
域的指代
只在应用
领域中成
立的特性
只在建模
领域中成
立的特性
如何应对现实世界的复杂性
现实世界的复杂性 模型的方面性
抽象的好处：简洁、可操作
抽象的代价：片面
结构化原理
结构化原理之一：划分
? 划分：捕获聚合 /part-of关系
? 例子：
? 目标：开发一个航天飞机
? 划分：
? 引导和导航
? 数据处理
? 命令和控制
? 环境控制
? 仪表
? ……
? 注意：这不是设计，这只是一个问题分解
? 实际的设计还有一些组件，这些组件和这些子问题没有关系
? 然而，问题分解的选择可能将反映在设计中
结构化原理之二：抽象
? 抽象：
? 通过忽略一些细节来
发现概念之间的相似
性的方法
? 关注于现象之间的
“普遍 /特殊”关系
? 分类：将具有某个
相似点的实体定义
成一组，作为一个
单一的类的成员
? 泛化：表示,is-a”
关联中的不同类之
间的相似性
? 例子
? 需求：处理航天飞机的故障
? 可以将不同故障按不同故障类来组织
? 按照故障的位置
? 仪表故障
? 通讯系统故障
? 处理器故障
? ……
? 按照故障的表象
? 没有来自设备的响应
? 不正确的响应
? 自检失效
? ……
? ……
结构化原理之三：投影
? 投影
? 分离模型的不同方面为多个视点
? 与建筑图纸中使用的投影概念相同
? 例子
? 需求：为航天飞机和地面系统之间
的通讯系统建模
? 独立的模型：
? 消息序列
? 数据包格式
? 错误校正行为
? ……
? 注意
? 投影和划分是相
似的
? 划分定义 part-of
关系
? 投影定义 view-of
关系
? 划分假设划分出
来的组件相对独
立
过程、方法、技术 ?
? 一种 表示法 是用于表达的表示语言，如,Z,一界逻辑、
UML
? 一种 技术 规定如何进行一个特定的活动，以及如何描述
特定的表示法中活动的产品，如，数据流图
? 一个 方法 针对如何进行一组活动，提供一个技术上的规
定，关注于技术的集成和使用技术的指南，如,OMT，
JSD
? 一个 过程模型 是如何控制一组活动的抽象描述，关注活
动之间的资源使用和相关性
? 一个 过程 是过程模型的一个实例，这个过程模型描述了
一个或多个 Agent的行为和它们对资源的管理
过程、方法、技术 ?
?需求工程方法适合于需求工程过程？
?每种方法适合不同的步骤范围
? 它们适合于何处常常不是很明确
?方法从它们的关注点和覆盖面上很不相同；
? 覆盖面：抽取、建模、分析
? 关注点：目标、行为、视点
现象
? 涉及一点点哲学
? 现象学：研究在观察世界
时表现为存在的东西的学
说
? 本体论：研究实际上真的
存在的东西（独立与任何
的观察者）
? 认识论：研究人能够知道
（或者他们相信）的东西
? 世界观：一个世界的视点，
定义一个观察者想要（很
可能要）观察到的现象的
集合
? 任何方法都体现一个特定
的视点
? OO将世界看成带能响应外
部刺激的内部状态的对象
集合
? SA将世界看成是变换数据
的过程
? 自然语言也定义一个视点
? 一种方法通过限制你能够
描述的现象的集合，来限
制你将观察到的 …
? … 因此你能够建模的东西
模型驱动的方法
?举例：结构化分析、信息系统工程、面向
对象分析
?强调画出图示的系统模型，来对现实系统
和解系统建立文档并验证，最后系统模型
成为设计和实现的蓝图
?模型举例：数据流图、结构或层次图、组
织图
结构化分析
?技术要点：
? 模型驱动：数据流
? 过程为中心：过程，与过程相关的输入、输
出和文件
? 用于：
? 分析存在的系统
? 定义新系统的业务需求
结构化分析：数据流图
俱乐部会员
俱乐部会员
仓库
过程：
会员订购
帐号
定单
会员订购响应
要被填写的定单
修订自动定单
过程：
积分订购
积分订购
要被填写
的定单
过程：
自动订购
存在的定单信息
要被填写
的定单
信用率分值和限制
信用分值和限制
信用分值和限制
信息系统工程
?技术要点：
? 模型驱动：实体关系图
? 数据为中心：强调在对过程和接口进行之前
进行数据需求的研究和分析
? 过程敏感：借用了结构化分析中的数据流图
表示过程模型
? 用于：
? 规划、分析和设计信息系统
信息系统工程：实体关系图
会员定单 会员 合约
俱乐部促销产品
购买
按此存放 在此下注册
建立
倡议特性
诱发
面向对象分析
?技术要点
? 集成数据和过程关注点，构成对象
? 集成不同的视角：结构的和行为的
? 统一建模语言：图形语法
累积式分析方法
?特点：强调原型的构造，以便迅速地标识
新系统的业务和用户需求
?原型：小规模、不完整的、作为工作样板
?在快速应用开发（ RAD） 中常用，但 RAD
需要自动工具
几种累积式分析方法
?发现原型
? 通过获取用户对原型的反馈来标识用户的业
务需求
?快速体系结构分析
? 从存在的系统或发现原型中导出系统模型
?逆向工程技术
? 阅读存在的数据库、应用程序、和用户界面
等的代码，自动产生等价的系统模型
需求发现方法
?特点：
? 前两种方法：试图表达用户对新系统的需求
（用模型或原型）
? 需求发现方法：从用户群体中识别或精确化
系统问题和对解决方案的需求
常用需求发现方法
? 事实发现技术：
? 主要技术：
? 存在的文档的样本分析、
? 相关文献及其它相关解
决方案的分析、
? 对当前系统的观察、
? 问卷调查、
? 面谈、等。
? 缺点：不可估计、时
间开销大
? 联合需求规划（ JRP）
? 特点：
? 支持多方人员共同参与，
是联合应用开发（ JAD）
的一部分
? 为参加人员提供共同工
作的环境，加速工作进
程
? 通常与模型驱动的方法
一起使用，还和快速应
用开发方法学结合使用
业务进程重设计方法
?问题：大多数信息系统只是将存在的业务
系统自动化
?特点：结合全面质量管理和连续进程改进
?结果：
? 新的系统
? 基于商用成品软件（如 ERP等）推行业务进
程重设计
