需求工程的基本原理
软件工程的本质
什么是需求工程
需求工程在生命周期中的作用
有效性的问题
问题领域的类型
软件开发的本质
? 软件要解决的问题具有：
? 复杂性
? 不一致性
? 可变性
? 不可见性
软件工程固有的困难
软件：是作为一种创造性活动开发出来的产品
是由工匠（而不是艺术家）创作的工艺品或艺术品
软件不是重复性制造活动的产物
存在各种各样的不确定因素
软件开发的不变量
? 软件是开发出来的，不是制造出来的（充满了各种不确
定性）
? 软件工程的进展为开发实践带来了很多确定的因素，但
然不象传统工程那样成功，软件项目的成功仍然无法保
证。
? 算法、代码库、可复用类、软件构件：模块重用
? 商用成品软件：从零开始变成客户化软件
? 各种概念结构：支持从零开始的软件开发
? 但是任何组织不可能找到一个软件包使它的核心业务活
动可以自动生成
三
个
不
同
层
次
上
的
解
决
方
案
项目成败的因素：投入者
? 客户：
? 客户的需要被误解或没有
被完全捕捉
? 客户需求变化得过于频繁
? 客户没有准备为项目提供
足够的资源
? 客户不想与开发者合作
? 客户具有不现实的期望
? 系统不再对客户有利
? 开发人员：
? 不能胜任本项任务
? 开发者的技能和知识
非常关键
? 杰出的设计来自杰出
的设计者
软件系统大部分是社会系统，是由人（开发者）为人
（客户）开发的，软件项目的成功由社会因素确定
项目成败的因素：过程
? 软件开发过程确定以促进开发小组内部合作的活动和组
织的程序，使得能交给客户一个性能优良的产品
? 过程模型包括：
? 说明执行活动的次序
? 说明需要交出什么样的制品，以及什么时候交出
? 将活动和制品交给开发者
? 提供监控项目进程、评估产出和计划未来项目的准则
? 每个组织都有自己的过程，或客户化一个通用过程模板
几种典型的过程改进模型
? 迭代增量式开发：
? 迭代涉及管理可执行的版本流的过程；
? 增量涉及系统结构连续继承以产生这些版本
的过程；
? 关键：系统划分的规模和模块间的偶合度
几种典型的过程改进模型
第一级
初始级
第五级
优化
第四级
已管理
第三级
已定义
第二级
可重复
依赖当前员工的不可预测和无规程的过程
可重复的项目管理
对同类项目有一致的时间和工作预测
管理和工程化过程都得到规范并被遵守
有用于控制过程的度量标准
适当时候的连续过程改进
改进过程规程
改进过程定义
改进过程度量标准
改进过程变化管理
? 能力成熟度模型 CMM
几种典型的过程改进模型
? ISO9000标准
? 主要承诺：如果过程正确，则该过程的产出
也将是令人满意的
? 没有强制性的或规定的过程
? 组织要记录和整理其所有活动，并为每个过
程规定成文的步骤
项目成败的因素：建模
? 需求工程的作用是捕获系统需求，为系统建模，
并用一种语言表达系统模型
? 语言：支持在描述性语句中捕获过程性含义，
说出什么需要做，而不是怎样去做
? CASE工具：支持模型的协同存取和开发者之间
的合作
? 目前,UML及其工具：
? 支持面向对象风格
? 支持静态结构建模和动态行为建模
总结
? 问题
? 社会系统对软件的依赖越来越
强
? 软件成为任务关键系统的最大
的开销点
? 目前的情况：失败的项目造成
巨大的浪费。比如,1997年
GAO报告,6年浪费
$145billion
? 失败的后果花费很高的代价。
比如,Intel Pentium Bug：
$475million
? 没有“银弹”
? 软件在规模上越来越复杂
? 软件是不可见的和抽象的
? 没有构造性的步骤：软件是可修
改的！
? 但，早期的建模和分析非常重要
? 缺陷发现的越早消除它就越便宜
? 需求缺陷很可能是安全相关的
? 早期的建模和分析还不够
? 需要向每个人传递需求
? 需要得到所有投入者的同意
? 需要理解系统的所处的环境
? 需要理解开发过程所处的环境
? 需要随需求的进化保持不断的更
新
解决方案？
需求工程成为软件工程中的重中之重
什么是需求
用户需要用来求解问题或实现目
标的条件或能力
系统或系统的成分所拥有的条件
或能力，以满足一个合同、标准
、规格说明、或其它形式的文档
。所有需求的集合形成系统或系
统成分的后续开发的基础
从用户的角度
从开发者的角度
需求的重要性
? 工程的观点
? 工程是关于开发针对问题的解决方案的
? 只有当工程师对问题有了充分的理解后，一个好的解决方案才能被开
发出来
? 经济的观点
? 对错误，越长时间没有被检测出来，开销就会越大
? 在维护阶段修正一个需求时的错误，比在需求阶段修正它，代价会增
加 100倍
? 经验的观点
? 未能理解和管理需求是过度开销和不能按时完成等的最大的原因
? 安全性的观点
? 安全相关软件中的错误最经常出自不适当或错误理解的需求
? 与需求相关的困难是在系统测试中发现的安全相关错误的关键根源
什么是需求工程
需求工程是系统工程的一个分支，它涉及到软件系统的
目标、软件系统提供的服务、和对软件系统的约束。需
求工程还涉及这些因素和系统的精确规格说明，系统的
进化等之间的关系
需求工程涉及识别软件系统的目的和软件系统运行的环
境。需求工程提供与软件系统相关的所有用户的现实世
界的需要，和软件技术所能提供的能力之间的一个桥梁
从社会系
统的层次
从软件系
统的层次
需求工程：软件工程还是系统工程
? 窄义地说
? 软件的存在只是为了让硬
件更有用
? 硬件的存在只是为了让软
件可运行
? 软件是混合系统的一个组
件
? 广义地说
? 混合系统的存在是为了实
现用户的某个（某些）现
实的目的
? 是一个更大的社会系统的
一部分
软件总是一个更大的系统的一个组成部分
需求工程：软件工程还是系统工程
? 如果现实系统已经存在
? 软件需求要从用户的需要、硬件的能力中导出，是一
种应用工程
? 如果现实系统要同时被开发
? 软件需求要从现实系统的规格说明中导出
? 现实系统和软件需求必须同步进化
? 现实系统被认为总是可变的
? 是一种系统工程
需求工程还是系统分析
? 系统分析的方法，抽象要点：
? 系统有一定的目标
? 系统与外界之间有边界，并通过边界进行物质或信息
的交换
? 系统可以分成若干相互联系的部分，称之为子系统
? 在各个子系统之间存在各种物质或信息的交换关系
? 系统是分层次的
? 系统是动态的，含自我调节的机制和功能
需求工程还是系统分析
? 需求工程从信息系统分析中成长出来，但是
? 系统分析关注于一个组织中的信息系统
? 已经开发或被采用了的大多数是非形式化的表示法、
工具和方法学，如 DFD,E-R,OO范例
? 经历了广泛的实践，大量通过管理咨询公司
? 教学主要是在管理学、并逐步地在工业工程和计算机
程序设计领域的本科和研究生层次上进行
需求工程还是系统分析
? 需求工程超出了系统分析的范畴
? 研究内容包含了整个的形式化的问题
? 从“业务需要”到“精确的规格说明”
? 研究对象超出了信息系统的范围
? 实时系统
? 嵌入式系统
? 交互式系统
? （但是较少强调管理的问题和业务过程）
需求的种类
? 功能需求：
? 由待开发的软件系统的适当行为（功能性）所满足的需求
? 功能可以分层次描述
? 性能需求：
? 安全性、速度、容量、可用性、可靠性
? 倾向于是一种特别不稳定的需求
? 设计约束：
? 完全的非功能性需求
? 常见的约束：
? 直接约束系统的合成结构
? 约束用于开发系统的过程和技术，只能间接地影响系统的结构
? 商业约束：
? 开发时间、费用与最终的功能性、可靠性、可用性之间的关系
需求的种类：总结
问题
域描
述
（世
界是
怎样
的）
需求（客户想要什么）
商业约
束（时
间和金
钱 ）
设计约
束（如
何构建
系统）
功能的（系统做什么）
一般的
性能
速度 容量 可靠性 可用性
需求工程：位于何处？
? 需求工程在软件工程过程中的位置
瀑布模型
发现的需要
集成
测试
编码
设计
需求
? 开发视点
? 步进求精的过程
? 高层管理的观点
? 问题
? 将需求看成是静态的，忽
略其变化性
? 一旦规格说明写好后，用
户就不能参与
? 对规格说明和设计进行了
不现实的分隔
? 不利于原型、重用、等
原型法生命周期
需求 设计原型 构建原型 测试原型
文档需求 设计 编码 测试 集成
? 原型法用于：
? 理解与用户的接口的需求
? 检测所提出的设计方法的可行性
? 探索系统性能方面的问题
? 问题：
? 用户将原型当作解决方案来看待
? 一个原型只是一个部分的规格说明
分段生命周期模型
需
求
设计 编码 测试 集成
设计 编码 测试 集成
设计 编码 测试 集成
设计 编码 测试 集成
第一次发布
第四次发布
第三次发布
第二次发布
增量式开发（每次发
布增加一些功能）
设计 编码 测试 集成需求
设计 编码 测试 集成需求
设计 编码 测试 集成需求
第一版
第三版
第二版
进化式开发（每个版
本解决新的需求）
螺旋式模型
规划
确定目标、其
它选择、约束
评估其它选
择和风险
开发和
测试
风险分析
风险分析
风险分析
风险分析
原型 原型原型原型预算预算 预算预算
需求生命
周期规划
开发规划
集成和测
试规划
操作的
概念
软件需求
需求有效
性验证
软件设计
验证设计的有
效性和正确性
实现规划
可接受性
测试
系统测试
单元测试
编码
详细设计
其它选择
约束
其它选择
其它选择
约束
约束
其它选择
和约束
螺旋式模型中的需求
? 螺旋式模型是风险管
理模型
? 对每一次迭代：
? 计划下一个阶段
? 决定目的和约束
? 评估其它的选择
? 归结风险
? 开发产品
? 包括为需求过程
? 需求风险分析（采用模拟
和原型法）
? 为设计进行规划（减少由
于需求不能被遇到而需求
过程不得不重复的风险）
? 问题：
? 螺旋式模型不能处理未预
见的开发过程中的变化，
如，新的业务目标的涌现
V-模型
系统需求
软件需求
初步设计
详细设计
编码和
调试
单元测试
组件测试
软件集成
可接受性
测试
系统集成
分析和设计
测试和集成
需求工程过程
? 需求获取：对问题领域及客户需求进行调查，获得关于需求
的信息。三个主要问题：
? 应当收集什么信息
? 能从什么来源中来收集
? 可以通过什么机制或技术来收集
? 需求分析：通过对问题领域的研究，获得对该领域特性及存
在于其中的问题特性的透彻理解。特点：
? 关注于问题领域及其建模，而不是解系统
? 主要目标是获得问题领域及存在于其中的问题本质的理解
? 在本质上先于对目标系统行为的规格说明
? 规格说明：创建并定义目标系统的一种行为，使之在问题领
域中产生所需的效果。特点：
? 创造性的任务，是一个设计任务（但不是内部设计任务）
? 成为投入者之间交流的契约
? 需求验证：试图保证定义了目标系统的正确的功能性
需
求
工
程
是
软
件
工
程
这
个
比
较
大
的
过
程
中
的
一
个
部
分
，
但
本
身
也
是
一
个
过
程
：
需求工程过程：本质
? 理解问题
? 抽取、需求获取、等
? 形式地描述问题
? 规格说明、建模、等
? 获得对问题本质的一致意
见
? 证明有效、矛盾归结、协
商
? 需求管理 —— 维护一个一
致的意见
现实世界
问题陈述
实现陈述
系统
对应性
正确性
有效性验证
正确性验证
问题领域和目标（解）系统
? 问题领域：问题所存在的现实世界中的那个部
分
? 解系统：必须要用于在问题领域内产生某些效
果，从而解决存在的问题
问题
领域
目标
系统
接口
分析 设计规格说明
验证和有效性证明
D R C PS
? 从问题域的角度区分验证和有效性证
明。假设：
? 计算机硬件的特性（ C）
? 程序的特性（ P）
? 应用领域中的机器的特性（规格说明,S）
? 独立于机器的领域的（ D） 特性
? 对机器的需求（ R）
? 证明 P满足 R是
一个两步过程：
? C和 P产生 S？
（ 验证）
? S和 D产生 R？
（ 证明有效）
有效性证明的例子
? 需求 R：
? 只有在飞机在跑道动了的时候 (P),反推力才能发生 (Q)
? 领域特性 D：
? 当且仅当飞机轮子正在旋转 (P1),轮子的脉冲置于 ON(P2)
? 当且仅当飞机在跑道上动了 (P),飞机轮子就在旋转 (P1)
? 规格说明 S：
? 当且仅当轮子的脉冲置于 ON(P2),反推力才能发生 (Q)
? S+D?R
有效性证明的例子
P
P1 PP2 P1
QP2
Q
P P2
问题：如果领域模型错了会怎样呢？
需求和领域工程
? 方法：
? 认识到需求并不是一次性
活动
? 探索同一问题领域中应用
的相似性
? 支持重用
? 需求
? 需求工程跟着领域工程
? 领域工程关注应用之间的
共同点
? ‘问题理解’被约减为领
域模型和特殊应用的需要
之间的映射的过程
? ‘规格说明’由来自一个
可重用的分析构件库中的
合适的构件组成
? 问题
? 领域分析非常昂贵，而且
其效果是滞后的
? 受应用开发的期限的限制
需求工程问题领域的类型
? 平凡的设计 OR革新的设
计
? 平凡的设计：老问题，解
决方案常见
? 工程化将标准的解决方案
整理成了规范
? 工程师选择合适的方法和
技术
? 革新的设计：从没有做过，
或者过去的方案都是失败
的
? 这绝对不属于工程化方法
的范畴
? 需要的软件的类型
? 静态的或动态的？
? 静态的：所有的输入数据在
进程开始之前都有了
? 动态的：数据在进程中连续
到达
? 顺序的或并行的？
? 数据、控制、或算法难的？
? 数据难：复杂的数据在系统
的边界上游动
? 控制难：复杂的控制法则描
述系统应该怎样控制它的环
境
? 算法难：由系统运行的计算
是复杂
? 确定的或非确定的
需求工程项目的类型
? 需求的来源
? 客户驱动 —— 涉及一个特定的客
户，他需要一个系统来解决特定
的问题
? 市场驱动 —— 涉及一个开发商，
他需要开发一个系统到市场上销
售
? 混合型 —— 为一个特定的客户开
发，但想要最后进入市场
? 产品的本质
? 一次性（定做的）还是产品家族
（产品线）
? 新系统还是对存在系统的更新
? 这些问题都会影响需
求的作用
? 作为要被解决的问题
的陈述
? 作为客户和开发者之
间的一个契约
? 作为设计者、客户和
最终用户之间的沟通
? 支持系统的进化
? 支持设计的正确性验
证
软件的类型
? 信息系统
? 支持组织运作的软件
? 包含文件 /数据库，还
有应用
? 有 70%以上的软件是这
种类型的，常常是用
COBOL,RPG或 4GL语
言写成，
? 比如，职工工资、雇
员记录、可支付 /可接
受帐户、客户记录、
事务记录
? 嵌入式系统
? 驱动某种硬件过程的软件，比
如，工厂、电梯系统、信用卡
机器，等
? 通用服务
? 提供某种形式的通用服务的系
统，比如，许多 Internet应用，
远程医疗咨询、远程学习
? 这样的系统将用各种语言和中
间件来开发，比如,Java、
C++,CORBA,HTML/XML、
等
软件工程的本质
什么是需求工程
需求工程在生命周期中的作用
有效性的问题
问题领域的类型
软件开发的本质
? 软件要解决的问题具有：
? 复杂性
? 不一致性
? 可变性
? 不可见性
软件工程固有的困难
软件：是作为一种创造性活动开发出来的产品
是由工匠（而不是艺术家）创作的工艺品或艺术品
软件不是重复性制造活动的产物
存在各种各样的不确定因素
软件开发的不变量
? 软件是开发出来的，不是制造出来的（充满了各种不确
定性）
? 软件工程的进展为开发实践带来了很多确定的因素，但
然不象传统工程那样成功，软件项目的成功仍然无法保
证。
? 算法、代码库、可复用类、软件构件：模块重用
? 商用成品软件：从零开始变成客户化软件
? 各种概念结构：支持从零开始的软件开发
? 但是任何组织不可能找到一个软件包使它的核心业务活
动可以自动生成
三
个
不
同
层
次
上
的
解
决
方
案
项目成败的因素：投入者
? 客户：
? 客户的需要被误解或没有
被完全捕捉
? 客户需求变化得过于频繁
? 客户没有准备为项目提供
足够的资源
? 客户不想与开发者合作
? 客户具有不现实的期望
? 系统不再对客户有利
? 开发人员：
? 不能胜任本项任务
? 开发者的技能和知识
非常关键
? 杰出的设计来自杰出
的设计者
软件系统大部分是社会系统，是由人（开发者）为人
（客户）开发的，软件项目的成功由社会因素确定
项目成败的因素：过程
? 软件开发过程确定以促进开发小组内部合作的活动和组
织的程序，使得能交给客户一个性能优良的产品
? 过程模型包括：
? 说明执行活动的次序
? 说明需要交出什么样的制品，以及什么时候交出
? 将活动和制品交给开发者
? 提供监控项目进程、评估产出和计划未来项目的准则
? 每个组织都有自己的过程，或客户化一个通用过程模板
几种典型的过程改进模型
? 迭代增量式开发：
? 迭代涉及管理可执行的版本流的过程；
? 增量涉及系统结构连续继承以产生这些版本
的过程；
? 关键：系统划分的规模和模块间的偶合度
几种典型的过程改进模型
第一级
初始级
第五级
优化
第四级
已管理
第三级
已定义
第二级
可重复
依赖当前员工的不可预测和无规程的过程
可重复的项目管理
对同类项目有一致的时间和工作预测
管理和工程化过程都得到规范并被遵守
有用于控制过程的度量标准
适当时候的连续过程改进
改进过程规程
改进过程定义
改进过程度量标准
改进过程变化管理
? 能力成熟度模型 CMM
几种典型的过程改进模型
? ISO9000标准
? 主要承诺：如果过程正确，则该过程的产出
也将是令人满意的
? 没有强制性的或规定的过程
? 组织要记录和整理其所有活动，并为每个过
程规定成文的步骤
项目成败的因素：建模
? 需求工程的作用是捕获系统需求，为系统建模，
并用一种语言表达系统模型
? 语言：支持在描述性语句中捕获过程性含义，
说出什么需要做，而不是怎样去做
? CASE工具：支持模型的协同存取和开发者之间
的合作
? 目前,UML及其工具：
? 支持面向对象风格
? 支持静态结构建模和动态行为建模
总结
? 问题
? 社会系统对软件的依赖越来越
强
? 软件成为任务关键系统的最大
的开销点
? 目前的情况：失败的项目造成
巨大的浪费。比如,1997年
GAO报告,6年浪费
$145billion
? 失败的后果花费很高的代价。
比如,Intel Pentium Bug：
$475million
? 没有“银弹”
? 软件在规模上越来越复杂
? 软件是不可见的和抽象的
? 没有构造性的步骤：软件是可修
改的！
? 但，早期的建模和分析非常重要
? 缺陷发现的越早消除它就越便宜
? 需求缺陷很可能是安全相关的
? 早期的建模和分析还不够
? 需要向每个人传递需求
? 需要得到所有投入者的同意
? 需要理解系统的所处的环境
? 需要理解开发过程所处的环境
? 需要随需求的进化保持不断的更
新
解决方案？
需求工程成为软件工程中的重中之重
什么是需求
用户需要用来求解问题或实现目
标的条件或能力
系统或系统的成分所拥有的条件
或能力，以满足一个合同、标准
、规格说明、或其它形式的文档
。所有需求的集合形成系统或系
统成分的后续开发的基础
从用户的角度
从开发者的角度
需求的重要性
? 工程的观点
? 工程是关于开发针对问题的解决方案的
? 只有当工程师对问题有了充分的理解后，一个好的解决方案才能被开
发出来
? 经济的观点
? 对错误，越长时间没有被检测出来，开销就会越大
? 在维护阶段修正一个需求时的错误，比在需求阶段修正它，代价会增
加 100倍
? 经验的观点
? 未能理解和管理需求是过度开销和不能按时完成等的最大的原因
? 安全性的观点
? 安全相关软件中的错误最经常出自不适当或错误理解的需求
? 与需求相关的困难是在系统测试中发现的安全相关错误的关键根源
什么是需求工程
需求工程是系统工程的一个分支，它涉及到软件系统的
目标、软件系统提供的服务、和对软件系统的约束。需
求工程还涉及这些因素和系统的精确规格说明，系统的
进化等之间的关系
需求工程涉及识别软件系统的目的和软件系统运行的环
境。需求工程提供与软件系统相关的所有用户的现实世
界的需要，和软件技术所能提供的能力之间的一个桥梁
从社会系
统的层次
从软件系
统的层次
需求工程：软件工程还是系统工程
? 窄义地说
? 软件的存在只是为了让硬
件更有用
? 硬件的存在只是为了让软
件可运行
? 软件是混合系统的一个组
件
? 广义地说
? 混合系统的存在是为了实
现用户的某个（某些）现
实的目的
? 是一个更大的社会系统的
一部分
软件总是一个更大的系统的一个组成部分
需求工程：软件工程还是系统工程
? 如果现实系统已经存在
? 软件需求要从用户的需要、硬件的能力中导出，是一
种应用工程
? 如果现实系统要同时被开发
? 软件需求要从现实系统的规格说明中导出
? 现实系统和软件需求必须同步进化
? 现实系统被认为总是可变的
? 是一种系统工程
需求工程还是系统分析
? 系统分析的方法，抽象要点：
? 系统有一定的目标
? 系统与外界之间有边界，并通过边界进行物质或信息
的交换
? 系统可以分成若干相互联系的部分，称之为子系统
? 在各个子系统之间存在各种物质或信息的交换关系
? 系统是分层次的
? 系统是动态的，含自我调节的机制和功能
需求工程还是系统分析
? 需求工程从信息系统分析中成长出来，但是
? 系统分析关注于一个组织中的信息系统
? 已经开发或被采用了的大多数是非形式化的表示法、
工具和方法学，如 DFD,E-R,OO范例
? 经历了广泛的实践，大量通过管理咨询公司
? 教学主要是在管理学、并逐步地在工业工程和计算机
程序设计领域的本科和研究生层次上进行
需求工程还是系统分析
? 需求工程超出了系统分析的范畴
? 研究内容包含了整个的形式化的问题
? 从“业务需要”到“精确的规格说明”
? 研究对象超出了信息系统的范围
? 实时系统
? 嵌入式系统
? 交互式系统
? （但是较少强调管理的问题和业务过程）
需求的种类
? 功能需求：
? 由待开发的软件系统的适当行为（功能性）所满足的需求
? 功能可以分层次描述
? 性能需求：
? 安全性、速度、容量、可用性、可靠性
? 倾向于是一种特别不稳定的需求
? 设计约束：
? 完全的非功能性需求
? 常见的约束：
? 直接约束系统的合成结构
? 约束用于开发系统的过程和技术，只能间接地影响系统的结构
? 商业约束：
? 开发时间、费用与最终的功能性、可靠性、可用性之间的关系
需求的种类：总结
问题
域描
述
（世
界是
怎样
的）
需求（客户想要什么）
商业约
束（时
间和金
钱 ）
设计约
束（如
何构建
系统）
功能的（系统做什么）
一般的
性能
速度 容量 可靠性 可用性
需求工程：位于何处？
? 需求工程在软件工程过程中的位置
瀑布模型
发现的需要
集成
测试
编码
设计
需求
? 开发视点
? 步进求精的过程
? 高层管理的观点
? 问题
? 将需求看成是静态的，忽
略其变化性
? 一旦规格说明写好后，用
户就不能参与
? 对规格说明和设计进行了
不现实的分隔
? 不利于原型、重用、等
原型法生命周期
需求 设计原型 构建原型 测试原型
文档需求 设计 编码 测试 集成
? 原型法用于：
? 理解与用户的接口的需求
? 检测所提出的设计方法的可行性
? 探索系统性能方面的问题
? 问题：
? 用户将原型当作解决方案来看待
? 一个原型只是一个部分的规格说明
分段生命周期模型
需
求
设计 编码 测试 集成
设计 编码 测试 集成
设计 编码 测试 集成
设计 编码 测试 集成
第一次发布
第四次发布
第三次发布
第二次发布
增量式开发（每次发
布增加一些功能）
设计 编码 测试 集成需求
设计 编码 测试 集成需求
设计 编码 测试 集成需求
第一版
第三版
第二版
进化式开发（每个版
本解决新的需求）
螺旋式模型
规划
确定目标、其
它选择、约束
评估其它选
择和风险
开发和
测试
风险分析
风险分析
风险分析
风险分析
原型 原型原型原型预算预算 预算预算
需求生命
周期规划
开发规划
集成和测
试规划
操作的
概念
软件需求
需求有效
性验证
软件设计
验证设计的有
效性和正确性
实现规划
可接受性
测试
系统测试
单元测试
编码
详细设计
其它选择
约束
其它选择
其它选择
约束
约束
其它选择
和约束
螺旋式模型中的需求
? 螺旋式模型是风险管
理模型
? 对每一次迭代：
? 计划下一个阶段
? 决定目的和约束
? 评估其它的选择
? 归结风险
? 开发产品
? 包括为需求过程
? 需求风险分析（采用模拟
和原型法）
? 为设计进行规划（减少由
于需求不能被遇到而需求
过程不得不重复的风险）
? 问题：
? 螺旋式模型不能处理未预
见的开发过程中的变化，
如，新的业务目标的涌现
V-模型
系统需求
软件需求
初步设计
详细设计
编码和
调试
单元测试
组件测试
软件集成
可接受性
测试
系统集成
分析和设计
测试和集成
需求工程过程
? 需求获取：对问题领域及客户需求进行调查，获得关于需求
的信息。三个主要问题：
? 应当收集什么信息
? 能从什么来源中来收集
? 可以通过什么机制或技术来收集
? 需求分析：通过对问题领域的研究，获得对该领域特性及存
在于其中的问题特性的透彻理解。特点：
? 关注于问题领域及其建模，而不是解系统
? 主要目标是获得问题领域及存在于其中的问题本质的理解
? 在本质上先于对目标系统行为的规格说明
? 规格说明：创建并定义目标系统的一种行为，使之在问题领
域中产生所需的效果。特点：
? 创造性的任务，是一个设计任务（但不是内部设计任务）
? 成为投入者之间交流的契约
? 需求验证：试图保证定义了目标系统的正确的功能性
需
求
工
程
是
软
件
工
程
这
个
比
较
大
的
过
程
中
的
一
个
部
分
，
但
本
身
也
是
一
个
过
程
：
需求工程过程：本质
? 理解问题
? 抽取、需求获取、等
? 形式地描述问题
? 规格说明、建模、等
? 获得对问题本质的一致意
见
? 证明有效、矛盾归结、协
商
? 需求管理 —— 维护一个一
致的意见
现实世界
问题陈述
实现陈述
系统
对应性
正确性
有效性验证
正确性验证
问题领域和目标（解）系统
? 问题领域：问题所存在的现实世界中的那个部
分
? 解系统：必须要用于在问题领域内产生某些效
果，从而解决存在的问题
问题
领域
目标
系统
接口
分析 设计规格说明
验证和有效性证明
D R C PS
? 从问题域的角度区分验证和有效性证
明。假设：
? 计算机硬件的特性（ C）
? 程序的特性（ P）
? 应用领域中的机器的特性（规格说明,S）
? 独立于机器的领域的（ D） 特性
? 对机器的需求（ R）
? 证明 P满足 R是
一个两步过程：
? C和 P产生 S？
（ 验证）
? S和 D产生 R？
（ 证明有效）
有效性证明的例子
? 需求 R：
? 只有在飞机在跑道动了的时候 (P),反推力才能发生 (Q)
? 领域特性 D：
? 当且仅当飞机轮子正在旋转 (P1),轮子的脉冲置于 ON(P2)
? 当且仅当飞机在跑道上动了 (P),飞机轮子就在旋转 (P1)
? 规格说明 S：
? 当且仅当轮子的脉冲置于 ON(P2),反推力才能发生 (Q)
? S+D?R
有效性证明的例子
P
P1 PP2 P1
QP2
Q
P P2
问题：如果领域模型错了会怎样呢？
需求和领域工程
? 方法：
? 认识到需求并不是一次性
活动
? 探索同一问题领域中应用
的相似性
? 支持重用
? 需求
? 需求工程跟着领域工程
? 领域工程关注应用之间的
共同点
? ‘问题理解’被约减为领
域模型和特殊应用的需要
之间的映射的过程
? ‘规格说明’由来自一个
可重用的分析构件库中的
合适的构件组成
? 问题
? 领域分析非常昂贵，而且
其效果是滞后的
? 受应用开发的期限的限制
需求工程问题领域的类型
? 平凡的设计 OR革新的设
计
? 平凡的设计：老问题，解
决方案常见
? 工程化将标准的解决方案
整理成了规范
? 工程师选择合适的方法和
技术
? 革新的设计：从没有做过，
或者过去的方案都是失败
的
? 这绝对不属于工程化方法
的范畴
? 需要的软件的类型
? 静态的或动态的？
? 静态的：所有的输入数据在
进程开始之前都有了
? 动态的：数据在进程中连续
到达
? 顺序的或并行的？
? 数据、控制、或算法难的？
? 数据难：复杂的数据在系统
的边界上游动
? 控制难：复杂的控制法则描
述系统应该怎样控制它的环
境
? 算法难：由系统运行的计算
是复杂
? 确定的或非确定的
需求工程项目的类型
? 需求的来源
? 客户驱动 —— 涉及一个特定的客
户，他需要一个系统来解决特定
的问题
? 市场驱动 —— 涉及一个开发商，
他需要开发一个系统到市场上销
售
? 混合型 —— 为一个特定的客户开
发，但想要最后进入市场
? 产品的本质
? 一次性（定做的）还是产品家族
（产品线）
? 新系统还是对存在系统的更新
? 这些问题都会影响需
求的作用
? 作为要被解决的问题
的陈述
? 作为客户和开发者之
间的一个契约
? 作为设计者、客户和
最终用户之间的沟通
? 支持系统的进化
? 支持设计的正确性验
证
软件的类型
? 信息系统
? 支持组织运作的软件
? 包含文件 /数据库，还
有应用
? 有 70%以上的软件是这
种类型的，常常是用
COBOL,RPG或 4GL语
言写成，
? 比如，职工工资、雇
员记录、可支付 /可接
受帐户、客户记录、
事务记录
? 嵌入式系统
? 驱动某种硬件过程的软件，比
如，工厂、电梯系统、信用卡
机器，等
? 通用服务
? 提供某种形式的通用服务的系
统，比如，许多 Internet应用，
远程医疗咨询、远程学习
? 这样的系统将用各种语言和中
间件来开发，比如,Java、
C++,CORBA,HTML/XML、
等
