第 3章 需求分析
3.1 需求分析的任务
3.2 与用户沟通获取需求的方法
3.3 分析建模与规格说明
3.4 实体 -联系图 （？）
3.5 数据规范化（？）
3.6 状态转换图 +有穷状态机
3.7 其他图形工具
3.8 验证软件需求
3.9 小结需求分析的 意义软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。
需求分析是软件定义时期的最后一个阶段，
它的基本任务 不是确定系统怎样完成 它的工作，
而是确定系统必须完成 哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：
---- 准确地回答“系统必须做什么?” 。
在分析软件需求和书写软件需求规格说明书的过程中，
分析员和用户都起着关键的、必不可少的作用。
业务需求项目范围文档用户需求文档功能需求质量属性其他非功能需求设计约束需求规约
(specification)
非功能需求系统需求需求组成的全景图软件需求的组成其中：
业务需求,反映组织机构和客户对系统、产品高层次的目标要求。
用户需求,从用户使用的角度给出需求的描述。
如一个小型超市需要一个商品的查询系统。
业务需求,进货人员 需要查询商品库存以便保证及时进货； 收款员 需要查询商品的销售价格以便结账； 经理 需要查询商品的销售及盈利情况。
用户需求,这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。
系统需求,从 系统的角度描述要提供的服务以及所受到的约束。即系统对外必须提供的服务和达到的要求。
功能性需求,描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。
非功能性需求,产品必须具备的属性或品质，如性能、可靠性等等。
设计约束,设计与 实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。
软件需求的描述
结构化语言,PDL
图形化表示
数学描述（形式化语言描述）
1 确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、
逆向需求、将来可能提出的要求。
3.1 需求分析的具体任务
2 分析系统的数据要求
3 导出系统的逻辑模型
4 修正系统开发计划软件需求获取需求分析是一个包括创建和维持系统需求文档所必需的一切活动的过程。它包含了如下活动：
需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理（管理需求工程的变更）。
需求获取和分析需求描述需求有效性验证系统模型 用户需求和系统需求需求规约软件需求过程需求管理
需求获取是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。
需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规约的过程。
需求获取和分析有一定的难度，因为：
1） 项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。
2） 项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。
3）不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的项目相关人员那里得到。
需求获取技术
建立由客户（用户）、系统分析员、领域专家参加的联合小组。
需求获取的方法：个别访谈、召集会议、文档研究、
问卷调查、观察用户工作流程、建立原型。
获取的需求的表达方式：
（ 1）需求列表需求与系统的特殊视角或环境的关系
（ 2）业务流程图（状态 /活动图）
（ 3）数据流图
（ 4）实体 -联系图
3.2 与用户沟通获取需求的方法
3.2.1 访谈
3.2.2 面向数据流自顶向下求精
3.2.3 简易的应用规格说明技术
3.2.4 快速建立软件原型面向数据流自顶向下求精提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求
- 进行初步的访谈
- 开发者和用户双方组织的代表出席会议
- 每个小组为每张列表中的项目制定小型规格说明
- 根据会议成果起草完整的软件需求规格说明书
3.2.3 简易的应用规格说明技术
3.3 分析建模与规格说明
1),分析建模模型
----就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。
建模方法在过去的数年中，人们提出了许多种分析建模的方法，其中两种在分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis,SA),70年代末由
DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过 30年的一个混合物。
具体的建模方法 /表达方式 有：
面向流的建模,数据流图 （ DFD/CFD）
数据 建模,实体关系图 （ ERD）
基于 行为 的建模,Petri网,状态图
3.3.2 软件需求规格说明 (SRS)
Software Requirement Specification
通常用自然语言 +模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
软件需求规格说明书，是需求分析阶段得出的最主要的文档。
软件需求说明书的编写提示（ GB856T— 88）
1 引言
1.1 编写目的
1.2 背景
1.3 定义
1.4 参考资料
2 任务概述
2.1 目标
2.2 用户的特点
2.3 假定和约束软件需求说明书的编写提示（ GB856T— 88）
3 需求规定
3.1 对功能的规定
3.2 对性能的规定
3.2.1 精度
3.2.2 时间特性要求
3.2.3 灵活性
3.3 输人输出要求
3.4 数据管理能力要求
3.5 故障处理要求
3.6 其他专门要求
4 运行环境规定
4.1 设备
4.2 支持软件
4.3 接口
4.4 控制
3.4 实体 -联系图 (ER)
Entity Relationship Diagram
ER图 ---- 是用来建立概念数据模型的工具。
概念数据模型 ---- 是一种面向问题的数据模型，
是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，
而且与在软件系统中的实现方法无关。
数据模型中包含 3种相互关联的信息,数据对象
（ 实体 ）、数据对象的 属性 及数据对象彼此间相互连接的 关系 。
(1),数据对象
数据对象,是对软件必须理解的复合信息的抽象。
复合信息,是指 具有一系列不同性质或属性的事物,
仅有单个值的事物 (例如，宽度 )不是数据对象。
可以由 一组属性来定义的实体 都可以被认为是数据对象。
如：外部实体、事物、行为、事件、角色、单位、地点或结构等。
数据对象彼此间是有关联的。
(2),属 性
属性定义了数据对象的 性质 。
必须把一个或多个属性定义为,标识符,,也就是说，
当我们希望找到数据对象的一个实例时，用标识符属性作为,关键字,(通常简称为,键,)。
应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。
如,学生具有 学号,姓名,性别,年龄,专业 （其它略）等属性；
课程具有 课程号,课程名,学分,学时数 等属性；
教师具有 职工号,姓名,年龄,职称 等属性。
(3),联 系
数据对象 彼此之间相互连接的方式 称为联系，也称为关系。
联系可分为以下 3种类型,
a,一对一联系 (1∶1)
如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
b,一对多联系 (1∶N)
如：某校教师与课程之间存在一对多的联系,教,,即每位教师可以教多门课程，但是每门课程只能由一位教师来教。
c,多对多联系 (M∶N)
如：学生与课程间的联系 (“学,)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
(3),联 系
联系也可能有属性。
如：某个学生学习某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于,成绩,既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系,学,的属性。
(4),实体 -联系图的符号
ER图 中包含了 实体 (即数据对象 ),关系 和 属性 等 3种基本成分。
通常用 矩形框 代表实体；
用连接相关实体的 菱形框 表示关系；
用 椭圆形或圆角矩形 表示实体 (或关系 )的属性；
并用 直线 把实体 (或关系 )与其属性连接起来。
举 例图 3.2 某校教学管理 ER图实体教师属性学生属性课程属性联系属性联系
3.5 数据规范化什么是规范化？
为什么要规范化？
3.5 数据规范化队 队长 学号 课程 成绩平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
关键字
3.5 数据规范化上述表格存在的问题：
数据冗余 ；
结构复杂,数据项“成绩”不是简单数据，而是一个复合数据项；
插入、删除与修改操作不便；
规范化的目的是：
消除数据冗余,即消除表格中数据的重复；
使关系的,概念,单一化,让每个数据项只是一个简单的数或字符串，而不是一个复合数据项；
方便操作 。使数据的插入、删除与修改操作方便并且不易出错；
规范化的方法是：关系分解
1、范式级别越高，存储同样数据就需要分解成更多张表，因此，
,存储自身,的过程也就越复杂。
2、随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。
3、范式级别提高则需要访问的表增多，因此性能 (速度 )将下降。
从实用角度看来，在大多数场合选用第三范式都比较恰当。
从实用角度看来，在大多数场合选用第三范式都比较恰当。
通常用,范式 (Normal Forms)”定义消除数据冗余的程度。第一范式 (1 NF)数据冗余程度最大，第五范式 (5 NF)
数据冗余程度最小。 但是：
第 一 范 式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
队 队长 学号 课程 成绩平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
第 一 范 式第 一 范 式队 队长 学号 课程 平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
第 二 范 式满足第一范式条件，而且每个非关键字属性都由整个关键字决定 (而不是由关键字的一部分来决定 )。
简言之，第二范式的目的是消除 部分依赖第 二 范 式 关键字队 队长 学号 课程 平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 课程 平时成绩 考试成绩
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 队 队长
001
002
003
004
51队
51队
53队
53队张三张三李四李四关键字 关键字第 三 范 式符合第二范式的条件。 满足第三范式（ 3NF）必须先满足第二范式（ 2NF）。第三范式（ 3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
简言之，第三范式的目的是消除 传递依赖。
学号 课程 平时成绩 考试成绩
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 队 队长
001
002
003
004
51队
51队
53队
53队张三张三李四李四关键字 关键字学号 课程 平时成绩 考试成绩
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 队
001
002
003
004
51队
51队
53队
53队队 队长
51队
53队张三李四关键字 关键字图 3.2 某校教学管理 ER图学号 姓名 性别 系 年级课号 教工号教工号 姓名 性别 职称 职务课号 课名 学时 学分学号 课号 成绩教师信息表：
教课信息表：
课程信息表：
学生信息表：
成绩信息表：
学号 姓名 性别 系 年级教工号 姓名 性别 职称 职务课号 课名 学时 学分 教工号学号 课号 成绩教师信息表：
课程信息表：
学生信息表：
成绩信息表：
3.6 状态转换图状态转换图 (简称为状态图 )
通过描绘系统的 状态 及引起系统状态转换的 事件,来表示系统的 行为 。此外，状态图还指明了作为特定事件的结果系统将做哪些动作 (例如，处理数据 )。
1),状 态状态 是任何可以被观察到的 系统行为模式,一个状态代表系统的一种行为模式。 状态规定了系统对事件的响应方式 。系统对事件的响应，既可以是做一个 (或一系列 )
动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
初态 (即初始状态 )
状态 终态 (即最终状态 )
中间状态一张状态图中只能有一个初态，而终态则可以有 0至多个。
2),事 件事件是在某个特定时刻发生的事情，它是对引起系统做动作或 (和 )从一个状态转换到另一个状态的外界事件的抽象。
例如，用户移动或点击鼠标等都是事件。
简而言之,事件就是引起系统做动作或 (和 )转换状态的控制信息。
初态用实心圆 表示,终态用一对同心圆 (内圆为实心圆 )表示。
中间状态用圆角矩形表示,可以用两条水平横线把它分成 上、
中、下 3个部分。 上面部分为状态的名称,这部分是必须有的；
中间部分为状态变量的名字和值,这部分是可选的； 下面部分是活动表,这部分也是可选的。
3),符 号
活动表的语法格式：事件名 (参数表 )/动作表达式其中,,事件名,可以是任何事件的名称。在活动表中经常使用下述 3种标准事件,entry,exit和 do。 entry事件指定进入该状态的动作,exit事件指定退出该状态的动作，而 do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。
3),符 号
状态图中两个状态 之间带箭头的连线称为状态转换,箭头指明了转换方向。
状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的 箭头线上标出触发转换的事件表达式 ；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
事件表达式的语法：
事件说明［守卫条件］／动作表达式
事件说明 的语法为：事件名 (参数表 )。
守卫条件 是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。
动作表达式 是一个过程表达式，当状态转换开始时执行该表达式。
3),符 号
4),举 例电话系统的状态图
3.7 其他图形工具
层次方框图
Warnier图
IPO图
3.7.1 层次方框图
层次方框图用 树形结构的一系列多层次的矩形框 描绘数据的层次结构。
树形结构的 顶层是一个单独的矩形框,它代表完整的数据结构，
下面的各层矩形框代表这个数据的子集,最底层 的各个框代表组成这个数据的 实际数据元素 (不能再分割的元素 )。
随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，
这种模式非常适合于需求分析阶段的需要 。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。
举 例领导层辅助决策系统查询 辅助决策物资信息重点供料信息商情信息人员状况合同监视财务信息计划执行情况工程进展情况超储低储情况经营指标历年对比价格预测物资用量预测库存定额核定库存结构分析经济采购批量保本保利分析
3.7.2 Warnier图
法国计算机科学家 Warnier提出了表示信息层次结构的另外一种图形工具。
Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。
用 Warnier图可以 表明信息的逻辑组织 。
它可以指出一类信息或一个信息元素是 重复出现 的，也可以表示特定信息在某一类信息中是 有条件地出现 的。
重复和条件约束是说明软件处理过程的基础，所以很容易把 Warnier图转变成软件设计的工具。
举 例图中表示一种软件产品 要么 是系统软件 要么 是应用软件。
系统软件中有 P1种操作系统,P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具,图中标出了每种软件工具的数量。
3.7.3 IPO图
左边的框中列出有关的输入数据。
中间的框内列出主要的处理，处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。
在右边的框内列出产生的输出数据。
在 IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。
一种改进的 IPO图 (也称为 IPO表 )
在需求分析阶段可以使用 IPO
表 简略地 描述系统的主要算法
(即数据流图中各个处理的基本算法 )。
需求分析阶段,IPO表中的许多附加信息暂时还不具备，但在设计阶段可以进一步补充修正这些图，作为设计阶段的文档。
这正是在需求分析阶段用 IPO
表作为描述算法的工具的重要优点。
3.8 验证软件需求验证软件需求的正确性，一般应从 4个方面进行：
(1) 一致性 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
(2) 完整性 需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
(3) 现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
(4) 有效性 必须证明需求是正确有效的，确实能解决用户面对的问题。
3.9 小结需求分析的任务,功能、性能、可靠性、可用性、接口、
约束条件获取需求的方法,访谈、会议、面向数据流逐步求精、
快速原型分析建模与规格说明,数据模型、功能模型、行为模型实体 -联系图 & 数据规范化状态转换图数据字典 &其他图形工具验证软件需求,一致性、完整性、现实性和有效性
3.1 需求分析的任务
3.2 与用户沟通获取需求的方法
3.3 分析建模与规格说明
3.4 实体 -联系图 （？）
3.5 数据规范化（？）
3.6 状态转换图 +有穷状态机
3.7 其他图形工具
3.8 验证软件需求
3.9 小结需求分析的 意义软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。
需求分析是软件定义时期的最后一个阶段，
它的基本任务 不是确定系统怎样完成 它的工作，
而是确定系统必须完成 哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：
---- 准确地回答“系统必须做什么?” 。
在分析软件需求和书写软件需求规格说明书的过程中，
分析员和用户都起着关键的、必不可少的作用。
业务需求项目范围文档用户需求文档功能需求质量属性其他非功能需求设计约束需求规约
(specification)
非功能需求系统需求需求组成的全景图软件需求的组成其中：
业务需求,反映组织机构和客户对系统、产品高层次的目标要求。
用户需求,从用户使用的角度给出需求的描述。
如一个小型超市需要一个商品的查询系统。
业务需求,进货人员 需要查询商品库存以便保证及时进货； 收款员 需要查询商品的销售价格以便结账； 经理 需要查询商品的销售及盈利情况。
用户需求,这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。
系统需求,从 系统的角度描述要提供的服务以及所受到的约束。即系统对外必须提供的服务和达到的要求。
功能性需求,描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。
非功能性需求,产品必须具备的属性或品质，如性能、可靠性等等。
设计约束,设计与 实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。
软件需求的描述
结构化语言,PDL
图形化表示
数学描述（形式化语言描述）
1 确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、
逆向需求、将来可能提出的要求。
3.1 需求分析的具体任务
2 分析系统的数据要求
3 导出系统的逻辑模型
4 修正系统开发计划软件需求获取需求分析是一个包括创建和维持系统需求文档所必需的一切活动的过程。它包含了如下活动：
需求获取和分析、需求描述和文档编写、需求有效性验证、需求管理（管理需求工程的变更）。
需求获取和分析需求描述需求有效性验证系统模型 用户需求和系统需求需求规约软件需求过程需求管理
需求获取是开发人员与客户或用户一起对应用领域进行调查研究，收集系统需求的过程。
需求分析是将获取到的需求准确的理解、求精，并将其转化为完整的需求定义（包括建模），进而生成需求规约的过程。
需求获取和分析有一定的难度，因为：
1） 项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。
2） 项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。
3）不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度会改变，新的需求会从新的项目相关人员那里得到。
需求获取技术
建立由客户（用户）、系统分析员、领域专家参加的联合小组。
需求获取的方法：个别访谈、召集会议、文档研究、
问卷调查、观察用户工作流程、建立原型。
获取的需求的表达方式：
（ 1）需求列表需求与系统的特殊视角或环境的关系
（ 2）业务流程图（状态 /活动图）
（ 3）数据流图
（ 4）实体 -联系图
3.2 与用户沟通获取需求的方法
3.2.1 访谈
3.2.2 面向数据流自顶向下求精
3.2.3 简易的应用规格说明技术
3.2.4 快速建立软件原型面向数据流自顶向下求精提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求
- 进行初步的访谈
- 开发者和用户双方组织的代表出席会议
- 每个小组为每张列表中的项目制定小型规格说明
- 根据会议成果起草完整的软件需求规格说明书
3.2.3 简易的应用规格说明技术
3.3 分析建模与规格说明
1),分析建模模型
----就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。
建模方法在过去的数年中，人们提出了许多种分析建模的方法，其中两种在分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis,SA),70年代末由
DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发展了超过 30年的一个混合物。
具体的建模方法 /表达方式 有：
面向流的建模,数据流图 （ DFD/CFD）
数据 建模,实体关系图 （ ERD）
基于 行为 的建模,Petri网,状态图
3.3.2 软件需求规格说明 (SRS)
Software Requirement Specification
通常用自然语言 +模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
软件需求规格说明书，是需求分析阶段得出的最主要的文档。
软件需求说明书的编写提示（ GB856T— 88）
1 引言
1.1 编写目的
1.2 背景
1.3 定义
1.4 参考资料
2 任务概述
2.1 目标
2.2 用户的特点
2.3 假定和约束软件需求说明书的编写提示（ GB856T— 88）
3 需求规定
3.1 对功能的规定
3.2 对性能的规定
3.2.1 精度
3.2.2 时间特性要求
3.2.3 灵活性
3.3 输人输出要求
3.4 数据管理能力要求
3.5 故障处理要求
3.6 其他专门要求
4 运行环境规定
4.1 设备
4.2 支持软件
4.3 接口
4.4 控制
3.4 实体 -联系图 (ER)
Entity Relationship Diagram
ER图 ---- 是用来建立概念数据模型的工具。
概念数据模型 ---- 是一种面向问题的数据模型，
是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，
而且与在软件系统中的实现方法无关。
数据模型中包含 3种相互关联的信息,数据对象
（ 实体 ）、数据对象的 属性 及数据对象彼此间相互连接的 关系 。
(1),数据对象
数据对象,是对软件必须理解的复合信息的抽象。
复合信息,是指 具有一系列不同性质或属性的事物,
仅有单个值的事物 (例如，宽度 )不是数据对象。
可以由 一组属性来定义的实体 都可以被认为是数据对象。
如：外部实体、事物、行为、事件、角色、单位、地点或结构等。
数据对象彼此间是有关联的。
(2),属 性
属性定义了数据对象的 性质 。
必须把一个或多个属性定义为,标识符,,也就是说，
当我们希望找到数据对象的一个实例时，用标识符属性作为,关键字,(通常简称为,键,)。
应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。
如,学生具有 学号,姓名,性别,年龄,专业 （其它略）等属性；
课程具有 课程号,课程名,学分,学时数 等属性；
教师具有 职工号,姓名,年龄,职称 等属性。
(3),联 系
数据对象 彼此之间相互连接的方式 称为联系，也称为关系。
联系可分为以下 3种类型,
a,一对一联系 (1∶1)
如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
b,一对多联系 (1∶N)
如：某校教师与课程之间存在一对多的联系,教,,即每位教师可以教多门课程，但是每门课程只能由一位教师来教。
c,多对多联系 (M∶N)
如：学生与课程间的联系 (“学,)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
(3),联 系
联系也可能有属性。
如：某个学生学习某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于,成绩,既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系,学,的属性。
(4),实体 -联系图的符号
ER图 中包含了 实体 (即数据对象 ),关系 和 属性 等 3种基本成分。
通常用 矩形框 代表实体；
用连接相关实体的 菱形框 表示关系；
用 椭圆形或圆角矩形 表示实体 (或关系 )的属性；
并用 直线 把实体 (或关系 )与其属性连接起来。
举 例图 3.2 某校教学管理 ER图实体教师属性学生属性课程属性联系属性联系
3.5 数据规范化什么是规范化？
为什么要规范化？
3.5 数据规范化队 队长 学号 课程 成绩平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
关键字
3.5 数据规范化上述表格存在的问题：
数据冗余 ；
结构复杂,数据项“成绩”不是简单数据，而是一个复合数据项；
插入、删除与修改操作不便；
规范化的目的是：
消除数据冗余,即消除表格中数据的重复；
使关系的,概念,单一化,让每个数据项只是一个简单的数或字符串，而不是一个复合数据项；
方便操作 。使数据的插入、删除与修改操作方便并且不易出错；
规范化的方法是：关系分解
1、范式级别越高，存储同样数据就需要分解成更多张表，因此，
,存储自身,的过程也就越复杂。
2、随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。
3、范式级别提高则需要访问的表增多，因此性能 (速度 )将下降。
从实用角度看来，在大多数场合选用第三范式都比较恰当。
从实用角度看来，在大多数场合选用第三范式都比较恰当。
通常用,范式 (Normal Forms)”定义消除数据冗余的程度。第一范式 (1 NF)数据冗余程度最大，第五范式 (5 NF)
数据冗余程度最小。 但是：
第 一 范 式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
队 队长 学号 课程 成绩平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
第 一 范 式第 一 范 式队 队长 学号 课程 平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
第 二 范 式满足第一范式条件，而且每个非关键字属性都由整个关键字决定 (而不是由关键字的一部分来决定 )。
简言之，第二范式的目的是消除 部分依赖第 二 范 式 关键字队 队长 学号 课程 平时成绩 考试成绩
51队
51队
51队
51队
51队
53队
53队
53队
53队张三张三张三张三张三李四李四李四李四
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 课程 平时成绩 考试成绩
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 队 队长
001
002
003
004
51队
51队
53队
53队张三张三李四李四关键字 关键字第 三 范 式符合第二范式的条件。 满足第三范式（ 3NF）必须先满足第二范式（ 2NF）。第三范式（ 3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
简言之，第三范式的目的是消除 传递依赖。
学号 课程 平时成绩 考试成绩
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 队 队长
001
002
003
004
51队
51队
53队
53队张三张三李四李四关键字 关键字学号 课程 平时成绩 考试成绩
001
001
001
002
002
003
003
004
004
C语言软件工程数据结构
BASIC
数据库
C语言微机原理软件工程数据库
20
25
22
24
20
21
15
14
19
85
90
80
83
92
87
90
85
80
学号 队
001
002
003
004
51队
51队
53队
53队队 队长
51队
53队张三李四关键字 关键字图 3.2 某校教学管理 ER图学号 姓名 性别 系 年级课号 教工号教工号 姓名 性别 职称 职务课号 课名 学时 学分学号 课号 成绩教师信息表：
教课信息表：
课程信息表：
学生信息表：
成绩信息表：
学号 姓名 性别 系 年级教工号 姓名 性别 职称 职务课号 课名 学时 学分 教工号学号 课号 成绩教师信息表：
课程信息表：
学生信息表：
成绩信息表：
3.6 状态转换图状态转换图 (简称为状态图 )
通过描绘系统的 状态 及引起系统状态转换的 事件,来表示系统的 行为 。此外，状态图还指明了作为特定事件的结果系统将做哪些动作 (例如，处理数据 )。
1),状 态状态 是任何可以被观察到的 系统行为模式,一个状态代表系统的一种行为模式。 状态规定了系统对事件的响应方式 。系统对事件的响应，既可以是做一个 (或一系列 )
动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
初态 (即初始状态 )
状态 终态 (即最终状态 )
中间状态一张状态图中只能有一个初态，而终态则可以有 0至多个。
2),事 件事件是在某个特定时刻发生的事情，它是对引起系统做动作或 (和 )从一个状态转换到另一个状态的外界事件的抽象。
例如，用户移动或点击鼠标等都是事件。
简而言之,事件就是引起系统做动作或 (和 )转换状态的控制信息。
初态用实心圆 表示,终态用一对同心圆 (内圆为实心圆 )表示。
中间状态用圆角矩形表示,可以用两条水平横线把它分成 上、
中、下 3个部分。 上面部分为状态的名称,这部分是必须有的；
中间部分为状态变量的名字和值,这部分是可选的； 下面部分是活动表,这部分也是可选的。
3),符 号
活动表的语法格式：事件名 (参数表 )/动作表达式其中,,事件名,可以是任何事件的名称。在活动表中经常使用下述 3种标准事件,entry,exit和 do。 entry事件指定进入该状态的动作,exit事件指定退出该状态的动作，而 do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。
3),符 号
状态图中两个状态 之间带箭头的连线称为状态转换,箭头指明了转换方向。
状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的 箭头线上标出触发转换的事件表达式 ；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
事件表达式的语法：
事件说明［守卫条件］／动作表达式
事件说明 的语法为：事件名 (参数表 )。
守卫条件 是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。
动作表达式 是一个过程表达式，当状态转换开始时执行该表达式。
3),符 号
4),举 例电话系统的状态图
3.7 其他图形工具
层次方框图
Warnier图
IPO图
3.7.1 层次方框图
层次方框图用 树形结构的一系列多层次的矩形框 描绘数据的层次结构。
树形结构的 顶层是一个单独的矩形框,它代表完整的数据结构，
下面的各层矩形框代表这个数据的子集,最底层 的各个框代表组成这个数据的 实际数据元素 (不能再分割的元素 )。
随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，
这种模式非常适合于需求分析阶段的需要 。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。
举 例领导层辅助决策系统查询 辅助决策物资信息重点供料信息商情信息人员状况合同监视财务信息计划执行情况工程进展情况超储低储情况经营指标历年对比价格预测物资用量预测库存定额核定库存结构分析经济采购批量保本保利分析
3.7.2 Warnier图
法国计算机科学家 Warnier提出了表示信息层次结构的另外一种图形工具。
Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。
用 Warnier图可以 表明信息的逻辑组织 。
它可以指出一类信息或一个信息元素是 重复出现 的，也可以表示特定信息在某一类信息中是 有条件地出现 的。
重复和条件约束是说明软件处理过程的基础，所以很容易把 Warnier图转变成软件设计的工具。
举 例图中表示一种软件产品 要么 是系统软件 要么 是应用软件。
系统软件中有 P1种操作系统,P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具,图中标出了每种软件工具的数量。
3.7.3 IPO图
左边的框中列出有关的输入数据。
中间的框内列出主要的处理，处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。
在右边的框内列出产生的输出数据。
在 IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。
一种改进的 IPO图 (也称为 IPO表 )
在需求分析阶段可以使用 IPO
表 简略地 描述系统的主要算法
(即数据流图中各个处理的基本算法 )。
需求分析阶段,IPO表中的许多附加信息暂时还不具备，但在设计阶段可以进一步补充修正这些图，作为设计阶段的文档。
这正是在需求分析阶段用 IPO
表作为描述算法的工具的重要优点。
3.8 验证软件需求验证软件需求的正确性，一般应从 4个方面进行：
(1) 一致性 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
(2) 完整性 需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
(3) 现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
(4) 有效性 必须证明需求是正确有效的，确实能解决用户面对的问题。
3.9 小结需求分析的任务,功能、性能、可靠性、可用性、接口、
约束条件获取需求的方法,访谈、会议、面向数据流逐步求精、
快速原型分析建模与规格说明,数据模型、功能模型、行为模型实体 -联系图 & 数据规范化状态转换图数据字典 &其他图形工具验证软件需求,一致性、完整性、现实性和有效性
