之间有什么联系、数据本身有什么性质、数据的结构等。
又要分析用户的处理要求：即对数据进行哪些处理、
每个处理的逻辑功能等
2020/9/30
21
为了把用户的数据表达清楚，通常建立一个 概念性的数据模型（也称信息模型）。
概念性数据模型是一种面向问题的数据模 型，按照用户的观点来对数据和信息建模。它描 述了从用户角度看到的数据，反映用户的现实环 境，与软件的实现方法无关。
概念性数据模型常用的方法是实体—联系的方 法（也称ER模型）。是用ER图描述现实世界中 的实体。
2020/9/30
22
1）、ER模型
ER模型中包含“实体”、“联系”和“属性”等三个基本 成分。
2020/9/30
23
（1）实体： 客观世界中存在的且可相互 区分的事物。
在ER图中用矩形框代表。 实体是现实中存在的对象，有具体的，也 有抽象的；有物理上存在的，也有概念性的； 例如，学生、课程，等等。它们的特征是可以 互相区别，否则就会被认为是同一对象。凡是 可以互相区别、又可以被人们识别的事、物、 概念等统统可以被抽象为实体 。
由于成本的增加，过去很少采用样机策略。但是，由于 正确地提出用户需求是软件开发工程成功的基础，近来主张 采用样机策略的人也多起来。
6、编写软件需求规格说明书
编写提纲见表3-1 (next page)
2020/9/30
11
表3-1 需求规格说明书提纲
1、引言 1.1 目的 1.2 背景 1.3 定义 1.4 参考资料
（4）修正的开发计划。包括修正后的成本估计、资源使用计 划、进度计划等。
6、审查和复审（技术审查和管理复审）
2020/9/30
20
四、概念模型和规范化
软件系统本质是信息处理系统，因此，在 开发过程中必须考虑两个问题：“数据”及数据 的“处理”。在需求分析阶段，
既要分析用户的数据要求：即需要哪些数据、数据
2、分析系统的数据要求
软件需求分析的一个重要任务是分析系统的数据要求。
通常采用建立概念模型的方法，并辅助图形工具，如：
层次方框图、Warnier图等。
复杂的数据由许多基本的数据元素组成，数据元素之
间的逻辑关系用数据结构表示。利用数据字典可以全面
准确地定义数据，但是不够形象直观（缺点）。为了提
高可理解性，常常利用图形工具辅助描绘数据结构。常
例如，一个学生可以上多门课程，而每门课程可以有 多个学生来学，则学生与课程是多对多的联系。
2020/9/30
25
（3）属性：是实体或联系所具有的性质
在ER图中用椭圆形或圆角矩形代表。
例如，“学生”实体的属性有学号、姓名、性别 、系、年级等；“教师”实体的属性有教工号、姓名 、性别、职称、职务等。
联系也可能有属性。例如，学生的“成绩”既依赖 于某名特定的学生又依赖于某门特定的课程，所以“ 成绩”是学生与课程之间的联系属性。
(1) 功能需求
系统做什么？ 系统何时做什么？ 系统何时及如何修改或升级？
(2)性能需求
软件开发的技术性指标 例如： 存储容量限制 执行速度、相应时间 吞吐量
(3) 环境需求
硬件设备：机型、外设、接口、地点、 分布、温度、湿度、磁场干扰等
软件： 操作系统、网络、数据库
(4) 界面需求
有来自其它系统的输入吗？ 有到自其它系统的输出吗？ 对数据格式有规定吗？ 对数据存储介质有规定吗？
2020/9/30
26
例子：
职称
性别
职务
姓名 性别 学号
年级 系
-
图 3
1
姓名
教师
学生
教工号
1 教N
学
N
校
M学
成绩
教 学
课程
管
理
ER
课程号 课名 学时 学分
图
2020/9/30
27
2）、范式
通常用范式来消除数据冗余的程度。第 一范式（1NF）数据冗余程度最大，第五范 式（5NF）数据冗余程度最小。
第三章 软件需求分析
2020/9/30
1
内容提要
一、需求分析的任务
二、需求分析的步骤
三、结构化的分析方法
四、概念模型和规范化
五、软件需求分析工具
六、状态转换图
七、验证软件需求
八、小结
2020/9/30
2
一、需求分析的任务
仍然回答“What(做什么)”， 而不是“How（怎样做）”， 但更细致、精确（合同的拟定）
2020/9/30
22% 17% 14% 20% 19% 25% 16% 26%
金工 金工 动力 动力 金工 金工 动力 动力
李明 李明 赵杰 赵杰 李明 李明 赵杰 赵杰
29
上表W中的数据库存在严重缺点 ：数据冗余大，增删改麻烦 采取第二范式来避免以上缺点。
※ 第二范式：满足第一范式条件，而且每个非关键字属性 都由整个关键字决定（也即每个非关键字属性都依赖于关键 字）。 方法：将上表W关系分解为W1和W2。如下表：
2、项目概述 2.1 产品描述 2.2 产品功能 2.3 用户特点 2.4 一般约束 2.5 假设与依据
3、具体需求 3.1 功能需求 3.1.1 规格说明 3.1.1.1 引言 3.1.1.2 输入 3.1.1.3 输出 3.1.1.4 加工 3.1.2 外部接口 3.1.2.1 用户接口 3.1.2.2 硬件接口 3.1.2.3 软件接口 3.1.2.4 通讯接口
4、修正系统开发计划
在分析过程中对系统更深入更具体的了解， 可以比较准确地估计系统的成本和进度，修正 以前制定的开发计划
2020/9/30
9
5、开发原型系统（样机模型）
在第一章我们讲过软件开发三种模型当 中，有一种原型模型（也称样机模型）。 在需求分析当中，使用样机的主要目的是 ：使用户通过实践获得关于未来的系统将 怎样为他们工作的更直接更具体的概念， 从而可以更准确地提出和解决他们的要求 。
95.05 95.05 95.05 95.05 95.06 95.06 95.06 95.06
101 丁一 车工 80 102 王二 车工 80 103 张三 钳工 75 104 李四 电工 70 101 丁一 车工 80 102 王二 车工 80 103 张三 钳工 75 104 李四 电工 70
2020/9/30
17
3、细化数据流图
通过了用户复查以后，分析员就要把数据流图进行细化， 通过功能分解可以完成数据流图的细化。细化之后得到一组 新的数据流图。
随着分析过程的进展，经过问题和解答的反复循环， 分析员对目标系统越来越清楚，最终得到对系统数据和功能 要求的满意了解。
图 3-1 概括了上述分析的过程。 需要分解
目前，需求分析的方法有面向数据流的方法（也 就是结构化的分析方法（SA），使用的工具有DFD＋ RED等），以及面向对象的方法（使用的工具为用例 图等）。一般来说，可以使用DFD＋ERD来描述那些 功能层次比较清晰的需求；而USE CASE则适于描述 功能结构复杂的需求。做需求分析的目的是为了建立 需求的模型，不同的子系统有可能使用不同的建模方 法。
3.2 性能需求 3.2.1 数据精度 3.2.2 时间特性 3.2.3 适应性
3.3 设计约束 3.4 属性需求
3.4.1 安全性 3.4.2 可维护性 3.4.3 保密性
…… 附录 索引
2020/9/30
12
二、需求分析的步骤
获取用户需求→分析用户需求→编写需求文档 →评审需求文档→管理需求。
状态转换图：通过描绘系统的状态及引起系统状态转换的
事件,来表示系统的行为.此外,状态图还指明了作为特定事件的 结果系统将作那些动作(例如,处理数据)。
同时，借用数据词典、结构化语言、判定表、判定树等工
具对它们进行详细说明。
2020/9/30
15
面向数据流自顶向下求精分析过程
1、沿数据流图回溯(02(5))
沿数据流图从输出端往输入端回溯，确定每个 数据元素的来源，同时初步定义算法。在可行性 研究阶段的高层数据流基础上，设计细节的数据 元素。
通常把分析过程中得到的有关数据元素的信息 记录在数据字典中，把对算法的简明描述记录在 IPO图中。
通过分析而补充的数据流、数据存储和处理， 应该添加到数据流图的适当位置上。
有补充
修正
分析数据 流图
无补充
用户复查 修正
细化数 据流图
2020/9/30
不需分解
18
4、修正开发计划
我们讲过在可行性研究阶段，写出了一份开 发计划。经过需求分析阶段的工作，对系统的成 本和进度有了更准确的估计之后，对开发计划进 行修正。
2020/9/30
19
5、书写文档
根据需求分析阶段的基本任务，可以完成以下的文档资料。
DFD描述问题空间中数据变换处理之间的逻辑关系，尤其 适用于MIS系统的表述。DFD方法直观易懂，使用者可以方便 地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断 活动的时序关系。
ER图描述问题空间中数据存贮之间的逻辑关系，需求分 析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使 用ERD描述物理表之间的关系。ERD只关注系统中数据间的关 系，而缺乏对系统功能的描述。
可行性分析 DFD 功能具体化 DD
需求规格说明
加细 DFD
DD
算法 描述
IPO
2020/9/30 Final stage of Definition phase
3
1、确定对系统的综合要求（讲义p48）
(1) 功能需求 (2) (2) 性能需求 (3) 环境需求 (4) 界面需求
……
（n）将来可能提出的要求