需求抽取（ I）
传统的方法
交谈和问卷
情景、目标和用例
软件开发的四个世界
问题世界
开发世界
使用世界 系统世界
关于应用领域的信
息如何被系统使用
开发目标的证明
机器如何表示关于
应用领域的信息
设计决策
用户界面
需求抽取
? 开始点
? 存在一个“问题”需
要解决，例如：
? 对当前的事务处理方
式不满意
? 出现新的业务机会
? 有可能节省开销、时
间、资源的使用、等
? 需求工程师是带来变
化的代理人
? 需求工程师必须要做的：
? 标识“问题” /“机会”
? 那个问题需要解决？（识别问题边界）
? 问题在什么地方？（理解上下文 /问题领域）
? 是谁的问题？（识别投资人）
? 为什么需要解决它？（识别投资人的目标）
? 软件系统会起到怎样的作用？（采集一些情景）
? 它需要什么时候解决？（识别开发约束）
? 什么会防碍我们解决它？（识别可行性和风险）
? 抽取足够的知识
? …… 足以分析需求：有效性、一致性、完整性
? 变成问题领域的专家
W6H（ 记者的技巧）
What,Where,Who、
Why,When,How、
Which
抽取的困难
? 领域知识非常薄弱
? 知识可能分布在许多地方，并很少以显式的形式表示出来（写出来）
? 来自不同地方的知识之间将会有矛盾
? 不同的人有不同的目标，不同的人对问题的理解不同
? 经验知识
? 人很难描述他们日常使用的知识
? 描述会是专家行为的不准确的理性化
? 有限的观察
? 问题拥有者可能太忙，没时间用存在的系统去解决它
? 出现一个观察可能会改变这个问题
? 偏见
? 人可能不方便告诉你你需要知道什么
? 人可能不想告诉你你需要知道什么
与客户沟通的重要性
0
10
20
30
40
50
60
70
软件工具 程序环境 财务软件 办公软件 主要航线 中型饮料公司
更成功的项目
不够成功的项目
成功的项目都与客户有更多的联系
使
用
的
联
系
与
所
有
可
能
的
联
系
的
百
分
比
抽取技术
? 传统的方法
? 内省
? 存在的文档
? 数据分析
? 交谈
? 开放式
? 结构式
? 调查 /问卷
? 组抽取
? 有关注点的组
? 大脑风暴
? JAD/RAD工作组
? 原型法
? 基于表示的方法
? 基于目标的
? 基于情景的
? 用例
? 上下文的方法
? 谈话分析
? 谈话分析
? 语言 -行为分析
? 参与式设计
? 社会技术方法
? 软系统分析
? 认知的方法
? 任务分析
? 协议分析
? 知识获取技术
? 场记分析法
? 卡片分类法
? 分类表格技术
? 基于模型的知识获取
这一讲
下一讲
交谈法
? 类型
? 结构式：需要提前准备，具有明确的日程，预先确定好问题，
? 开放式：非正式会议、没有事先准备的问题和预计的目的、鼓励客户讲出他们
自己的想法
? 优点
? 能采集到丰富的信息
? 缺点
? 大量定性的数据可能很难分析
? 不同的回答难以比较
? 交谈的技巧很难掌握
? 注意
? 三种问题需要避免：固执己见的问题、带偏见的问题、强加的问题
? 经验性知识不好谈出来
? 交谈者的态度会影响交谈的结果
直接表达了自己的关
于这个问题的观点：
“我们必须 ……, 同上，但观点明显有
偏见：“我们不
做 ……,对吗？” 假设了问题的答案：
“你是用这种方式
做 ……,对吗？”
交谈形式举例
? 正向模拟：举几个例子，请用户说明工作过程
? 案例分析：请用户选择有代表性的案例，并说
明工作过程
? 授课实例：系统分析员选出一批有代表性的案
例，请用户说明
? 局外评论：请用户对正在进行的过程进行评论
? 知识反教：从用户出获取信息后，按照自己的
理解表述给用户
问卷法
? 优点：
? 快速地从多个客户中收集
信息
? 可以远程进行
? 回答者有时间思考、回答
可以匿名
? 缺点：
? 没有面谈法有效，是被动
的
? 按问题的简单分类，提供
很少的上下文信息
? 回答者不容易弄清楚问题
的含义和出发点
? 注意（问卷分析）
? 样本选择中的偏差
? 小样本规模、缺少统计上
的意义
? 要避免的问题
? 引导性问题
? 模糊的问题
? 一般采用的问题形式
? 多项选择
? 评分
? 排序
观察法
? 包括：
? 主动观察
? 被动观察
? 注意：
? 时间相对较长
? 选择不同时间段、不同工作负荷时的场景
组抽取技术
? 类型
? 联合应用开发 /
快速应用开发
? 具有关注点的组
? 大脑风暴
? 注意
? 样本偏差
? 支配地位和服从
? 优点
? 比形式的面谈具有更自然的交互
? 能够判定对一些初步设计的反映（原
型、使用情节串联图、等）
? 群体动力学原理、组协同（提高生产
力、学得更快、制定更多理智的判断、
消除更多的错误,… ）
? 缺点
? 组的构成可能不够自然（参与者在一
起感到不舒服）
? 对技术问题可能只提供粗略的反映
? 要求有受过正规训练的组织者
联合应用开发（ JAD）
? 特点：
? 将所有的投资者（客户和开发人员）带到一起（不超过 25到 30人）
? 形式：
? 几个小时、几天、甚至一到两个星期的 JAD会议
? 参加者：
? 领导：组织和召集这个会议的人（具有交流能力，很好的业务领域知
识）
? 文书：在计算机上记录 JAD活动，能够使用 CASE工具为活动生成文档，
并开发出最初的解决方案模型
? 客户（最终用户和经理）：是交流、讨论需求、作出决策、批准项目
目标等的主要参与者
? 开发人员：业务分析员等，他们听得多说得少，主要是收集信息
联合应用开发（ JAD）
? 基础：群体动力学原理，支持组协同
? 提高生产力
? 学得更快
? 制定更多理智的判断
? 消除更多的错误
快速应用开发（ RAD）
? 特点：组合了五个方面的技术
? 进化原型技术
? 带有代码生成，以及支持设计和代码生成循环工程的
CASE工具
? 拥有先进工具的专门人员（ SWAT）
? 交互式 JAD,一般 JAD中的文书由具有 CASE工具的
SWAT小组代替
? 时间表：具有固定的时间期限、严格禁止“范围扩
张”、进展缓慢就削减方案、按时完成是第一位的
不仅仅是需求抽取方法，还是视软件开发为一体的方法。
原型法
? 演示型系统：
?,丢弃”式原型
? 进化式原型
? 呈现图形用户界面
? 对各种用户事件模拟系统的行为
文档的研究
? 组织文档
? 业务表格、工作过程、职位描述、政策手册、
业务计划、组织图、会议记录、财务报
表,…
? 系统文档
? 计算机屏幕、各类录入表单、各类打印报
表,…
? 领域知识需求
? 领域刊物、书籍、参考手册,…
“硬数据”的采集
? 标识硬数据的集合
? 事实、图表、财务信息,……
? 用于决策分析的报表,……
? 调查结果、市场数据,……
? 抽样
? 抽样用来从中选择有代表性的集合
? 有目的的抽样：选择不担心统计问题，你也认为是相关的部分
? 简单随机抽样：每隔 k项选择一个
? 分层随机抽样：先分层次、再抽样
? 聚簇随机抽样：选择一个有代表性的子数据集，再抽样
? 样本规模非常重要
? 要进行数据采集和分析的代价以及所需要的明显度之间的平衡
用例
? 什么是用例？
? 参与者与系统交互的每种不同的方式都
是一个用例
? 对一个特定的参与者，产生一个可观察
的结果的系统执行的行为序列的描述
? 所有的用例都需要枚举出来，否则需求
将会不完整
? 带有共同的目的的可能的情景的集合描
述
? 一般用自然语言书写
? 不含系统的内部状态；只包含交互
? 组合用例的方式
? 扩展 /使用
? 优点和缺点
? 所有可能的与系统的
交互的详细特征
? 帮助画出系统的边界，
和规定需求的范围
? 用例并没有捕获领域
知识
? 不能将用例和精确的
规格说明混为一谈
系统行为 是当系统响应外部事件时所做的事情
用例 捕获从外表上可见并可测的系统行为
一个用例执行一个业务功能，该功能对参与者来说是外表上可见的
用例图
? 图元：
? 参与者
? 用例
? 连接：
? 表示参与者和用
例之间的关联
显示标准计
算机配置
设置计算机
配置
验证并接收
客户付款
更新订单状
态
打印发票
请求销售人
员的联系
订购配置好
的计算机
将订单通知
仓库
客户
仓库 销售人员
使用用例
? 画系统边界
? 识别系统边界外与系统发生交互的参与者
? 对每个参与者，做：
? 识别可能的用例
? 做出示例每个用例的具体的情景
? 将相似的情景组合起来成为一个用例
? 对每个用例，做：
? 将它写出来
? 说明选择和循环的规则
? 考虑其它选择和例外
? 查看与其它用例的重叠和共同点
用例框架
用例名：
简述：
参与者：
前提条件：
描述：
例外：
后置条件：
用例文档
用例：订购计算机
简述：该用况允许 Customer输入一份购物定单, 该定单包括提供运送和发票地址, 以及关于付款的详细情况
参与者：客户
前提条件：客户点击 Internet浏览器进入计算机制造厂商的定单输入 web页面, 该页面显示已配置计算机以及它的价格
的详细情况 。
主要的流：
1,当客户在定单信息已经显示在屏幕上时选择 继续 （ 或相似命名的 ） 功能键来确定订购所配置的计算机时, 该用
例开始 。
2,系统请求客户输入购买细节, 包括：销售人员的名字 （ 如果知道的话 ）, 运送信息 （ 客户的名字和地址 ）, 发
票细节 （ 如果与运送地址不同的话 ）, 付款方法 （ 信用卡或支票 ）, 以及任何其它注释 。
3,客户选择 购买 （ 或相似命名的 ） 功能发送定单给制造厂商 。
4,系统给购买定单赋予一个唯一的定单号码和一个客户帐号, 系统将定单信息存入数据库 。
5,系统将定单号和客户号与所有定单细节一起 e-mail给客户, 作为对接收定单的确认 。
其它的流：
1,客户在提供所有要求录入的信息之前, 激活 购买 （ 或相似命名的 ） 功能, 系统显示错误信息, 它要求提供所漏
掉的信息 。
2,客户选择 恢复 （ 或相似命名的 ） 功能来恢复一个空白的购物表格, 系统允许客户重新输入信息 。
后置条件：如果用况成功, 购物定单记录进系统的数据库, 否则系统的状态不变 。
从用例文档中识别情景
? 情景（活动序列）
? 参与者和系统之间交互的特定序列
? 比较短的序列（一般为 3到 7步）
? 可以是：正方的（需要的行为）和反方的（不想要的行为）
? 可以是陈述的或希求的
? 优点：
? 非常自然：投资人喜欢使用
? 短的情景对快速示例特定的交互非常好
? 缺点：
? 缺乏结构：需要用例或任务模型提供更高层的视点
活动图
显示当前配置 获取定单请求
显示购买表单
获取购买信息 库存定单
E m a i l 定单信息
不完全
完全
任务模型和情景
? 任务模型
? 构型活动的层次化采集
? 子目标就是任务
? 子目标可以按顺序、并发、或者选择的方式出现
? 子目标可以周期出现，或者作为对偶然事件的响应
? 情景
? 是穿越任务模型的通路，按特定的时间顺序选取任务作为情景的活动
步骤
? 可以用来组织需求
? 可以包含并发性
? 例外
? 情景是用例的一种重要的变体
? 不能建模为情景本身，由于任务模型与许多可执行的情景发生交互
基于目标的方法
? 理解软件系统的运行环境和它与环境的交互
? 软件系统已经成为业务和组织进化方案的一部
分，必须与业务和组织关联起来考虑
? 业务和组织的动态发展性要求不断进化
? 目标模型是连接软件系统和组织业务的一种手
段
基于目标的方法
? 方法
? 关注于系统为什么要构造
? 将为什么的问题表达成投资者的一组目标
? 使用目标求精来导出特定的需求
? 目标分析：
? 为目标建立文档、组织并分类目标
? 目标进化
? 对目标进行求精、具体化、和操作化
? 目标层次展现目标之间的求精和障碍关系
基于目标的方法
? 提示
? 多个来源会产生更好的目标
? 将投入者与每个目标关联起来（揭示视点和冲突）
? 使用情景来探索目标怎样才能遇到
? 优点：
? 可推理、具有直观意义
? 显式地描述目标为冲突求解提供了基础
? 缺点
? 难以处理目标的进化
? 可能会进入目标提升（或分解）的无限
几种常用方法的比较
优点 缺点
问卷法 快速采集大量信息；可以远程实现；采
集关于态度、信念等
按照预先制订的框架进行，可能不能反
映真实的需求
面谈法 采集到丰富的信息 采集到的定性数据难以分析；不同谈话
者的结果不好比较；技巧不好掌握
硬数据采集 包括图表、报表、财务信息、市场数据、
等等
需要考虑数据采集及分析的开销
用例法 与系统的可能的交互的描述；易于刻画
系统边界和需求范围
不包含领域知识；不应与精确的规格说
明混淆；应包含所有可能的用例
情景法 是用例的一种，交互的特定序列；包含
正反实例；比较自然
缺乏结构性，需 要其它方法提供抽象视
点，如：任务模型
基于目标技术 直观；为冲突求解提供基础 不利于需求进化；
传统的方法
交谈和问卷
情景、目标和用例
软件开发的四个世界
问题世界
开发世界
使用世界 系统世界
关于应用领域的信
息如何被系统使用
开发目标的证明
机器如何表示关于
应用领域的信息
设计决策
用户界面
需求抽取
? 开始点
? 存在一个“问题”需
要解决，例如：
? 对当前的事务处理方
式不满意
? 出现新的业务机会
? 有可能节省开销、时
间、资源的使用、等
? 需求工程师是带来变
化的代理人
? 需求工程师必须要做的：
? 标识“问题” /“机会”
? 那个问题需要解决？（识别问题边界）
? 问题在什么地方？（理解上下文 /问题领域）
? 是谁的问题？（识别投资人）
? 为什么需要解决它？（识别投资人的目标）
? 软件系统会起到怎样的作用？（采集一些情景）
? 它需要什么时候解决？（识别开发约束）
? 什么会防碍我们解决它？（识别可行性和风险）
? 抽取足够的知识
? …… 足以分析需求：有效性、一致性、完整性
? 变成问题领域的专家
W6H（ 记者的技巧）
What,Where,Who、
Why,When,How、
Which
抽取的困难
? 领域知识非常薄弱
? 知识可能分布在许多地方，并很少以显式的形式表示出来（写出来）
? 来自不同地方的知识之间将会有矛盾
? 不同的人有不同的目标，不同的人对问题的理解不同
? 经验知识
? 人很难描述他们日常使用的知识
? 描述会是专家行为的不准确的理性化
? 有限的观察
? 问题拥有者可能太忙，没时间用存在的系统去解决它
? 出现一个观察可能会改变这个问题
? 偏见
? 人可能不方便告诉你你需要知道什么
? 人可能不想告诉你你需要知道什么
与客户沟通的重要性
0
10
20
30
40
50
60
70
软件工具 程序环境 财务软件 办公软件 主要航线 中型饮料公司
更成功的项目
不够成功的项目
成功的项目都与客户有更多的联系
使
用
的
联
系
与
所
有
可
能
的
联
系
的
百
分
比
抽取技术
? 传统的方法
? 内省
? 存在的文档
? 数据分析
? 交谈
? 开放式
? 结构式
? 调查 /问卷
? 组抽取
? 有关注点的组
? 大脑风暴
? JAD/RAD工作组
? 原型法
? 基于表示的方法
? 基于目标的
? 基于情景的
? 用例
? 上下文的方法
? 谈话分析
? 谈话分析
? 语言 -行为分析
? 参与式设计
? 社会技术方法
? 软系统分析
? 认知的方法
? 任务分析
? 协议分析
? 知识获取技术
? 场记分析法
? 卡片分类法
? 分类表格技术
? 基于模型的知识获取
这一讲
下一讲
交谈法
? 类型
? 结构式：需要提前准备，具有明确的日程，预先确定好问题，
? 开放式：非正式会议、没有事先准备的问题和预计的目的、鼓励客户讲出他们
自己的想法
? 优点
? 能采集到丰富的信息
? 缺点
? 大量定性的数据可能很难分析
? 不同的回答难以比较
? 交谈的技巧很难掌握
? 注意
? 三种问题需要避免：固执己见的问题、带偏见的问题、强加的问题
? 经验性知识不好谈出来
? 交谈者的态度会影响交谈的结果
直接表达了自己的关
于这个问题的观点：
“我们必须 ……, 同上，但观点明显有
偏见：“我们不
做 ……,对吗？” 假设了问题的答案：
“你是用这种方式
做 ……,对吗？”
交谈形式举例
? 正向模拟：举几个例子，请用户说明工作过程
? 案例分析：请用户选择有代表性的案例，并说
明工作过程
? 授课实例：系统分析员选出一批有代表性的案
例，请用户说明
? 局外评论：请用户对正在进行的过程进行评论
? 知识反教：从用户出获取信息后，按照自己的
理解表述给用户
问卷法
? 优点：
? 快速地从多个客户中收集
信息
? 可以远程进行
? 回答者有时间思考、回答
可以匿名
? 缺点：
? 没有面谈法有效，是被动
的
? 按问题的简单分类，提供
很少的上下文信息
? 回答者不容易弄清楚问题
的含义和出发点
? 注意（问卷分析）
? 样本选择中的偏差
? 小样本规模、缺少统计上
的意义
? 要避免的问题
? 引导性问题
? 模糊的问题
? 一般采用的问题形式
? 多项选择
? 评分
? 排序
观察法
? 包括：
? 主动观察
? 被动观察
? 注意：
? 时间相对较长
? 选择不同时间段、不同工作负荷时的场景
组抽取技术
? 类型
? 联合应用开发 /
快速应用开发
? 具有关注点的组
? 大脑风暴
? 注意
? 样本偏差
? 支配地位和服从
? 优点
? 比形式的面谈具有更自然的交互
? 能够判定对一些初步设计的反映（原
型、使用情节串联图、等）
? 群体动力学原理、组协同（提高生产
力、学得更快、制定更多理智的判断、
消除更多的错误,… ）
? 缺点
? 组的构成可能不够自然（参与者在一
起感到不舒服）
? 对技术问题可能只提供粗略的反映
? 要求有受过正规训练的组织者
联合应用开发（ JAD）
? 特点：
? 将所有的投资者（客户和开发人员）带到一起（不超过 25到 30人）
? 形式：
? 几个小时、几天、甚至一到两个星期的 JAD会议
? 参加者：
? 领导：组织和召集这个会议的人（具有交流能力，很好的业务领域知
识）
? 文书：在计算机上记录 JAD活动，能够使用 CASE工具为活动生成文档，
并开发出最初的解决方案模型
? 客户（最终用户和经理）：是交流、讨论需求、作出决策、批准项目
目标等的主要参与者
? 开发人员：业务分析员等，他们听得多说得少，主要是收集信息
联合应用开发（ JAD）
? 基础：群体动力学原理，支持组协同
? 提高生产力
? 学得更快
? 制定更多理智的判断
? 消除更多的错误
快速应用开发（ RAD）
? 特点：组合了五个方面的技术
? 进化原型技术
? 带有代码生成，以及支持设计和代码生成循环工程的
CASE工具
? 拥有先进工具的专门人员（ SWAT）
? 交互式 JAD,一般 JAD中的文书由具有 CASE工具的
SWAT小组代替
? 时间表：具有固定的时间期限、严格禁止“范围扩
张”、进展缓慢就削减方案、按时完成是第一位的
不仅仅是需求抽取方法，还是视软件开发为一体的方法。
原型法
? 演示型系统：
?,丢弃”式原型
? 进化式原型
? 呈现图形用户界面
? 对各种用户事件模拟系统的行为
文档的研究
? 组织文档
? 业务表格、工作过程、职位描述、政策手册、
业务计划、组织图、会议记录、财务报
表,…
? 系统文档
? 计算机屏幕、各类录入表单、各类打印报
表,…
? 领域知识需求
? 领域刊物、书籍、参考手册,…
“硬数据”的采集
? 标识硬数据的集合
? 事实、图表、财务信息,……
? 用于决策分析的报表,……
? 调查结果、市场数据,……
? 抽样
? 抽样用来从中选择有代表性的集合
? 有目的的抽样：选择不担心统计问题，你也认为是相关的部分
? 简单随机抽样：每隔 k项选择一个
? 分层随机抽样：先分层次、再抽样
? 聚簇随机抽样：选择一个有代表性的子数据集，再抽样
? 样本规模非常重要
? 要进行数据采集和分析的代价以及所需要的明显度之间的平衡
用例
? 什么是用例？
? 参与者与系统交互的每种不同的方式都
是一个用例
? 对一个特定的参与者，产生一个可观察
的结果的系统执行的行为序列的描述
? 所有的用例都需要枚举出来，否则需求
将会不完整
? 带有共同的目的的可能的情景的集合描
述
? 一般用自然语言书写
? 不含系统的内部状态；只包含交互
? 组合用例的方式
? 扩展 /使用
? 优点和缺点
? 所有可能的与系统的
交互的详细特征
? 帮助画出系统的边界，
和规定需求的范围
? 用例并没有捕获领域
知识
? 不能将用例和精确的
规格说明混为一谈
系统行为 是当系统响应外部事件时所做的事情
用例 捕获从外表上可见并可测的系统行为
一个用例执行一个业务功能，该功能对参与者来说是外表上可见的
用例图
? 图元：
? 参与者
? 用例
? 连接：
? 表示参与者和用
例之间的关联
显示标准计
算机配置
设置计算机
配置
验证并接收
客户付款
更新订单状
态
打印发票
请求销售人
员的联系
订购配置好
的计算机
将订单通知
仓库
客户
仓库 销售人员
使用用例
? 画系统边界
? 识别系统边界外与系统发生交互的参与者
? 对每个参与者，做：
? 识别可能的用例
? 做出示例每个用例的具体的情景
? 将相似的情景组合起来成为一个用例
? 对每个用例，做：
? 将它写出来
? 说明选择和循环的规则
? 考虑其它选择和例外
? 查看与其它用例的重叠和共同点
用例框架
用例名：
简述：
参与者：
前提条件：
描述：
例外：
后置条件：
用例文档
用例：订购计算机
简述：该用况允许 Customer输入一份购物定单, 该定单包括提供运送和发票地址, 以及关于付款的详细情况
参与者：客户
前提条件：客户点击 Internet浏览器进入计算机制造厂商的定单输入 web页面, 该页面显示已配置计算机以及它的价格
的详细情况 。
主要的流：
1,当客户在定单信息已经显示在屏幕上时选择 继续 （ 或相似命名的 ） 功能键来确定订购所配置的计算机时, 该用
例开始 。
2,系统请求客户输入购买细节, 包括：销售人员的名字 （ 如果知道的话 ）, 运送信息 （ 客户的名字和地址 ）, 发
票细节 （ 如果与运送地址不同的话 ）, 付款方法 （ 信用卡或支票 ）, 以及任何其它注释 。
3,客户选择 购买 （ 或相似命名的 ） 功能发送定单给制造厂商 。
4,系统给购买定单赋予一个唯一的定单号码和一个客户帐号, 系统将定单信息存入数据库 。
5,系统将定单号和客户号与所有定单细节一起 e-mail给客户, 作为对接收定单的确认 。
其它的流：
1,客户在提供所有要求录入的信息之前, 激活 购买 （ 或相似命名的 ） 功能, 系统显示错误信息, 它要求提供所漏
掉的信息 。
2,客户选择 恢复 （ 或相似命名的 ） 功能来恢复一个空白的购物表格, 系统允许客户重新输入信息 。
后置条件：如果用况成功, 购物定单记录进系统的数据库, 否则系统的状态不变 。
从用例文档中识别情景
? 情景（活动序列）
? 参与者和系统之间交互的特定序列
? 比较短的序列（一般为 3到 7步）
? 可以是：正方的（需要的行为）和反方的（不想要的行为）
? 可以是陈述的或希求的
? 优点：
? 非常自然：投资人喜欢使用
? 短的情景对快速示例特定的交互非常好
? 缺点：
? 缺乏结构：需要用例或任务模型提供更高层的视点
活动图
显示当前配置 获取定单请求
显示购买表单
获取购买信息 库存定单
E m a i l 定单信息
不完全
完全
任务模型和情景
? 任务模型
? 构型活动的层次化采集
? 子目标就是任务
? 子目标可以按顺序、并发、或者选择的方式出现
? 子目标可以周期出现，或者作为对偶然事件的响应
? 情景
? 是穿越任务模型的通路，按特定的时间顺序选取任务作为情景的活动
步骤
? 可以用来组织需求
? 可以包含并发性
? 例外
? 情景是用例的一种重要的变体
? 不能建模为情景本身，由于任务模型与许多可执行的情景发生交互
基于目标的方法
? 理解软件系统的运行环境和它与环境的交互
? 软件系统已经成为业务和组织进化方案的一部
分，必须与业务和组织关联起来考虑
? 业务和组织的动态发展性要求不断进化
? 目标模型是连接软件系统和组织业务的一种手
段
基于目标的方法
? 方法
? 关注于系统为什么要构造
? 将为什么的问题表达成投资者的一组目标
? 使用目标求精来导出特定的需求
? 目标分析：
? 为目标建立文档、组织并分类目标
? 目标进化
? 对目标进行求精、具体化、和操作化
? 目标层次展现目标之间的求精和障碍关系
基于目标的方法
? 提示
? 多个来源会产生更好的目标
? 将投入者与每个目标关联起来（揭示视点和冲突）
? 使用情景来探索目标怎样才能遇到
? 优点：
? 可推理、具有直观意义
? 显式地描述目标为冲突求解提供了基础
? 缺点
? 难以处理目标的进化
? 可能会进入目标提升（或分解）的无限
几种常用方法的比较
优点 缺点
问卷法 快速采集大量信息；可以远程实现；采
集关于态度、信念等
按照预先制订的框架进行，可能不能反
映真实的需求
面谈法 采集到丰富的信息 采集到的定性数据难以分析；不同谈话
者的结果不好比较；技巧不好掌握
硬数据采集 包括图表、报表、财务信息、市场数据、
等等
需要考虑数据采集及分析的开销
用例法 与系统的可能的交互的描述；易于刻画
系统边界和需求范围
不包含领域知识；不应与精确的规格说
明混淆；应包含所有可能的用例
情景法 是用例的一种，交互的特定序列；包含
正反实例；比较自然
缺乏结构性，需 要其它方法提供抽象视
点，如：任务模型
基于目标技术 直观；为冲突求解提供基础 不利于需求进化；
