软件需求分析的任务和过程.

④ 考察现场
了解用户实际的操作环境、操作过 程和操作要求。对照用户提交的问 题陈述，对用户需求可以有更全面、 更细致的认识。 调查研究方式有：发调查表；召开 调查会；向用户领域的专家个别咨 询；实地考察，跟踪现场业务流程； 查阅与待开发系统有关的资料；使 用各种调查工具等。
需求分析的过程
(1) 问题识别

需求分析的任务就是借助于当前系 统的逻辑模型导出目标系统的逻辑 模型，解决目标系统的 “做什么” 的问题。
怎么做 做什么
抽象化 逻辑模型 模型化
当前系统
物理模型
理 导解 需 出求
表 达 需 求
目标系统
具体化
物理模型
实例化
逻辑模型


通常软件开发项目是要实现目标系 统的物理模型 目标系统的具体物理模型是由它的 逻辑模型经实例化，即具体到某个 业务领域而得到的
课程


进一步，要确定属性。例如， 学生具有学号、姓名、性别、出 生年月、专业（其它略）等属性； 课程具有课程号、课程名、学分、 学时数等属性； 教师具有职工号、姓名、年龄、 职称等属性。 为每一个数据对象建立数据对象表， 描述其属性，如此可得“教学”数 据模型。
学号 姓名 专业 性别 ……


数据对象只封装了数据，没有包含作 用于这些数据上的操作。 属性 定义了数据对象的特征。它可 用来： 为数据对象的实例命名； 描述这个实例； 建立对另一个数据对象的另一个实 例的引用。



为了唯一地标识数据对象的某一个实 例，定义数据对象中的一个属性或几 个属性为关键码 (key)，书写为_id， 例如在“学生”数据对象中用“学号” 做关键码，它可唯一地标识一个“学 生”数据对象中的实例。 关系 各个数据对象的实例之间有关 联。如一个学生“张鹏”选修两门课 程“软件工程”与“计算机网络”， 学生与课程的实例通过“选修”关联 起来。

然后从输入端开始，根据商店业 务工作流程，画出数据流流经的 各加工框，逐步画到输出端，得 到第一层数据流图
第一层数据流图
加细每一个加工框
销售细化
采购细化
检查和修改数据流图的原则




数据流图上所有图形符号只限于前 述四种基本图形元素 数据流图的主图必须包括前述四种 基本元素，缺一不可 数据流图的主图上的数据流必须封 闭在外部实体之间 每个加工至少有一个输入数据流和 一个输出数据流

软件需求方法



需求分析方法由对软件问题的信息 域和功能域的系统分析过程及其表 示方法组成 大多数的需求分析方法是由信息驱 动的 信息域具有三种属性: 信息流、信 息内容和信息结构。
结构化分析方法

结构化分析方法是一种建模技术 在模型的核心是数据词典，它描述 了所有的在目标系统中使用的和生 成的数据对象。围绕着这个核心的 有三种图： 实体—关系图(ERD) 描述数据对 象及数据对象之间的关系；
数据流图(DFD) 描述数据在系统 中如何被传送或变换，以及描述 如何对数据流进行变换的功能 （子功能）； 状态—迁移图(STD)描述系统对 外部事件如何响应，如何动作。 ERD 用于数据建模，DFD用于功 能建模，STD用于行为建模。

结构化分析的分析模型
数据对象描述 实体— 关系图 数据流 图 加工规格说明

用E-R图描述它们之间的关联，得下 图。其中，学生与课程是多对多的关 联，教师与课程的关联是 0/1 对多。
学生
教师
课程

由于“多对多”的关联在计算机表达 时有困难，引入“选课”对象作为关 联对象，可将“多对多”的关联改为 两个“一对多”的关联。
学生 数据对象表 学号 姓名 性别 出生年月 籍贯 …… 选 课
⑵ 以层次化的方式对问题进行分解和 不断细化 软件的功能域和信息域都 能做进一步的分解。这种分解可以是 同一层次上的，称为横向分解；也可 以是多层次的纵向分解。
纵 向 分 解
横向分解
⑶ 要给出系统的逻辑视图和物理视图 软件需求的逻辑视图给出的是软件 要达到的功能和要处理的数据之间 的关系，而不是实现的细节。 软件需求的逻辑描述是软件设计的 基础。 软件需求的物理视图给出的是处理 功能和数据结构的实际表现形式， 这往往是由设备本身决定的。
商店业务处理系统


这个数据流图只是一个高层的系统 逻辑模型，它反映了目标系统要实 现的功能 数据流图绘制步骤
首先确定系统的输入和输出 根据商店业务，画出顶层数据流 图，以反映最主要业务处理流程


经过分析，商店业务处理的主要 功能应当有销售、采购、会计三 大项。主要数据流输入的源点和 输出终点是顾客和供应商。
软件需求规格说明的原则



从现实中分离功能，即描述要“做 什么”而不是“怎样实现” 要求使用面向处理的规格说明语言 （或称系统定义语言） 如果被开发软件只是一个大系统中 的一个元素，那么整个大系统也包 括在规格说明的描述之中

规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许 扩充 规格说明必须局部化和松散耦合
软件需求分析的任务和过程 结构化分析方法 原型化方法 数据及数据库需求

软件需求分析的任务


深入描述软件的功能和性能
确定软件设计的约束和软件同 其它系统元素的接口细节 定义软件的其它有效性需求



需求分析研究的对象是软件项目的 用户要求 准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统 元素中
(4) 需求分析评审




系统定义的目标是否与用户的要求 一致; 系统需求分析阶段提供的文档资料 是否齐全; 文档中的所有描述是否完整、清晰、 准确反映用户要求; 与所有其它系统成分的重要接口是 否都已经描述;





被开发项目的数据流与数据结构是 否足够，确定; 所有图表是否清楚，在不补充说明 时能否理解; 主要功能是否已包括在规定的软件 范围之内，是否都已充分说明; 设计的约束条件或限制条件是否符 合实际; 开发的技术风险是什么;
基数:一位教师
教师
管带
基数:多位学生
学生
参与度:必须
参与度:可选
( Entity-Relationship Diagram)

E- R图
在需求分析阶段描述数据对象和它们 之间的关系，使用了E-R图。

E-R图中表示实体关联的符号如下：
X
X X X X
Y
Y Y Y Y
一个X与一个Y相关联
一个X与一个或多个Y相关联
常用的分析方法

面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开 发方法 (DSSD) 面向对象的分析方法 (OOA) 等

(3) 编制需求分析阶段的文档

软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计 划
需求获取技术


需求获取技术包括两方面的工作： 建立获取用户要求的方法的框架； 支持和监控需求获取的过程的机制。 获取用户需求的主要方法是调查研究。 ① 了解系统的需求 软件开发是系统开发的一部分,仔细 分析研究系统的需求规格说明,对软 件的需求获取是很有必要的。
② 市场调查
了解市场对待开发软件有什么样的 要求；了解市场上有无与待开发软 件类似的系统 ③ 访问用户和用户领域的专家 把从用户那里得到的信息作为重要 的原始资料进行分析；访问用户领 域的专家所得到的信息将有助于对 用户需求的理解。
职工号
学生
教师
ห้องสมุดไป่ตู้
姓名 专业
选课 学号 课程号 成绩 课程
职称
年龄
课程号 课程名 学分 学时 ……
教学数据模型
功能建模和数据流

最初, 结构化分析方法仅讨论数据流 建模。目标系统被表示成如图所示的 数据变换流程图。系统的功能体现在 核心的数据变换中。
外部实体 输入信息 目标 系统 外部实体 输入信息 输出信息 外部实体 输出信息 外部实体



在数据流图中，需按层给加工框编 号。编号表明该加工所处层次及上 下层的亲子关系 规定任何一个数据流子图必须与它 上一层的一个加工对应，两者的输 入数据流和输出数据流必须一致。 此即父图与子图的平衡 可以在数据流图中加入物质流，帮 助用户理解数据流图
数据 字典
状态—迁移图
控制规格说明
分析模型的三个视图





数据建模和对象描述 功能建模和数据流图 基本加工逻辑说明 行为建模 数据词典
数据建模



数据模型包括三种互相关联的信息： 数据对象，描述对象的属性，描述对 象间相互连接的关系。 数据对象 是需被目标系统所理解的 复合信息的表示。它具有若干不同特 征或属性的信息。 数据对象可以是外部实体,事物, 角色, 行为或事件, 组织单位, 地点或结构。
分层的数据流图



在多层数据流图中，顶层流图仅包 含一个加工，它代表被开发系统。 它的输入流是该系统的输入数据， 输出流是系统所输出数据 底层流图是指其加工不需再做分解 的数据流图，它处在最底层 中间层流图则表示对其上层父图的 细化。它的每一加工可能继续细化， 形成子图。
结构化分析方法功能建模的步骤
数据流图中的主要图形元素 数据加工 (数据变换) 数据源点或终点 (外部实体)
数据流
数据存储文件
描述银行取款过程的数据流图
数据流与数据加工之间的关系
数据流图的层次结构

为了表达数据处理过程的数据加工 情况，需要采用层次结构的数据流 图。按照系统的层次结构进行逐步 分解，并以分层的数据流图反映这 种结构关系，能清楚地表达和容易 理解整个系统
问题识别的另一项工作是建立分析所 需要的通信途径，以保证能顺利地对 问题进行分析。
(2) 分析与综合

从信息流和信息结构出发，逐步细 化所有的软件功能，找出系统各元 素之间的关联、接口特性和设计上 的约束，分析它们是否满足功能要 求，是否合理。剔除其不合理的部 分，增加其需要部分。最终综合成 系统的解决方案，给出目标系统的 详细逻辑模型。



从系统的角度来理解软件并评审软 件范围是否恰当 确定对目标系统的综合要求，即软 件的需求 提出这些需求实现条件，以及需求 应达到的标准
软件的需求包括：

功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求

资源使用需求 成本消耗需求 开发进度需求 预先估计以后 系统可能达到 的目标
一个X与零个或一个Y相关联
一个X与零个, 一个或多个Y相关联 一个X与一个Y或Z相关联
Z
Y 一个X与一个Y与Z相关联
X
Z


在E-R图中，每个方框表示数据对 象或属性，方框之间的连线表示数 据对象之间，或对象与属性之间的 关联。出现在连线上的短竖线可以 看成是“1”，而圆圈隐含表示“0”。 例如，在教学管理中，一个教师可 以教授零门、一门或多门课程，每 位学生也需要学习几门课程。因此， 教学管理中涉及的对象（实体型） 有学生、教师和课程。
功能建模的思想


功能建模就是用抽象模型的概念，按 照软件内部数据传递、变换的关系， 自顶向下逐层分解，直到找到满足功 能要求的所有可实现的软件为止。 根据DeMarco的论述，功能模型使用 了数据流图来表达系统内数据的运动 情况，而数据流的变换则用结构化英 语、判定表与判定树来描述。
数据流图



是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需 求; 是否详细制定了检验标准，它们能否 对系统定义是否成功进行确认;
需求分析流程
软件需求分析的原则
⑴ 需要能够表达和理解问题的信息域 和功能域 信息域应包括 信息流：数据和控制通过一个系统 时的变化方式。两个功能之间的数据 /控制传递就确定了功能间的接口。 信息内容：单个数据或控制对象， 它们构成了某个更大的由软件变换生 成的信息的集合。 信息结构：各种数据和控制项的内 部组织。



实例的关联有三种：一对一 (1:1)； 一对多(1:m)；多对多(n:m)。 这种实例的关联称为“基数”。基数 表明了“重复性”。如 1 位教师带学 生班的 30 位同学，就是 1:m 的关系。 但也有 1 位教师带 0 位同学的情形, 所以实例关联有是“可选”还是“必 须” 之分。用“O”表示关系是可选 的，用“│”表示关系必须出现 1 次。 这表明了关系的“参与性”。