软件工程：第三章需求分析

导学目标

了解需求分析的目的和基本任务等
了解常见的获取需求的方式
掌握需求分析建模和结构化分析方法
掌握**实体联系图（E-R图）**画法
了解数据规范化分类及目的
掌握状态转换图的画法
了解层次方框图和IPO图

第一节需求分析的任务

3.1.1 需求分析

软件定义时期的最后一个阶段，准确的回答系统必须做什么这个问题

系统分析员和用户一起商定

清楚、准确、具体的描述软件产品必须具备的功能、性能、运行规则等各方面的要求

3.1.2 需求分析的任务

基本任务

准确的回答系统必须做什么的问题

具体任务

确定软件系统的综合需求
分析系统的数据需求
- 数据模型、信息模型E-R图、层次方框图
导出软件系统的逻辑模型
- 数据流图、E-R图、状态转化图、数据字典、算法
修正系统的开发计划
验证软件需求分析的正确性
编写软件规则需求说明书

确定软件系统的综合需求

功能需求：系统必须提供的服务
- 系统要做什么？
- 系统什么时候做什么？
- 系统何时修改或者升级？
性能需求：系统必须满足的定时约束或者容量约束等
- 软件开发的技术性指标，包括响应时间、存储容量限制、执行的速度以及吞吐量
可靠性和可用性需求
- 系统可靠性要求？
- 系统平均出错时间？
- 出错后重启系统允许的时间？
出错处理需求
- 系统对环境错误应该如何响应
接口需求：系统与它的环境通信格式要求
- 用户接口需求
- 硬件接口需求
- 软件接口需求
- 通信接口需求
约束需求：设计或实现约束时应遵守的限制条件例如精度、工具、语言、设计、标准、平台等
- 环境约束
- 界面约束
- 用户或者人的因素约束
- 文档约束
- 数据约束
- 资源约束
- 安全保密要求约束
- 软件成本消耗与开发进度需求
逆向需求：说明系统不应该做什么
将来可能提出的要求

3.1.3 需求分析的注意事项

工作大致分为4个阶段

对问题的识别
分析与综合
制定规格说明
评审

3个基本原则

必须能够表达和理解问题的数据域和功能域
必须按自顶向下、逐步分解的方式对问题进行分解和不断细化

要给出系统的逻辑视图和物理视图

3.1.4 优秀需求分析的特点

完整性
正确性
可行性
必要性
划分优先级
无二义性
可验证性

第二节获取需求的方法

3.2.1 需求获取存在的问题

客户说不清楚自己的需求
需求常常变化
问题的复杂性和对问题空间理解的不完备性与不一致性

3.2.2 需求获取的方法

访谈

基本形式：正式、非正式访谈
需要收集大量人员意见：使用调查表
情景分析技术：对用户将来使用目标系统解决某个具体问题的方法和结果进行分析
情景分析技术的用途：
- 一定程序上演示目标系统的行为，方便用户理解
- 保证用户在需求分析过程中扮演一个积极主动的角色

面向数据流自顶向下求精

结构化分析方法
从系统的高层数据流图输出端出发
对不清楚的地方可以与用户和其他人员交流
利用数据流图、数据字典、IPO图向用户解释系统
根据用户反馈进行补充
细化数据流图

简易的应用规格说明

面向团队的需求收集法
提倡用户与开发者密切合作
信息系统领域使用的主流技术
典型过程
- 初步访谈
- 开发者和用户分别写产品需求
- 组织会议，会前审查产品需求
- 会议讨论，严禁批评与争论
- 针对每个议题创建一张意见一致的列表
- 小组制定小型规格说明，供大家讨论

快速建立软件原型(了解)

实现用户看得见的功能
快速
容易修改

第三节需求分析建模

3.3.1 需求分析的四个阶段

调查研究
- 系统分析员协同程序员向用户做需求调查，根据可行性报告和项目开发计划报告，确定系统必须做什么，并获得当前系统的具体模型，用数据流图或者IPO 图表示出来
- 【补充数据字典、修改IPO 图】
分析综合
- 系统分析员从数据流和数据结构出发，逐步细化所有软件的功能，剔除其中不合理部分，增加其需要的部分，最终合成系统的解决方案，并给出目标系统的详细逻辑模型
- 【系统分析员和用户追踪数据流图，复查系统逻辑模型】
书写需求分析文档
- 把分析的结果用正式的文档记录下，主要包括4份文档资料：系统规格说明书、数据需求、用户系统描述、修正的开发计划
- 【系统规格、数据要求、用户系统描述等文档】
需求分析评审
- 作为需求分析的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性以及其他需求给与评价。
- 【评审结果】

3.3.2 需求分析阶段常用的模型（逻辑模型）有三种

数据模型
- E-R图：描述数据对象与数据对象之间的关系
功能模型
- 数据流图：描述数据在软件系统中移动时被变换的逻辑过程
行为模型
- 状态转换图：描绘了系统中的各种状态以及不同状态间转换的方式

需求分析步骤

3.3.3 结构化分析方法

结构化分析方法是70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法
核心思想是分解化简问题、物理与逻辑表示分开、进行数据与逻辑抽象
适用于分析大型数据处理系统，特别适合企事业管理系统
使用的建模工具主要包括
- 数据流图：表达系统内数据的流动情况
- 数据字典：用于定义系统中的数据元素
- 结构化语言、判断表、判定树：描述数据流的加工的工具

第四节实体联系图

3.4.1 概念性模型

定义

概念性模型也叫做信息模型，是一种面向问题的数据模型，按照用户的观点对数据进行建模

最常用的概念数据模型

实体联系图（Entity-Relationship Diagram），简称ER图

作用

有助于理解业务和系统中数据组成的关系及交互
可以使用简单的符号使不熟悉计算机的用户也能理解

组成ER模型的三要素

数据对象
- 具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象
- 数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构等
- 数据对象使用矩形框表示
- 数据对象之间是彼此有关联的
属性
- 定义了实体或者联系所具有的性质
- 用椭圆形或者圆角矩形表示
联系
- 数据对象彼此之间相关连接的方式
- 联系可以是一对一、一对多、多对多的关系
- 用菱形框表示
- 联系也可以有属性

3.4.2 实例分析

一个图书馆借阅管理数据库要求提供下述服务：

（１）可随时查询书库中现有书籍的品种、数量与存放位置。所有各类书籍均可由书号唯一标识。

（２）可随时查询书籍借还情况，包括借书人单位、姓名、借书证号、借书日期和还书日期。我们约定：任何人可借多种书，任何一种书可为多个人所借，借书证号具有唯一性。

（３）当需要时，可通过数据库中保存的出版社的电报编号、电话、邮编及地址等信息下相应出版社增购有关书籍。我们约定，一个出版社可出版多种书籍，同一本书仅为一个出版社出版，出版社名具有唯一性。

根据上述描述，画出满足需求的E-R图

第五节数据规范化

目的

减少数据冗余
避免插入或者删除异常
简化数据修改的过程

范式

范式消除数据的冗余程度
范式分为1NF~5NF，1NF 冗余程度最大，5NF 冗余程度最小
- 第一范式（1NF）
  - 数据的冗余程度最大
  - 每个属性必须是原子值，即仅仅是一个简单值而不含内部结构
- 第二范式（2NF）
  - 满足一范式条件
  - 每个非关键字属性都由整个关键字决定
- 第三范式（3NF）（一般使用最多）
  - 满足第二范式条件
  - 每个非关键字属性都仅由关键字决定，一个非关键字属性值不能依赖于另一个非关键字属性值

第六节状态转换图

3.6.1 状态转换图

状态转换图

简称状态图
通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为

状态

任何可以被观察到的系统行为模式
一个状态代表系统的一种行为模式
状态规定了系统对事件的响应方式
主要状态
- 初态（初始状态）：仅1个
- 终态（最终状态）：0-N个
- 中间状态
状态图可以表示系统循环运行的过程，而不关心循环如何启动
状态图可以表示系统单程生命期，需注明初始状态和最终状态

事件

某个特定时刻发生的事情
引起系统做动作或从一个状态转换到另一个状态
简而言之，事件就是引起系统做动作或状态转换的控制信息

符号

在状态图中，初态是实心圆
终态是同心圆（内圆为实心圆）
中间状态是圆角矩形，共分成上中下三个部分
- 状态名称**（必须有**）
- 状态变量名和值**（可选）**
- 活动表**（可选）**

示例

示例名词解释

活动表
- 语法格式：事件名（参数表）/动作表达式
- 事件名可以是任何事件的名称，经常使用3种标准事件
  - entry事件：指定进入该状态的动作
  - exit事件：指定退出该状态的动作
  - do事件：指定在该状态下的动作
- 参数表：需要时可以为事件指定
- 动作表达式：描述应该做的具体动作
事件表达式
- 语法格式：事件说明[守卫条件]/动作表达式
- 事件说明的语法：事件名（参数表）
- 守卫条件是一个布尔表达式
- 如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生；如果只有守卫条件而没有事件说明，只要守卫条件发生，则状态转换就发生
- 动作表达式是一个过程表达式，当状态转换开始时执行该表达式

3.6.2 案例

图书状态图

电话系统状态图

第七节其他图形工具

3.7.1 层次方框图

用树形结构的一系列多层次的矩形框描述数据的层级结构
示例

3.7.2 IPO 图

输入、处理、输出图的简称
IBM 公司发展完善的一种图形工具
示例