软件工程导论——3需求分析（上）

需求分析的概念和过程

重点是需求分析的一般步骤、数据流图、用例图、活动图、需求规格说明文档的编制。掌握结构化分析模型的导出、数据流图/用例图/活动图的基本画法和需求规格说明文档的编制；理解需求分析的过程、主要步骤。主要知识点：

什么是需求

软件需求是用户为解决某个问题或实现某个目标，要求软件必须满足的条件和能力。（与技术无关，不关心具体使用什么技术）

业务需求

• 客户对产品的高层次的目标要求
• 业务范围、目标用户、价值等
• 客户管理人员确定

用户需求

• 用户对软件的功能要求和非功能要求
• 系统外部行为
• 用户协助提供

功能需求

开发人员需要开发实现的功能以及对这 些功能的补充要求

非功能性需求（涉及到数字）

根据IEEE1998分类，非功能需求包括
– 性能需求：如响应时间、并发量等
– 质量属性：可靠性、可维护性等
– 对外接口：硬件接口、软件接口、数据库接口等
– 约束：硬件设施、编程语言等

软件需求规格说明

• 产品遵从的标准、规范和合约
• 外部界面
• 功能要求、非功能要求
• 设计和实现的约束
• 质量要求

需求工程

需求工程是指应用已证实有效的技术和方法进行需 求的获取和分析，确定客户需求，并通过合适的工 具和符号，系统的描述出目标系统及其行为特征和 相关约束。

需求获取

基于用例的方法获取需求（用例图）

用例：
– 从用户角度描述系统的一项功能
– 表示参与者与系统之间的交互，系统执行该动 作序列为参与者产生结果。
– 一个系统包含若干个相互关联的用例
– UML表示：椭圆，用例名称放在椭圆中心或椭 圆下方中间的位置
– 用例名称通常使用动词短语或者动名词组：如 选课、存款、登录、查询
– 任何用例都不能在缺少参与者的情况下独立存 在
– 任何参与者也必须要有与之关联的用例

识别用例
– 识别用例的最好方法就是从分析系统参与者开始，在这 个过程中往往会发现新的参与者，可以通过以下问题来 寻找用例：
①参与者希望系统提供什么功能？
②参与者是否会创建、读取、修改、删除、存储系统 的某种信息？如果是的话，参与者又是如何完成这些 操作的？
③参与者是否会将外部的某些事件通知给系统？ ④系统中发生的事件是否通知参与者？
⑤是否存在影响系统的外部事件？

基于用例的方法获取需求步骤：
①确定系统边界
②确定系统参与者：系统之外，与系统交互的人员、外部软件系统、硬件设备
③确定和绘制用例图
根据每个参与者去寻找用例
理清用例之间的关系
理清参与者之间的关系
合并
④编制用例描述文档（用例规约）
用例规约应该包含以下内容：
1、用例说明:对用例作用和目的的简要描述。
2、 事件流:事件流包括基本事件流和备选事件流。
基本事件流描述的 是用例的基本流程，是指用例“正常”运行时的场景。
备选事件流描 述的是用例的备选流程，指用例“异常”运行时的场景。
3、前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是 要求用户有访问的权限或是要求某个用例必须已经执行完。
4、后置条件：用例执行完毕后系统可能处于的一组状态。例如，要求 在某个用例执行完后，必须执行另一个用例。
5、 补充说明: 用例的非功能性需求和设计约束等。

例1（小型图书资料管理系统的用例图）：
• 实现对图书资料的借出、归还、查询和管理；
• 有图书管理员和普通读者两种用户；
• 图书管理员：
– 添加、更新、删除图书资料信息；
– 登记和查询图书资料的借出和归还情况；
• 普通用户：
– 需要先注册才可以使用该系统；
– 可以按照作者或者主题检索图书资料信息；
– 可以预定目前借不到的图书资料，一旦预定的图书资料 被归还或者购买，则系统通知预订者。

1、确定系统边界和参与者

2、确定和绘制用例图




3、编制用例图描述文档
1.用例说明
本用例允许图书管理员登记普通读者的借书记录
2.事件流
2.1 基本事件流
（1）系统请求图书管理员输入读者的注册号和所借图书的书目
（2）系统产生一个唯一的借书记录号
（3）系统显示新生成的借书记录
（4）图书管理员确认后，系统增加一个新的借书记录
2.2 备选事件流
（1）如果读者没有注册，…
（2）如果所借图书书目不存在，…
3.前提条件
用例开始之前，图书管理员必须在系统登录成功
4.后置条件
如果用例执行成功，该读者的借书记录被更新，否则系统状态不变
5.补充说明

需求分析

分析获取的需求

完整性：每项需求都有清楚完整的描述
正确性：每项需求正确无歧义
合理性
可行性
• 技术可行性
• 经济可行性（成本及收益）
• 社会可行性（无侵权）
– 充分性：需求全面周到

需求分析的方法

结构化需求分析方法（SA）/传统的需求分析方法

结构化需求分析模型

1、流程建模（流程图（4））

	• 不同图形块之间以箭头相连，代表信息在系统内的流动方向，表达数据在系统各部件之间流动的情况 
	• 与程序流程图符号类似，但表达不同含义1

2、功能建模

数据流图（1）

以图形方式展示系统中数据是如何加工处理和流动的
缺点：无法判断活动的时序关系
数据流图描绘系统的逻辑模型，图中无具体的物理元素，只是描绘信息在系统中流动和处理的情况
数据流图英文缩写DFD（Data Flow Diagram）它是描绘信息流和数据从输入移动到输出的过程中所经受的变换。图中没有任何具体的物理部件。
设计数据流图只需考虑系统必须完成的基本逻辑功能。
在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。

数据流图与程序流程图中用箭头表示的控制流有本质不同
在数据流图中应描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件
处理并不一定是一个程序，可以代表一系列程序、单个程序或者程序的一个模块，甚至人工处理过程
一个数据存储也并不一定是一个文件，它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等等

数据流图分层
自顶向下，功能分解
– 顶层数据流图：只含一个加工，表示整个系统
– 中间数据流图：对父图中的某个加工细化形成子图
– 底层数据流图：加工不能再分解，称为“原子加工”
– 注意父图与子图之间的平衡

例1（招生系统）：
招生系统的需求：
– 学校公布招生条件
– 考生根据自己的条件报名
– 系统进行资格审查，给出资格审查信息
– 资格审查合格的考生可以参加答卷
– 系统根据学校提供的试题及答案进行自动判卷 – 给出分数及答题信息，供考生查询
– 系统根据学校的录取分数线进行录取
– 系统将录取信息发送给考生

1、顶层数据流图：

2、招生系统功能分解：

招生系统一层数据流图：

例2（银行储蓄系统）：
• 储户填写存款申请单或者取款申请单，由业务员输入系统
• 如果是存款，则
– 系统记录存款人姓名、住址、电话号码、身份证号码、 存款类型、存款日期、到期日期、利率、密码等信息
– 系统进行存款处理，然后印出存款单给储户
• 如果是取款，则
– 系统核对储户密码
– 若密码正确，则系统进行取款处理
– 然后计算利息并印出取款单给储户

银行储蓄系统顶层数据流图：

银行储蓄系统功能分解：

银行储蓄系统一层数据流图：

银行储蓄系统二层数据流图：

IPO图（4）

IPO图（Input Process Output）是输入、处理、输出图的简称
• 由IBM公司发展完善起来的一种图形工具
• 能够方便地描述输入数据、对数据的处理、和输出数据之 间的关系
• 基本形式：
– 左边框：列出有关的输入数据
– 中间框：列出主要的处理，次序代表执行次序
– 右边框：列出产生的输出数据
– 使用粗大箭头指出数据通信情况
• 优点：简单易学
• 缺点：不足以精确描述执行处理的详细情况

3、数据建模

ER图（2）

• Entity-Relationship Diagram – ER
• 数据对象（实体）；矩形表示
• 数据对象的属性：圆角矩形或椭圆

例1（选课系统）：

例2（银行储蓄系统）：

数据字典（4）

	以词条方式定义在系统中出现的数据对象 
	• 字典式顺序组织 
		①数据流词条 
		②数据元素词条 
		③加工词条 
		④数据存储文件词条 
		⑤数据源点及数据汇点词条

4、行为建模

状态转移图（3）

• State Transition Diagram – STD
• 状态迁移图、状态图
• 通过描述系统的状态以及引起系统状态转换的事件，来表 示系统的行为
• 状态
– 可被观察到系统行为模式，规定对事件的响应方式
– 初态、中间状态、终态
• 事件
– 某个特定时刻发生的事情，引起系统动作或者状态转换

例1（电话系统）：

例2（银行储蓄系统）：

1、需求分析的概念

2、需求分析的过程：需求确认与需求变更

3、需求确认的步骤：需求获取→需求提炼→需求描述→需求验证

4、需求分析三类建模：功能模型、数据模型、行为模型。面向过程和面向对象的需求分析过程中，三类模型各包含哪些内容？

功能模型：

数据流图、IPO图

数据模型：

E-R图、数据字典

行为模型：

状态转换图

5、掌握数据流图和用例图作法。