软件工程：需求分析

type

status

date

slug

summary

软件需求分析基础

1 需求分析的概念

基本任务：回答“系统必须做什么”这一核心问题

需求分析是发现、求精、建模和规约的过程。

这一过程包括：详细精化最初由系统分析员建立在软件项目计划中确定的软件范围，创建所需的数据流、控制流以及操作行为的模型，在此基础上选择解决方案。

需求分析的前置任务

问题定义：回答要解决的为是什么，是软件生存周期中国最简短的阶段。

可行性研究阶段：对于上一个阶段所确定的问题有行得通的解决办法吗？

问题的初步认识、市场调查、分析准备、环境分析、物理分析、功能分析、信息分析、动态分析、确立系统方案进行歌中歌估算、模型评审、系统建模

2 需求分析

2.1 需求分析

需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口，并建立软件必须满足的约束。

需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。

需求规约为软件设计师和客户提供了软件建造完成后，进行质量评估的依据。

2.2 需求的定义

需求的定义（IEEE）：

用户解决问题或达到目标所需要的条件

系统或系统部件要满足合同、标准、规范或其他正式规定的文档所要具有的条件

反映上面两条的文档说明。

通俗的需求定义：

需求是指明系统必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

2.3 需求的类别

功能需求：制定系统必须提供的服务，通过需求分析应该给划分出系统必须完成的所有功能。

性能需求：制定系统必须满足的定时约束或容量约束。

可靠性和可用性需求：定量地指定系统的可靠性和可用性。

出错处理需求：说明系统对环境错误应该怎样响应。

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

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

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

将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。

2.4 需求分析的任务

需求分析的任务是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。

获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，并用一个具体的模型来反映自己对当前系统的理解。

抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。

建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。

对目标系统逻辑模型进行补充：具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。

需求分析的具体任务

确定对系统的综合要求

分析系统的数据要求

导出系统的逻辑模型

修正系统开发计划

3 数据流图DFD

3.1 结构化的分析方法

结构化的分析方法是最经典的需求分析方法。适用于数据处理类型软件的需求分析。

它提供的工具包括：数据流图、数据字典、结构化英语、判定表和判定树。

系统的分析模型必须达到三个主要目标：

描述客户的需要；

建立创建软件设计的基础；

定义在软件完成后可以被确认的一组需求。

3.2 相关概念

模型的核心是数据字典——一个包含了软件使用或生产的所有数据对象描述的中心库。

数据字典包括数据流条目、文件条目、加工条目

实体-关系图描述数据对象间的关系，实体-关系图是用来进行数据建模活动的。

数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能（和子功能）。它可以用于信息域的分析，作为功能建模的基础。

状态转换图指明系统将如何动作。为此，状态转换图表示了系统的各种行为模式（称为“状态”），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。

数据流图的基本符号

3.3 数据流图的绘制

数据流图有4种成分：源点和终点、处理、数据存储和数据流。画出上述定货系统的数据流图可采用以下步骤。

首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部每天需要一张订货报表”，“通过放在仓库中的终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。

接下来考虑处理。再一次阅读问题描述，“采购部需要报表”，显然他们还没有这种报表，因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量，而任何改变数据的操作都是处理，因此，对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。

最后考虑数据流和数据存储。系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生报表和处理事务这两个处理在时间上明显不匹配：每当有一个事务发生时立即处理它，然而每天只产生一次订货报表，因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储（存储着订货报表的数据，每当订货报表的数据有更新时，可以立即获取最新的订货报表的数据，这样就可以实现每当有一个事务发生时立即处理它）。

注意，并不是所有数据存储和数据流都能直接从问题描述中提取出来。例如，“当某种零件的库存数量少于库存量临界值时就应该再次订货”，这个事实意味着必须在某个地方有零件库存量和库存量临界值这样的数据。因为这些数据元素的存在时间看来应该比单个事务的存在时间长，所以认为有一个数据存储保存库存清单数据是合理的。

3.4 示例：工厂订单报表

假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据:零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。

一旦把数据流图的4种成分分离出来后，就可以着手画数据流图了。但是要注意，数据流图是系统的逻辑模型，而任何计算机系统实质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。因此，任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。

3.4.1 顶层数据流图

对于上述的定货系统可以画出下图所示的顶层数据流图（突出表明了数据的源点和终点）。

从顶层数据流图这样非常高的抽象层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点 / 终点是一目了然的，因此它是很有价值的沟通工具。

3.4.2 第0层数据流图

顶层数据流图太抽象了，从这张图上所能了解到的信息非常有限。下一步应该把基本系统模型细化，描绘系统的主要功能。

由于 “产生报表” 和 “处理事务” 是该系统必须完成的两个主要功能，它们将代替图顶层数据流图中的“订货系统”。此外，细化后的数据流图中还增加了两个数据存储：处理事务需要“库存清单”数据；产生报表和处理事务在不同时间，因此需要存储“定货信息”。除了2.1节（2.1 数据流图有4种成分分析）的表中列出的两个数据流之外还有另外两个数据流，它们与数据存储相同。这是因为从一个数据存储中取出来的或放进去的数据通常和原来存储的数据相同，也就是说，数据存储和数据流只不过是同样数据的两种不同形式（事务 <–> 库存清单，订货信息 <–> 订货报表）。

给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。

3.4.3 第1层数据流图

接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。考虑通过系统的逻辑数据流，当发生一个事务时必须首先接收它；随后按照事务的内容修改库存清单；最后如果更新后的库存量少于库存量临界值时，则应该再次定货，也就是需要处理定货信息。因此，把“处理事务”这个功能分解为下述3个步骤：“接收事务”、“更新库存清单”和“处理订货”，这在逻辑上是合理的。

我们为什么不进一步分解“产生报表”这个功能呢？因为订货报表中需要的数据在存储的订货信息中全都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。同样道理，对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。总之，当进一步分解将涉及如何具体地实现一个功能时，就不应该再分解了。

在对数据流图分层细化时必须保持信息连续性，即当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。

还应该注意在数据流图中对处理进行编号的方法。处理1.1，1.2和1.3是更高层次的数据流图中处理1的组成元素。如果处理2被进一步分解，它的组成元素的编号将是2.1， 2.2……如果把处理1.1进一步分解，则将得到编号为1.1.1，1.1.2……的处理，以此类推。

3.5 补充: 数据流图命名规范

数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。

数据源点/终点并不需要在开发目标系统的过程中设计和实现，它并不属于数据流图的核心内容，只不过是目标系统的外围环境部分（可能是人员、计算机外部设备或传感器装置）。通常，为数据源点 / 终点命名时采用它们在问题域中习惯使用的名字（如“采购员”、“仓库管理员”等）。

数据流（或数据存储）命名：

名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。

不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。

如果在为某个数据流（或数据存储）起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。

处理命名：

通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。

名字应该反映整个处理的功能，而不是它的一部分功能。

名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作为名字。

通常名字中仅包括一个动词。如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。

如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。

4 例题

例题一

请根据以下描述画出某库存管理系统的数据流图和ER图。该系统的描述如下:

(1)根据计划部门转来的收货通知单和已存在的物资编码文件，建立物资采购单流水账。

(2) 根据技术部门的物资验收报告和物资采购单流水账，更新物资台账文件。

(3) 对物资台账分类汇总，将结果存储于物资总账文件中。

(4) 物资出库：物资使用部门填写物资出库单，包括物资编号、物资名称、物资数量、物资使用部分、负责人、经手人。系统根据物资总账文件的库存情况判断是否能够出库，如果能够出库，则记录出库单，并更新物资总账文件。

例题二

复印机的工作过程大致如下：未接到复印命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲置状态，等待下一个复印命令；如果执行复印命令时发现没纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲置状态，准备接收复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告等待维修人员来排除故障，故障排除后回到闲置状态。请用状态转换图描绘复印机的行为。

📎 参考文章

软件工程 -- 数据流图的画法

💡

有关问题，欢迎您在底部评论区留言，一起交流~