3 软件需求工程
3.1 软件需求分析
需求分析是对系统的理解与表达
的过程，是一种软件工程的活动。
一、软件需求的层次
1、业务需求
反映了机构或客户对系统、产品
高层的目标要求。
2、用户需求
描述了用户使用产品需要完成的
任务。
软
件
工
程
原
理
2、功能需求
定义了开发人员必须实现的软件功
能。
功能需求要具有全面性和一致性。
3、非功能需求
所谓非功能性需求是不直接与系统
具体功能相关的一类需求。（例如：
可靠性、响应时间、存储空间等）
4、领域需求
来自系统的应用领域的需求，反映
了该领域的特点。
软
件
工
程
原
理
软
件
工
程
原
理
业务需求
用户需求 质量属性
功能需求
系统需求
约束条件
其它非功
能需求
项目视图与范围文档
使用实例文档
软件需求规格说明
软件需求各组成部分之间的关系
二、需求工程
需求工程是一个包括创建和维护
系统需求所必需的一切活动过程。
可分为：需求开发和需求管理。
三、需求分析原则
1、理解和表示问题的信息域，用 数
据模型 描述；
2、定义软件将完成的功能，用 功能
模型 描述；
3、表示软件的行为（服务、操作），
用 行为模型 描述；
软
件
工
程
原
理
4、对描述的数据、功能和行为模型
必须被划分，使分析模型可以用层次
的方法展示细节；
5、分析过程应该从要素信息移到实
现细节。可采用 逐步求精 的技术。
四、需求分析的任务
需求分析的任务就是借助于当前系
统的逻辑模型导出目标系统的逻辑模
型。主要有 两个任务, 1、建立分析
模型； 2、编写需求说明书。
其实现模型如下图所示：
软
件
工
程
原
理
目标系统
当前系统
物理模型 逻辑模型
逻辑模型物理模型
模型化
抽象化
实例化
具体化
理
解
需
求
表
达
需
求
导
出
做什么
怎
么
做
软
件
工
程
原
理
软
件
工
程
原
理
学
生
张
秘书
王
会计
李
出纳
赵
保管
学
生
学生购买教材的物理模型
购书
申请
购书
证明
购书发票
领书单 书
软
件
工
程
原
理
学
生
审查有
效性
开
发票
开
领书单 发书
学
生
购书单 有效
购书单
领书单 书
发票
学生购买教材的逻辑模型
学
生
审查并
开发票
开
领书单
发书 学生
购书单 发票
领书单
书
计算机售书系统的逻辑模型
软
件
工
程
原
理
软
件
工
程
原
理
学
生
审查并
开发票
开
领书单
学
生
购书单 发票 领书单
改进了的计算机售书系统模型
无效书单
五、需求开发过程 (即,需求分析步骤 )
1、问题获取（或需求获取）
要获取的需求有：
（ 1）功能需求；
（ 2）性能需求；
（ 3）环境需求；
（ 4）安全保密要求；
（ 5）用户界面需求；
（ 6）资源使用需求；
（ 7）软件成本消耗与开发进度需求。
需求获取的常用方法：
软
件
工
程
原
理
软
件
工
程
原
理
（ 1）常规的需求获取方法：
a）建立联合分析小组（成员有：
用户、系统分析员和领域专家）
b）客户访谈（深入现场，直接与
客户进行交流）
c）问题分析与确认（访谈后进行
分析、整理，让用户进行确认）
（ 2）快速原型法
步骤：生成简化的需求规格说明；
检查、修改后，确定原型有关结构；
生成原型并进行测试、改进；交付原
型，征求用户意见，反复修改，直至
用户确认。
2、需求分析
常用的分析方法有：
（ 1）面向数据流的结构化分析方法
（简称 SA）；
（ 2）面向数据结构的 Jackson方法
（简称 JSD）；
（ 3）面向对象的分析方法；
（ 4）状态迁移图或 Petri网等。
3、编写需求规格说明
4、需求评审
软
件
工
程
原
理
软
件
工
程
原
理
3.2 软件需求建模
一、软件建模
所谓 模型,就是为了理解事物而
对事物做出的一种抽象，是对事物
的一种无歧义的书面描述。简单地
说,模型就是某一事物的抽象表示
方式 。
经过软件的需求分析建立起来的
模型可以称之为 分析模型 或者 需求
模型 。
软
件
工
程
原
理
需求分析模型：
数据字典
功能模型
行为模型
数据模型
软
件
工
程
原
理
一般情况，均介绍两种需求分析模型：
（ 1）结构化分析模型
数据对 加工
象说明 说明
控制说明
E-R图 DFD图
STD图
DD
软
件
工
程
原
理
（ 2）面向对象分析模型
属性、操作、协作者
类／对象 对象 -关
模型 系模型
对象 -行为模型
使用
实例
软
件
工
程
原
理
1、数据模型
包含有 3种相关的信息：
（ 1）数据对象
数据对象是几乎所有必须被软件理
解的 复合信息 的表示。它只封装数据，
不包含作用于对象的操作。
（ 2）属性
属性定义了数据对象的性质。
（ 3）关系
数据对象彼此之间是有关联的，也
称为关系。
软
件
工
程
原
理
数据模型常常用, 实体 -关系图
(ERD)” 来描述。
ERD包含 3种基本元素，即实
体、属性和关系。
通常，用 矩形 表示即 数据对象,
用 圆角矩形或椭圆形 表示实体的
属性,用 菱形 连接相关实体表示
关系 。
下图是一个简化的教学管理
ERD：
软
件
工
程
原
理
性别 职称
姓名
教工号
姓名 性别 系
学号 年级
课程号 课程名 学时 学分
课程
教师 学生
教 学
软
件
工
程
原
理
数据对象 之间数量上的对应关系
如下面几种：
0:1 1:1
0:m 1:m
软
件
工
程
原
理
电话机 生产厂商
用户 经销商
生产
使用
购买
经销
软
件
工
程
原
理
电话机
话筒 话机
按键 连接线
E-R图也可表示数据对象间的 整体
与部分关系、一般与特殊关系。
E-R图表示整体与部分关系
软
件
工
程
原
理
书
教科书 课外辅导书 杂志
E-R图表示一般与特殊关系
2、功能模型
功能模型可以用数据流图 (DFD)
描述，所以又称为 数据流模型 。
下面是数据流图的基本形式：
软
件
工
程
原
理
3
变换
4
变换
1
变换
2
变换
外部
实体
外部
实体
外部
实体
外部
实体数据文件
输入数据
中间数据
输出数据
学
生
1
审查
开发票
2
开领书
单
学
生
购书单 发票 领书单
计算机售书系统的数据流图
无效书单软
件
工
程
原
理
各班学生用书表 教材存量表
软
件
工
程
原
理
3、行为模型
行为模型常用 状态转换图 （ 简称状
态图 ）来描述，它又称为 状态机模型 。
状态图中的基本元素有 事件, 状态
和 行为 等。
系统的状态机模型 可以理解为在任
一个时刻，系统处于有限可能的状态
中的一个状态，当某一个激励（条件）
到达时，它激发系统从一个状态转换
到另一个新状态。
下面是电话系统的状态图：
软
件
工
程
原
理
闲置
拨号音
do:响拨号音
超时
do:响蜂鸣音
存储的信息
do:播放信息接通中do:试接通
振铃
do:振铃
拨号
通话
断线
忙音
do:响忙音
挂断电话 挂断电话
拿起话筒 超时
无效号码
有效号码
超时数字数字
占线
已接通
受话人回话
受话人挂断电话
信
息
播
完
软
件
工
程
原
理
二、数据字典
数据字典 (Data Dictionary)用于描述
软件系统中使用或者产生的每一个数据
元素，是系统数据信息定义的集合。
数据字典的 作用,就是对软件中的每
个数据规定一个定义条目，以 保持数据
在系统中的一致性 。
软件中的数据，可分为三种情况：
① 只含一个数据的 数据项 (或数据元素 )；
② 由多个相关数据项组成的 数据流 ；
③ 数据文件或数据库 。
软
件
工
程
原
理
数据流, 发票, 的字典条目
数据流名：发票
别 名：购书发票
组 成：
学名＋姓名＋｛书号＋单价＋数量
＋总价｝＋书费合计
备 注：
软
件
工
程
原
理
数据文件, 各班学生用书表, 的字典条
目
文件名：各班学生用书表
别 名：
组 成：
｛系编号＋专业和班编号＋年级＋
｛书号｝｝
组 织：
按系、专业和班编号从小到大排列
备 注：
软
件
工
程
原
理
数据项, 数量, 的字典条目
数据项名：数量
别 名：购书量
取 值：正整数
备 注：
软
件
工
程
原
理
三、面向对象模型
一般情况下,OOA总是从理解系统
的, 使用实例 (简称用例 )”开始,基本步
骤 为：定义系统的 用例,在领域分析的
基础上建立问题域的 类－对象模型,然
后建立 对象－关系和对象－行为模型 。
在面向对象软件工程中，对象建模技
术 OMT(Object Modeling Technique)
是常用的方法和技术之一。
按照 OMT，分析模型有 3个子模型：
对象模型、动态模型和功能模型。
软
件
工
程
原
理
签定保险单
销售统计
客户统计客户 保险销售员
保险商务系统的用例图
保险商务系统
软
件
工
程
原
理
（ 1）对象模型 (Object Model)。描述
工具是 对象图 。用于描述对象的定义、
对象的属性、对象的运算、对象之间
的关系等。
学生
学号
班级
上课
考试
李平,学生
学号,020118
班级,计 02
上课
考试
类／对象图
软
件
工
程
原
理
规格
对象－关系图
部门 流水线
工序
不良品 材料 在制品
实时数据 指标数据
1:1
1:m
1:1
1:1
1:1 1:m
1:m
1:1
1:1 1:1
1:m0:m
1:1
1:m
1:1
1:m
0:m 1:1
1:1
1:m
0:1
1:1 1:1 0:1
软
件
工
程
原
理
（ 2）动态模型 (Dynamic Model)。描
述工具是 状态图 。用于描述系统的控
制结构、动态行为，即执行操作。
产生 半分钟数据
班数据
日数据
半小时数据
翻屏显示
实时数据状态转换图
光电采集 满半分钟
班数据处理
工控机处理
日数据处理
软
件
工
程
原
理
光电管 PLC 工控机 大屏幕
[半分钟到 ]
传累计值
物品经过
阻态信号
[半小时到 ]
显示数据
光电管实时数据采集部分 事件轨迹图
软
件
工
程
原
理
（ 3）功能模型 (Runction Model)。描
述工具是 数据流图 。用于描述系统的计
算结构、数据变换、数据流动的情形等
功能关系。
软
件
工
程
原
理
3.3 软件需求规格与评审
软件需求规格 SRS也称为 功能规格
说明、需求协议以及系统规格说明 等，
它是需求开发任务的最终产物。 P51
SRS可用 3种方法来描述：
（ 1）用结构化和自然语言编写文本
型文档；
（ 2）建立图形化模型；
（ 3）用形式化语言编写。
软
件
工
程
原
理
软件需求规格说明在编写后，要经
过评审和修改，最终行成一份正式的
文档，供用户、分析员、软件设计人
员等相关人员进行参考。
评审时有几项 指标,正确性、无岐
义性、完全性、可验证性、一致性、
可理解性、可修改性、可追踪性等。
软
件
工
程
原
理
3.4 需求管理
一、需求管理概述
需求管理是一个对系统需求变更、
了解和控制的过程。它与需求开发过程
相互关联,一旦形成了需求文档的初稿，
需求管理活动就开始了 。
需求管理强调：
（ 1）控制对需求基线的变动；
（ 2）保持项目计划与需求一致；
（ 3）控制单个需求和需求文档的版本
情况；
（ 4）管理需求和联系链，或者管理单
个需求和其他项目可交付产品之间的依
赖关系；
（ 5）跟踪基线中的需求状态。
需求管理的主要活动如下图所示：
软
件
工
程
原
理
软
件
工
程
原
理
需求管理
变更控制
?建议变更
?分析影响
?做出决策
?交流
?合并
?测量需求
的稳定性
版本控制
?确定需求
文档版本
?确定单个
需求文档
版本
需求跟踪
?定义对其
他需求的
连接链
?定义对其
他系统元
素的连接
链
需求状态跟踪
?定义需求状
态
?跟踪需求每
一个状态
软
件
工
程
原
理
1、需求管理原则
过程能力成熟度模型 (CMM)是在软件
开发机构中被广泛用来指导软件过程改
进。该模型描述了软件处理能力的 5个
成熟级别（ 初始级、可重复级、已定义
级、已管理级和优化级 ）。为了达到过
程能力成熟度模型的第二级，组织机构
必须具有 6个关键过程域 KPA( Key
Process Areas )。需求管理是其中之
一，它的目标是：
软
件
工
程
原
理
（ 1）为软件需求建立一个 基线,提供
给软件工程管理使用；
（ 2）软件计划、产品和活动与软件需
求保持一致。
2、需求规格说明的版本控制
版本控制是管理需求的一个必要方
面。软件开发组的每一个成员必须得
到需求的 当前版本 。
3、需求属性
除了文本，每一个功能需求应该有
一些相关的信息与它联系，这些信息
称为需求属性。
二、需求变更
为了使开发组织能够严格控制软件项
目，应该确保以下事项：
（ 1）仔细 评估 已建议的变更；
（ 2）挑选合适的 人选 对变更做出决定；
（ 3）变更应及时 通知 所有涉及的人员；
（ 4）项目要按一定的 程序 来采纳需求
变更。
1、变更控制过程
一个好的变更控制过程，给项目风险
软
件
工
程
原
理
软
件
工
程
原
理
承担者提供了正式的建议需求变更机制。
变更控制过程 如下图所示：
问题分析和变更描述
变更分析和成本计算
变更实现
识别出问题
修改后的需求
软
件
工
程
原
理
2、需求变更策略（参考）
（ 1）所有需求变更必须遵循变更控制过
程；
（ 2）对于未获得批准的变更，不应该做
设计和实现工作；
（ 3）变更应该由项目变更控制委员会决
定实现哪些变更；
（ 4）项目风险承担者应该能够了解变更
数据库的内容；
（ 5）决不能从数据库中删除或者修改变
更请求的原始文档；
（ 6）每一个集成的需求变更必须能跟踪
到一个经核准的变更请求。
软
件
工
程
原
理
3、变更控制委员会
变更控制委员会负责决定哪些已建议
需求变更或者新产品特性付诸应用，决
定在哪些版本中纠正哪些错误。
变更委员会可能包括如下方面的代表：
（ 1）产品或计划管理部门；
（ 2）项目管理部门；
（ 3）开发部门；
（ 4）测试或质量保证部门；
（ 5）市场部或客户代表；
（ 6）制作用户文档的部门；
（ 7）技术支持部门；
（ 8）帮助桌面或用户支持热线部门；
软
件
工
程
原
理
（ 9）配置管理部门。
三、需求跟踪
需求跟踪包括编制每个 需求 同 系统
元素 之间的 联系文档,这些元素包括
别的需求、体系结构、其他设计部件、
源代码模块、测试、帮助文件和文档
等。跟踪能力信息使变更影响分析十
分便利，有利于确认和评估实现某个
建议的需求变更所必须的工作。
跟踪能力（联系）链 ( Trace ability
Link )可以使我们跟踪一个需求使用
期限的全过程。
软
件
工
程
原
理
跟踪能力链有 4类，如图所示：
客户需求 软件需求 下一级工作产品①② ④③
图中：
① 客户需求向前追溯到软件需求。
② 从软件需求回溯相应的客户需求。
③ 从软件需求向前追溯到下一级工
作产品。
④ 从产品部件回溯到软件需求。
软
件
工
程
原
理
四、需求变更的代价和风险
变更需求是要付出代价的，只要允
许软件需求变更或者添加新特性，一
个表面上很简单的变更也可能转变成
很复杂的局面。
需求变更 对软件的 进度、成本、技
术、效率 都会有不同程度的影响，变
更只能在项目时间、预算、资源等的
限制内进行协商。
影响分析 是需求管理的一个重要组
成部分。进行影响分析的能力依赖于
跟踪能力、数据的质量和完整性。
软
件
工
程
原
理
3.5 软件需求分析与需求管理工具
(略 )
一、软件需求分析工具
CASE2000,系统分析组 SUITE
AnalistStudio等。
二、需求管理工具
软
件
工
程
原
理
课堂练习：
有一个小型数据库系统，具有
身份验证、查询（根据某一特征）、
添加数据、修改数据、删除数据、
数据合并、输出数据等功能。
要求：对该系统进行分析后，
画出该系统的数据流图。
软
件
工
程
原
理
1
身份验证
用
户
2
数据
查询
用户信息 非法用户
3
数据
添加
4
数据
修改
5
数据
删除
6
数据
合并
合法用户
合法用户
合法用户
合法用户 合法用户
数据库文件
7
数据
输出
用
户
输出数据
软
件
工
程
原
理
2
数据库管理
用
户
用户信息
用
户
输出数据
数据流图（顶层）
1
身份验证
非法用户
合法用户
软
件
工
程
原
理
合法用户
数据库文件
2.1
数据
查询
2.2
数据
添加
2.3
数据
修改
2.4
数据
删除
2.5
数据
合并
2.6
数据
输出
输出数据
数据流图（ 1层）
3.1 软件需求分析
需求分析是对系统的理解与表达
的过程，是一种软件工程的活动。
一、软件需求的层次
1、业务需求
反映了机构或客户对系统、产品
高层的目标要求。
2、用户需求
描述了用户使用产品需要完成的
任务。
软
件
工
程
原
理
2、功能需求
定义了开发人员必须实现的软件功
能。
功能需求要具有全面性和一致性。
3、非功能需求
所谓非功能性需求是不直接与系统
具体功能相关的一类需求。（例如：
可靠性、响应时间、存储空间等）
4、领域需求
来自系统的应用领域的需求，反映
了该领域的特点。
软
件
工
程
原
理
软
件
工
程
原
理
业务需求
用户需求 质量属性
功能需求
系统需求
约束条件
其它非功
能需求
项目视图与范围文档
使用实例文档
软件需求规格说明
软件需求各组成部分之间的关系
二、需求工程
需求工程是一个包括创建和维护
系统需求所必需的一切活动过程。
可分为：需求开发和需求管理。
三、需求分析原则
1、理解和表示问题的信息域，用 数
据模型 描述；
2、定义软件将完成的功能，用 功能
模型 描述；
3、表示软件的行为（服务、操作），
用 行为模型 描述；
软
件
工
程
原
理
4、对描述的数据、功能和行为模型
必须被划分，使分析模型可以用层次
的方法展示细节；
5、分析过程应该从要素信息移到实
现细节。可采用 逐步求精 的技术。
四、需求分析的任务
需求分析的任务就是借助于当前系
统的逻辑模型导出目标系统的逻辑模
型。主要有 两个任务, 1、建立分析
模型； 2、编写需求说明书。
其实现模型如下图所示：
软
件
工
程
原
理
目标系统
当前系统
物理模型 逻辑模型
逻辑模型物理模型
模型化
抽象化
实例化
具体化
理
解
需
求
表
达
需
求
导
出
做什么
怎
么
做
软
件
工
程
原
理
软
件
工
程
原
理
学
生
张
秘书
王
会计
李
出纳
赵
保管
学
生
学生购买教材的物理模型
购书
申请
购书
证明
购书发票
领书单 书
软
件
工
程
原
理
学
生
审查有
效性
开
发票
开
领书单 发书
学
生
购书单 有效
购书单
领书单 书
发票
学生购买教材的逻辑模型
学
生
审查并
开发票
开
领书单
发书 学生
购书单 发票
领书单
书
计算机售书系统的逻辑模型
软
件
工
程
原
理
软
件
工
程
原
理
学
生
审查并
开发票
开
领书单
学
生
购书单 发票 领书单
改进了的计算机售书系统模型
无效书单
五、需求开发过程 (即,需求分析步骤 )
1、问题获取（或需求获取）
要获取的需求有：
（ 1）功能需求；
（ 2）性能需求；
（ 3）环境需求；
（ 4）安全保密要求；
（ 5）用户界面需求；
（ 6）资源使用需求；
（ 7）软件成本消耗与开发进度需求。
需求获取的常用方法：
软
件
工
程
原
理
软
件
工
程
原
理
（ 1）常规的需求获取方法：
a）建立联合分析小组（成员有：
用户、系统分析员和领域专家）
b）客户访谈（深入现场，直接与
客户进行交流）
c）问题分析与确认（访谈后进行
分析、整理，让用户进行确认）
（ 2）快速原型法
步骤：生成简化的需求规格说明；
检查、修改后，确定原型有关结构；
生成原型并进行测试、改进；交付原
型，征求用户意见，反复修改，直至
用户确认。
2、需求分析
常用的分析方法有：
（ 1）面向数据流的结构化分析方法
（简称 SA）；
（ 2）面向数据结构的 Jackson方法
（简称 JSD）；
（ 3）面向对象的分析方法；
（ 4）状态迁移图或 Petri网等。
3、编写需求规格说明
4、需求评审
软
件
工
程
原
理
软
件
工
程
原
理
3.2 软件需求建模
一、软件建模
所谓 模型,就是为了理解事物而
对事物做出的一种抽象，是对事物
的一种无歧义的书面描述。简单地
说,模型就是某一事物的抽象表示
方式 。
经过软件的需求分析建立起来的
模型可以称之为 分析模型 或者 需求
模型 。
软
件
工
程
原
理
需求分析模型：
数据字典
功能模型
行为模型
数据模型
软
件
工
程
原
理
一般情况，均介绍两种需求分析模型：
（ 1）结构化分析模型
数据对 加工
象说明 说明
控制说明
E-R图 DFD图
STD图
DD
软
件
工
程
原
理
（ 2）面向对象分析模型
属性、操作、协作者
类／对象 对象 -关
模型 系模型
对象 -行为模型
使用
实例
软
件
工
程
原
理
1、数据模型
包含有 3种相关的信息：
（ 1）数据对象
数据对象是几乎所有必须被软件理
解的 复合信息 的表示。它只封装数据，
不包含作用于对象的操作。
（ 2）属性
属性定义了数据对象的性质。
（ 3）关系
数据对象彼此之间是有关联的，也
称为关系。
软
件
工
程
原
理
数据模型常常用, 实体 -关系图
(ERD)” 来描述。
ERD包含 3种基本元素，即实
体、属性和关系。
通常，用 矩形 表示即 数据对象,
用 圆角矩形或椭圆形 表示实体的
属性,用 菱形 连接相关实体表示
关系 。
下图是一个简化的教学管理
ERD：
软
件
工
程
原
理
性别 职称
姓名
教工号
姓名 性别 系
学号 年级
课程号 课程名 学时 学分
课程
教师 学生
教 学
软
件
工
程
原
理
数据对象 之间数量上的对应关系
如下面几种：
0:1 1:1
0:m 1:m
软
件
工
程
原
理
电话机 生产厂商
用户 经销商
生产
使用
购买
经销
软
件
工
程
原
理
电话机
话筒 话机
按键 连接线
E-R图也可表示数据对象间的 整体
与部分关系、一般与特殊关系。
E-R图表示整体与部分关系
软
件
工
程
原
理
书
教科书 课外辅导书 杂志
E-R图表示一般与特殊关系
2、功能模型
功能模型可以用数据流图 (DFD)
描述，所以又称为 数据流模型 。
下面是数据流图的基本形式：
软
件
工
程
原
理
3
变换
4
变换
1
变换
2
变换
外部
实体
外部
实体
外部
实体
外部
实体数据文件
输入数据
中间数据
输出数据
学
生
1
审查
开发票
2
开领书
单
学
生
购书单 发票 领书单
计算机售书系统的数据流图
无效书单软
件
工
程
原
理
各班学生用书表 教材存量表
软
件
工
程
原
理
3、行为模型
行为模型常用 状态转换图 （ 简称状
态图 ）来描述，它又称为 状态机模型 。
状态图中的基本元素有 事件, 状态
和 行为 等。
系统的状态机模型 可以理解为在任
一个时刻，系统处于有限可能的状态
中的一个状态，当某一个激励（条件）
到达时，它激发系统从一个状态转换
到另一个新状态。
下面是电话系统的状态图：
软
件
工
程
原
理
闲置
拨号音
do:响拨号音
超时
do:响蜂鸣音
存储的信息
do:播放信息接通中do:试接通
振铃
do:振铃
拨号
通话
断线
忙音
do:响忙音
挂断电话 挂断电话
拿起话筒 超时
无效号码
有效号码
超时数字数字
占线
已接通
受话人回话
受话人挂断电话
信
息
播
完
软
件
工
程
原
理
二、数据字典
数据字典 (Data Dictionary)用于描述
软件系统中使用或者产生的每一个数据
元素，是系统数据信息定义的集合。
数据字典的 作用,就是对软件中的每
个数据规定一个定义条目，以 保持数据
在系统中的一致性 。
软件中的数据，可分为三种情况：
① 只含一个数据的 数据项 (或数据元素 )；
② 由多个相关数据项组成的 数据流 ；
③ 数据文件或数据库 。
软
件
工
程
原
理
数据流, 发票, 的字典条目
数据流名：发票
别 名：购书发票
组 成：
学名＋姓名＋｛书号＋单价＋数量
＋总价｝＋书费合计
备 注：
软
件
工
程
原
理
数据文件, 各班学生用书表, 的字典条
目
文件名：各班学生用书表
别 名：
组 成：
｛系编号＋专业和班编号＋年级＋
｛书号｝｝
组 织：
按系、专业和班编号从小到大排列
备 注：
软
件
工
程
原
理
数据项, 数量, 的字典条目
数据项名：数量
别 名：购书量
取 值：正整数
备 注：
软
件
工
程
原
理
三、面向对象模型
一般情况下,OOA总是从理解系统
的, 使用实例 (简称用例 )”开始,基本步
骤 为：定义系统的 用例,在领域分析的
基础上建立问题域的 类－对象模型,然
后建立 对象－关系和对象－行为模型 。
在面向对象软件工程中，对象建模技
术 OMT(Object Modeling Technique)
是常用的方法和技术之一。
按照 OMT，分析模型有 3个子模型：
对象模型、动态模型和功能模型。
软
件
工
程
原
理
签定保险单
销售统计
客户统计客户 保险销售员
保险商务系统的用例图
保险商务系统
软
件
工
程
原
理
（ 1）对象模型 (Object Model)。描述
工具是 对象图 。用于描述对象的定义、
对象的属性、对象的运算、对象之间
的关系等。
学生
学号
班级
上课
考试
李平,学生
学号,020118
班级,计 02
上课
考试
类／对象图
软
件
工
程
原
理
规格
对象－关系图
部门 流水线
工序
不良品 材料 在制品
实时数据 指标数据
1:1
1:m
1:1
1:1
1:1 1:m
1:m
1:1
1:1 1:1
1:m0:m
1:1
1:m
1:1
1:m
0:m 1:1
1:1
1:m
0:1
1:1 1:1 0:1
软
件
工
程
原
理
（ 2）动态模型 (Dynamic Model)。描
述工具是 状态图 。用于描述系统的控
制结构、动态行为，即执行操作。
产生 半分钟数据
班数据
日数据
半小时数据
翻屏显示
实时数据状态转换图
光电采集 满半分钟
班数据处理
工控机处理
日数据处理
软
件
工
程
原
理
光电管 PLC 工控机 大屏幕
[半分钟到 ]
传累计值
物品经过
阻态信号
[半小时到 ]
显示数据
光电管实时数据采集部分 事件轨迹图
软
件
工
程
原
理
（ 3）功能模型 (Runction Model)。描
述工具是 数据流图 。用于描述系统的计
算结构、数据变换、数据流动的情形等
功能关系。
软
件
工
程
原
理
3.3 软件需求规格与评审
软件需求规格 SRS也称为 功能规格
说明、需求协议以及系统规格说明 等，
它是需求开发任务的最终产物。 P51
SRS可用 3种方法来描述：
（ 1）用结构化和自然语言编写文本
型文档；
（ 2）建立图形化模型；
（ 3）用形式化语言编写。
软
件
工
程
原
理
软件需求规格说明在编写后，要经
过评审和修改，最终行成一份正式的
文档，供用户、分析员、软件设计人
员等相关人员进行参考。
评审时有几项 指标,正确性、无岐
义性、完全性、可验证性、一致性、
可理解性、可修改性、可追踪性等。
软
件
工
程
原
理
3.4 需求管理
一、需求管理概述
需求管理是一个对系统需求变更、
了解和控制的过程。它与需求开发过程
相互关联,一旦形成了需求文档的初稿，
需求管理活动就开始了 。
需求管理强调：
（ 1）控制对需求基线的变动；
（ 2）保持项目计划与需求一致；
（ 3）控制单个需求和需求文档的版本
情况；
（ 4）管理需求和联系链，或者管理单
个需求和其他项目可交付产品之间的依
赖关系；
（ 5）跟踪基线中的需求状态。
需求管理的主要活动如下图所示：
软
件
工
程
原
理
软
件
工
程
原
理
需求管理
变更控制
?建议变更
?分析影响
?做出决策
?交流
?合并
?测量需求
的稳定性
版本控制
?确定需求
文档版本
?确定单个
需求文档
版本
需求跟踪
?定义对其
他需求的
连接链
?定义对其
他系统元
素的连接
链
需求状态跟踪
?定义需求状
态
?跟踪需求每
一个状态
软
件
工
程
原
理
1、需求管理原则
过程能力成熟度模型 (CMM)是在软件
开发机构中被广泛用来指导软件过程改
进。该模型描述了软件处理能力的 5个
成熟级别（ 初始级、可重复级、已定义
级、已管理级和优化级 ）。为了达到过
程能力成熟度模型的第二级，组织机构
必须具有 6个关键过程域 KPA( Key
Process Areas )。需求管理是其中之
一，它的目标是：
软
件
工
程
原
理
（ 1）为软件需求建立一个 基线,提供
给软件工程管理使用；
（ 2）软件计划、产品和活动与软件需
求保持一致。
2、需求规格说明的版本控制
版本控制是管理需求的一个必要方
面。软件开发组的每一个成员必须得
到需求的 当前版本 。
3、需求属性
除了文本，每一个功能需求应该有
一些相关的信息与它联系，这些信息
称为需求属性。
二、需求变更
为了使开发组织能够严格控制软件项
目，应该确保以下事项：
（ 1）仔细 评估 已建议的变更；
（ 2）挑选合适的 人选 对变更做出决定；
（ 3）变更应及时 通知 所有涉及的人员；
（ 4）项目要按一定的 程序 来采纳需求
变更。
1、变更控制过程
一个好的变更控制过程，给项目风险
软
件
工
程
原
理
软
件
工
程
原
理
承担者提供了正式的建议需求变更机制。
变更控制过程 如下图所示：
问题分析和变更描述
变更分析和成本计算
变更实现
识别出问题
修改后的需求
软
件
工
程
原
理
2、需求变更策略（参考）
（ 1）所有需求变更必须遵循变更控制过
程；
（ 2）对于未获得批准的变更，不应该做
设计和实现工作；
（ 3）变更应该由项目变更控制委员会决
定实现哪些变更；
（ 4）项目风险承担者应该能够了解变更
数据库的内容；
（ 5）决不能从数据库中删除或者修改变
更请求的原始文档；
（ 6）每一个集成的需求变更必须能跟踪
到一个经核准的变更请求。
软
件
工
程
原
理
3、变更控制委员会
变更控制委员会负责决定哪些已建议
需求变更或者新产品特性付诸应用，决
定在哪些版本中纠正哪些错误。
变更委员会可能包括如下方面的代表：
（ 1）产品或计划管理部门；
（ 2）项目管理部门；
（ 3）开发部门；
（ 4）测试或质量保证部门；
（ 5）市场部或客户代表；
（ 6）制作用户文档的部门；
（ 7）技术支持部门；
（ 8）帮助桌面或用户支持热线部门；
软
件
工
程
原
理
（ 9）配置管理部门。
三、需求跟踪
需求跟踪包括编制每个 需求 同 系统
元素 之间的 联系文档,这些元素包括
别的需求、体系结构、其他设计部件、
源代码模块、测试、帮助文件和文档
等。跟踪能力信息使变更影响分析十
分便利，有利于确认和评估实现某个
建议的需求变更所必须的工作。
跟踪能力（联系）链 ( Trace ability
Link )可以使我们跟踪一个需求使用
期限的全过程。
软
件
工
程
原
理
跟踪能力链有 4类，如图所示：
客户需求 软件需求 下一级工作产品①② ④③
图中：
① 客户需求向前追溯到软件需求。
② 从软件需求回溯相应的客户需求。
③ 从软件需求向前追溯到下一级工
作产品。
④ 从产品部件回溯到软件需求。
软
件
工
程
原
理
四、需求变更的代价和风险
变更需求是要付出代价的，只要允
许软件需求变更或者添加新特性，一
个表面上很简单的变更也可能转变成
很复杂的局面。
需求变更 对软件的 进度、成本、技
术、效率 都会有不同程度的影响，变
更只能在项目时间、预算、资源等的
限制内进行协商。
影响分析 是需求管理的一个重要组
成部分。进行影响分析的能力依赖于
跟踪能力、数据的质量和完整性。
软
件
工
程
原
理
3.5 软件需求分析与需求管理工具
(略 )
一、软件需求分析工具
CASE2000,系统分析组 SUITE
AnalistStudio等。
二、需求管理工具
软
件
工
程
原
理
课堂练习：
有一个小型数据库系统，具有
身份验证、查询（根据某一特征）、
添加数据、修改数据、删除数据、
数据合并、输出数据等功能。
要求：对该系统进行分析后，
画出该系统的数据流图。
软
件
工
程
原
理
1
身份验证
用
户
2
数据
查询
用户信息 非法用户
3
数据
添加
4
数据
修改
5
数据
删除
6
数据
合并
合法用户
合法用户
合法用户
合法用户 合法用户
数据库文件
7
数据
输出
用
户
输出数据
软
件
工
程
原
理
2
数据库管理
用
户
用户信息
用
户
输出数据
数据流图（顶层）
1
身份验证
非法用户
合法用户
软
件
工
程
原
理
合法用户
数据库文件
2.1
数据
查询
2.2
数据
添加
2.3
数据
修改
2.4
数据
删除
2.5
数据
合并
2.6
数据
输出
输出数据
数据流图（ 1层）
