【软件工程】一篇入门需求分析中的数据流图（DFD图）

十二月的猫

已于 2025-01-22 11:57:43 修改

阅读量3.3k

点赞数 72

分类专栏： # 软件工程与面向对象文章标签：软件工程

于 2024-11-26 16:35:39 首次发布

本文链接：https://blog.csdn.net/m0_67656158/article/details/144054237

版权

软件工程与面向对象专栏收录该内容

25 篇文章

订阅专栏

🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客

💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光

1. 前言

在进入本篇文章前，大家可以按需求看看另几篇文章：

【软件工程】第一章·软件工程概述-CSDN博客

【软件工程】第二章·软件过程（过程与生命周期建模）-CSDN博客

【软件工程】第三章·计划和管理项目（详解活动图计算关键路径、最早开始时间、最晚开始时间、冗余时间）-CSDN博客

【软件工程】第四章·需求分析-CSDN博客

【软件工程】第五章·设计体系结构-CSDN博客

【软件工程】第六章·考虑对象（UML、UML在软件开发中的应用、面向对象方法的软件开发）-CSDN博客

【软件工程】第八章·单元/集成测试程序-CSDN博客

【软件工程】第九章·系统测试（因果图全解析）-CSDN博客

这几篇文章将让你对软件工程有一个整体的脉络，并在细节上有一定的把控🐮🐮

本文参考书籍：软件工程第4版（ [美] 莎丽·劳伦斯·弗里格（Shari Lawrence Pfleeger））

我这里简单总结一下和需求分析有关的部分：

软件工程：用系统化、工程化的方法解决软件开发问题

工程化方法：将软件开发的过程严格固定化，用工程标准的要求来限制，从而提高软件性能

工程化方法下软件开发过程如下：

软件分析
软件设计
程序编写
软件测试
软件部署
软件维护

软件分析又分为：

问题分析
可行性分析
需求分析

其中需求分析是最重要的一步

2. 需求分析概述

什么是需求分析，软件开发中需求分析又占据着什么地位？

在学习软件工程过程中，这两个问题一直困扰着我。

经过资料的整理和分析，写了这一篇博客，希望能记录下自己的学习心得，也希望能为大家的学习提供一点微末的帮助。

2.1 软件需求的概念

软件需求就是用户对目标软件系统的期望。

为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论人们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望,并且给开发者带来烦恼。需求分析是软件分析时期的最后一个阶段。

它的基本任务是回答"系统必须做什么"这个问题，最终成品是一份"软件需求规格说明书"。

通常来说，用户的需求包含了以下几个方面：

a. 功能需求

这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能

b. 性能需求

性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。

c. 可靠性和可用性需求

可靠性需求定量地指定系统的可靠性，可用性与可靠性密切相关，它量化了用户可以使用系统的程度。

d. 出错处理需求

这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么。需要注意的是，这类错误并不是由该应用系统本身造成的。

e. 接口需求

接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求、硬件接口需求、软件接口需求、通信接口需求。

f. 约束

设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。常见的约束有：精度、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台。

g. 逆向需求

逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，人们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。

h. 将来可能提出的要求

应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

2.2 需求分析的原则与模型

尽管目前有许多不同的用于需求分析的结构化分析方法，但是，所有这些分析方法都遵守下述准则，并且每一个准则有一个典型的分析方法。

1、必须理解并描述问题的信息域，根据这条准则应该建立数据模型

1、主要使用ERD工具，即实体—联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形；

2. 必须定义软件应完成的功能域，这条准则要求建立功能模型

2. 主要使用DFD工具，即数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，是建立功能模型的基础；

3. 必须描述作为外部事件结果的软件行为域，这条准则要求建立行为模型

3. 主要使用STD工具，即状态转换图，指明了作为外部事件结果的系统行为，描绘了系统的各种行为模式(称为"状态")和在不同状态间转换的方式，是行为建模的基础；

3. 需求分析之DFD图

需求分析需要完整的流程，这也体现前面说的工程化方法。

在这个完整的流程中，需要体现并运用前面我们提到的需求分析原则/模型。

在需求分析流程中，建立起需求分析模型，并利用模型进一步辅助需求分析。

本篇我们就来看看DFD这一个需求分析结构化模型~~ ✨✨

3.1 数据流图基本符号

正方形表示数据的源点或终点
圆角/矩形代表变换数据的处理
开口矩形代表数据存储
箭头表示数据流，即特定数据的流动方向

我们将数据分为三个部分：数据项、数据流、数据文件：

数据项：每一个单一数据

数据流：箭头上面的东西

数据文件：需要存储在数据库、磁盘中的东西

3.2 构建数据流图的完整流程

流程图如下：

这里运用了 形式化度量方法 进行软件需求分析

举个例子，学生购买教材系统：

1. 根据现实环境，建立具体模型：

2. 抽象当前系统的具体模型为逻辑模型：

3. 根据当前系统逻辑模型，建立目标系统的逻辑模型（目标系统比当前系统模型一般来说更强）：

4. 根据目标系统的逻辑模型，写出完整需求说明，并进一步完善目标系统的逻辑模型：

需求分析最后得到的就是：一个根据DFD图写出来的需求说明书

3.3 构建分层的DFD图的完整流程

需求分析要求我们从三个角度去思考软件开发的需求：信息域、功能域、行为域。

为了更好的从这三个角度去思考软件开发的需求，我们为每一个角度设计一个具体的模型。

通过按照模型具体的流程思考，我们能够很好的完成需求分析。

这里针对功能域做进一步的展开~~~~~

功能域的模型就是DFD图，通过上一环节给出的DFD图设计方案：

我们已经知道如何建立一个DFD图，并写出需求说明书。

但是在具体软件开发中，我们的函数都是由顶层向下层逐步展开的，因此我们需要将DFD图转化为分层DFD图，方便软件代码的编写，也促进进一步完善我们的需求分析。

分层DFD图层次结构：

1. 画出顶层DFD图

2. 展开顶层DFD图得到第二层DFD图：

3. 继续分解，得到第三层DFD图：

4. 数据字典

分层DFD图为整个系统描绘了一个概貌，下一步应该考虑系统的一些细节，例如定义系统的数据、确定加工的策略等问题了。

因此，我们要进一步深入去理解DFD图中数据部分（数据流、数据文件、数据项）。

这时，就需要一个工具 数据字典。

定义：

DFD中含有许多数据。字典的作用，就是对DFD中的每个数据规定一个定义条目，以保持数据在系统中的一致性。当用户或软件人员想了解某一数据的含义时，查一查字典就清楚了。它是DFD必不可少的辅助资料，对DFD起着注解的作用。

必要性：

一个软件系统通常有许多人参加开发和使用，用字典来给出所有数据的定义与属性，可避免因理解不同而造成混乱。鉴于它在软件开发与维护中的重要作用，有人把数据字典称为“数据的数据（data about data）”。

数据字典各个栏目的意义：

在条目内容中列入“别名”，是因为对同一数据可能存在不同的称呼。将它们在字典中载明，更方便查字典的人。但决不是说允许同一数据在系统中使用不同的名字，恰恰相反，在软件开发中必须以主名称为准，不许另用其它的名字。
数据项的“取值”用来规定数据的取值范围和类型。对于数据流和数据文件，则应在“组成”栏内列举组成该数据流或文件记录的所有数据项。
“组织（方法）”是数据文件特有的内容，用于说明文件中的记录将按照什么规则组合成文件。

4.1 计算机售书系统例子

我们再根据前面的那个计算机售书系统例子，来辅助大家理解数据字典：

1、数据流：

数据流以图2.10中的“发票”为例，其条目内容与书写格式可以如表2.3所示。

在组成栏中，“学号”、“姓名”、“书号”等都是数据项的名称。就本例而言，“学号”、“姓名”与 “书费合计”在数据流中仅出现一次，其余各数据项则每购买一种书就要出现一次。条目中用花括号｛｝表示重复，重复的次数可根据需要增减。假定某学生购买了5种书，则花括号｛｝中的四种数据项将各自重复五次。