第3章 需求分析

面向数据流自顶向下求精过程
3.2.3 简易的应用规格说明技术

简易的应用规格说明技术是一种面向团队的需
求收集法。 这种方法提倡用户与开发者密切合作，共同标 识问题，提出解决方案要素，商讨不同方案并 指定基本需求。

分析需求的典型过程如下： 1. 初步访谈，准备会议 首先进行初步的访谈，初步确定待解决的问题 的范围和解决方案。 然后开发者和用户分别写出“产品需求”。选 定会议的时间和地点，并选举协调人。 2. 会前审查需求，确定列表 要求每位与会者在开会的前几天认真审查产品 需求，并且列出对象、操作这些对象或与这些 对象交互的服务、约束条件和性能标准。
数据模型中包含3种相互关联的信息：


数据对象 数据对象的属性 数据对象彼此间相互连接的关系
3.4.1 数据对象

数据对象：是对软件必须理解的复合信息的抽 象。复合信息是指具有一系列不同性质或属性 的事物，仅有单个值的事物不是数据对象。 数据对象可以是外部实体、事物、行为、事件、 角色、单位、地点或结构等。 数据对象彼此间是有关联的。
3.3 分析建模与规格说明 3.3.1 分析建模


模型：就是为了理解事物而对事物做出的一种 抽象，是对事物的一种无歧义的书面描述。通 常，模型由一组图形符号和组织这些符号的规 则组成。 结构化分析过程：实质上是一种创建模型的活 动。系统分析员从不同角度抽象出目标系统的 特性，使用精确的表示方法构造系统的模型， 验证模型是否满足用户对目标系统的需求，并 在设计过程中逐渐把和实现有关的细节加进模 型中，直至最终用程序实现模型。
需求管理存在的问题： 范围问题：系统目标、边界未被良好定义，用 户和开发团队理解不一致。 理解问题：用户不能完全了解自己需要什么， 对系统能力、局限更加不清楚；工程师不理解 用户的问题域和应用环境。 易变问题：需求随时间发生变化。
需求工程： 20世纪80年代中期，形成了软件工程的子领 域——需求工程。 进入20世纪90年代后，需求工程称为软件界研 究的重点之一。 Alan Davis 把需求工程定义为“直到（但不包 括）把软件分解为实际架构构件之前的所有活 动”。


3.4.2 属性

属性：定义了数据对象的性质。必须把一个或
3.1.2 分析系统的数据要求



建立数据模型——ER图 描绘数据结构——层次方框图和Warnier图 数据结构规范化
3.1.3 导出系统的逻辑模型

综合上述两项分析的结果可以导出系统的详细
的逻辑模型，通常用数据流图、实体-联系图、
状态转换图、数据字典和主要的处理算法描述
这个逻辑模型。
3.1.4 修正系统开发计划
我国定义了GB856D-1988国家标准，给出了需求规格说 明的内容框架：
1 引言 1.1 编写目的 1.2 项目背景（单位和其他系统 的关系） 1.3 定义（专门术语和缩写词） 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件限制 3 数据描述 3.1 静态数据 3.2 动态数据 3.3 数据库描述 3.4 数据字典 3.5 数据采集 4 功能需求 4.1 功能划分 4.2 功能描述 5 性能需求 5.1 数据精确度 5.2 时间特性 5.3 适应性 6 运行需求 6.1 用户界面 6.2 硬件接口 6.3 软件接口 6.4 故障处理 7 其他需求 （检测或验收标准、可用性、可 维护性、可移植性、安全保密性）


快速原型的特性：

“快速”。快速原型的目的是尽快向用户提供 一个可在计算机上运行的目标系统的模型。因 此，原型的某些缺陷是可以忽略的。

“容易修改”。如果原型的第一版不是用户所 需要的，就必须根据用户的意见迅速地修改它， 构建出原型的第二版，以更好地满足用户需求。 如果修改耗时过多，势必延误软件开发时间。
3. 会上讨论列表，创建组合列表 每位与会者展示列表供大家讨论。大家共同创建一 张组合列表。由协调人主持讨论这些列表。 4. 分组制定小型规格说明 与会者分成更小的小组，为每张列表中的项目制定 小型规格说明。每个小组都向全体与会者展示他们 制定的小型规格说明，供大家讨论。 5. 制定确认标准，起草需求规格说明书 每个与会者都制定出产品的一整套确认标准，并提 交会议讨论，以创建出意见一致的确认标准。 最后，起草完整的软件需求规格说明书。
简易的应用规格说明技术的优点：

开发者与用户不分彼此，齐心协力，密切合作； 即时讨论并求精； 有能导出规格说明的具体步骤。
3.2.4 快速建立软件原型

快速建立软件原型是最准确、最有效、最强大
的需求分析技术。 快速原型就是快速建立起来的旨在演示目标系 统主要功能的可运行的程序。 构建原型的要点是，它应该实现用户看得见的 功能，省略目标系统的“隐含”功能。
传统与现代需求方法的比较：
需求管理过程 需求管理功能 需求管理思想方法 一成不变的观点， 局 限 于 需 求 分 注 重 具 体 的 需 注重“描述”的方 传统 析这一个阶段 求分析方法 法和过程，是纯技 术性的转换
功能范围更广， 包括获取、分 全过程的，注 注重需求实现与维 析、处理、验 现代 重 整 个 产 品 过 护过程，处理不断 证、实现和全 程的全部 变更的系统需求 过程的需求管 理
快速原型通常使用下述3种方法和工具：
(1) 第四代技术（4GL）

第四代技术包括众多数据库查询（如SQL）和
报表语言（如ADF）、程序和应用系统生成器
（如Power Builder和Oracle的应用开发环境）
以及其他非常高级的非过程语言。

第四代技术使得软件工程师能够快速地生成可 执行的代码，它们是较理想的快速原型工具。



需求：正在构建的系统必须符合的事务。 需求管理：是一种获取、组织并记录系统需求 的系统化方案以及一个使客户与项目团队不断 变更的系统需求达成并保持一致的过程。 传统需求分析：强调需求的记录，以一成不变 的观点对待需求，不重视需求实现与维护。 现代需求过程：包括需求的获取、分析、处理、 验证、实现和全过程的需求管理。需求管理覆 盖软件工程的整个过程。
需求工程的阶段划分：
现代软件工程的需求工程 需求开发过程 需求获取 需求分析 需求处理 需求确认 需求管理过程 需求实现 需求跟踪 需求变更控制
3.1 需求分析的任务

确定对系统的综合要求
分析系统的数据要求
导出系统的逻辑模型
修正系统开发计划
3.1.1 确定对系统的综合要求
1. 功能需求 2. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求

象
图
需求分析过程 应该建立3种模 型，分别是：

数据模型
处 述 理 描
功能模型
规 格
数
对

实

数据模型 功能模型 行为模型
系
说
据
据
-关
明
流
数
数据 字典
体
图
状态转换图
控制规格说明 行为模型
分析模型的结构




数据字典：是分析模型的核心，它描述软件使 用或产生的所有数据对象。 实体-联系图：描绘数据对象及数据对象之间 的关系，是用于建立数据模型的图形。 数据流图：描绘当数据在软件系统中移动时被 变换的逻辑过程，指明系统具有的变换数据的 功能，因此，数据流图是建立功能模型的基础。 状态转换图(简称为状态图)：指明了作为外部 事件结果的系统行为。为此，状态转换图描绘 了系统的各种行为模式(称为“状态”)和在不 同状态间转换的方式。状态转换图是行为建模 的基础。
2.2 打印 存单 存单
存款信息 储户
3.1 验证 账户
取款额 取款额
3.3 计算 利息 利息 3.4 打印利息 清单
账户信息 密码 储户 3.2 核对 密码
利息清单
细化的数据流图
3.4 实体-联系图

概念性数据模型是一种面向问题的数据模型， 是按照用户的观点对数据建立的模型。它描述 了从用户角度看到的数据，它反映了用户的现 实环境，且与在软件系统中的实现方法无关。
第四代技术特点： 简单易学，用户界面良好，面向问题、非过程化程度 高，用户只需告知系统做什么，而无需说明怎么做。 用4GL编程使用的代码量较少，并可成数量级地提高 软件生产率。 程序设计语言划代： 1GL是汇编语言； 2GL是高级程序设计语言，如FORTRAN，ALGOL， BASIC，LISP等； 3GL是增强性的高级程序设计语言，如PASCAL， ALGOL68，FORTRAN77等； 4GL是按计算机科学理论指导设计出来的结构化语言， 如ADA，MODULA－2，SMALLTALK－80，JAVA， VB，VC，VF等。

根据在分析过程中获得的对系统的更深入更具
体的了解，可以比较准确地估计系统的成本和 进度，修正以前制定的开发计划。
3.2 与用户沟通获取需求的方法

访谈
面向数据流自顶向下求精
简易的应用规格说明技术
快速建立软件原型
需求分析综合症 解决方案 需求诱导的方法：
被动式沟通 用户讲故事 介绍游戏规则 输出结果 主动式沟通 幻灯片放映 动画制作 仿真演示 交互演示 现场演示 复杂程度与成本 原型开发 交互式沟通
(2) 可重用的软件构件 另外一种快速构建原型的方法，是使用一组已 有的软件构件(也称为组件)来装配(而不是从头 构造)原型。 软件构件可以是数据结构(或数据库)，或软件 体系结构构件(即程序)，或过程构件(即模块)。 (3) 形式化规格说明和原型环境 非形式化方法：自然语言描述 半形式化方法：数据流图或实体-联系图 形式化方法：基于数学的技术