第 2 章 软件需求分析

教学提示：本章通过实例分析引入软件需求分析的任务与步骤，对软件需求分析的步

骤——需求获取、分析建模、文档编写及需求验证做了较详细的介绍；并着重介绍了用结

构分析方法建立分析模型的描述工具及建立过程；同时给出文档编写规范与实例供学习

参考。

教学要求：本章概念较多，分析比较抽象，教学中要注意结合实例进行说明，使学生

对软件需求分析有较深刻的领会。本章重点是掌握软件需求分析的任务与步骤；理解需求

获取的常用方法，尤其是快速原型法的过程；掌握结构化建立分析模型的方法及常用工具

的使用；理解软件需求规格说明书的结构与内容；学会阅读与书写软件需求规格说明书。

需求是用户对系统提出的要求，这种要求可能是原始的、笼统的，也可能是抽象的太

细节化的。但一个软件系统的开发必须以一组需求作为出发点，软件需求分析工作是在软

件计划阶段完成之后开始的，其主要目的是：在综合分析用户对系统提出的一组需求(基于

功能、性能、数据等方面)的基础上，构造一个从抽象到具体的逻辑模型表达软件将要实现

的需求。并以“软件需求规格说明书”的形式作为本阶段工作的结果，为下一阶段的软件

设计提供设计基础。软件需求分析是软件工程的第一步，也是软件开发中十分重要的工作，

软件需求分析工作质量的好坏，将对后面几个阶段的开发工作产生决定性的影响。

本章将从实例出发，介绍软件需求分析的任务、获取方法、获取过程等方面软件需求

分析的相关知识。

2.1 软件需求分析概述

软件需求分析是软件生存期中重要的一步，是软件定义阶段的最后一个阶段，是关系

到软件开发成败的关键步骤。软件需求分析过程就是对可行性研究确定的系统功能进一步

具体化，并通过系统分析员与用户之间的广泛交流，最终形成一个完整、清晰、一致的软

件需求规格说明书的过程。通过需求分析能把软件功能和性能的总体概念描述为具体的软

件，从而奠定软件开发的基础。该过程将软件计划阶段所确定的软件范围逐步细化到可详

细定义的程度并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。总的

来说，软件需求分析过程实际上是一个调查研究、分析综合的过程，是一个抽象思维、逻

辑思维的过程，是对软件计划阶段建立的软件工作范围的求精和细化。它准确回答了“系

统该做什么”的问题。

2.1.1 实例分析

软件开发项目的过程可以用以下开发过程模型来说明，如图 2.1 所示。先看图中几个

概念的含义。

第 2章 软件需求分析

·23·

·23·

� 当前系统：将用户正在使用的系统，可能是需要改进的已经使用计算机进行数据处

理的系统，或者是一个人工处理数据的过程称为当前系统。

� 目标系统：将经过改进或者由纯人工方式的处理数据过程，在应用计算机后要实现

的系统，即要完成的软件系统称为目标系统。

图 2.1 开发过程模型

� 当前系统的物理模型：通过分析现实世界，理解当前系统的运行过程，用一个具体

化的模型模拟、了解当前系统的组织结构、资源利用情况和日常数据处理过程，这

一模型称为当前系统的物理模型。合理的物理模型应该客观反映现实世界的实际情

况。这是软件开发计划中较重要的一步，也是软件需要分析中的第一步。

� 当前系统的逻辑模型：在理解当前系统的具体运行过程后，从个体的细节中抽象出

本质的过程模型，即当前系统的逻辑模型。

� 目标系统的逻辑模型：分析当前系统与目标系统逻辑上的差别，明确目标系统要“做

什么”的实质工作，从当前系统的逻辑模型导出目标系统的逻辑模型。

� 目标系统的物理模型：要确定待开发系统的系统元素，并将功能和数据结构分配到

系统元素中。这是软件开发项目的目的。它的具体物理模型则是由它的逻辑模型经

实例化后，具体到某个业务领域得到的。

现在，就以学生收费系统的开发过程为例来描述开发模型过程中的各个部分，并说明

软件需求分析的任务与步骤的相关概念。

【例 2.1】 高校学生在每学年的开始都需要交纳学费、书费、住宿费等费用，这些工作往

往需要各个部门的人员参与。学生交费过程：先由系办公室秘书审查学生身份并开具交费

清单(包括学费、书费和住宿费等)；学生持交费清单找财务科会计开具交费发票；找财务

科出纳付款；凭交费发票去教材科领取教材，到宿舍办理入住手续，到系办公室办理开课

手续。

软件开发的任务：根据用户现在使用的系统抽象出应用计算机后的系统。即，将上述

手工操作过程改为计算机处理过程。

软件需求分析的任务：与用户交流，认清系统需要解决的问题，得出目标系统的逻辑

模型，并编写软件需求规格说明书等相关文档。

解：为了完成软件需求分析的目的，将该软件的需求分析过程分成以下几个步骤。

模型化 抽象化

具体化 实例化

当前系统

目标系统

物理模型

物理模型

逻辑模型

理

解

需

求

表

达

需

求

做什么 怎么做

逻辑模型

软件工程基础教程

·24·

·24·

(1) 通过对现实环境的调查研究，获取当前系统的物理模型，如图 2.2 所示。

图 2.2 当前系统的物理模型

(2) 分析需求，建立系统的分析模型(由当前系统的逻辑模型到目标系统的逻辑模型)。

① 排除当前系统的物理模型中的非本质因素，提炼出当前系统的逻辑模型。

在图 2.2 中具体的办公人员是可能变动的，但他们需要处理的工作是不变的。这些工

作才是本质的内容。由此可以抽象出学生交费过程中当前系统的逻辑模型，如图 2.3 所示。

图 2.3 当前系统的逻辑模型

② 分析当前系统与目标系统的差别，建立目标系统的逻辑模型。

目标系统与当前系统是有差别的，它的功能比当前系统更强，而不是完全模拟现行的

系统。在上述分析中，可以把第二步与第三步的工作合并，当学生提交申请后，根据学生

信息得出学生应交纳的学费及相关书费等费用情况，直接开出发票。抽象后的逻辑模型如

图 2.4 所示。

学费 单据

住宿 单据

学

生 学

生 秘书 1

秘书 2

出纳

交费 申请

交费 清单

交费 发票

领书 单据 教材

书库 管理员

宿舍 管理员

会计

学费 单据

住宿 单据

学

生 学

生

审查 有效性

注册

开单据

交费 申请

交费 清单

交费 发票

领书 单据 教材

领书

住宿

开发票

第 2章 软件需求分析

·25·

·25·

图 2.4 目标系统的逻辑模型

(3) 整理综合需求，编写软件需求规格说明书。根据已经确定的目标系统的逻辑模型，

编写相关文档，描述对系统的综合需求及数据要求。具体编写过程在此不做赘述，相关内

容参见 2.7 节。

(4) 验证需求，完善对目标系统的描述。为了对目标系统有个完整的描述，还需要对

已经得到的结果做补充：通过目标系统的人机界面，和用户一起确认目标系统功能；分析

哪些功能由计算机完成，哪些功能由人工完成。在本系统中，收款、发书、住宿认证和注

册等仍由人工完成。

验证需求说明、补充未考虑的细节，

如确定系统的响应时间、增加出错处理等。

在本系统中，若某学生因故休学，在重新

注册时，就要考虑学生的实际情况，交费

情况与其他同级学生有不同。这样，就需

要在其办理休学手续时，用“休学通知”

把相应的情况通知系统，如图 2.5 所示。

2.1.2 软件需求分析的任务

软件需求分析阶段研究的对象是软件项目的用户要求，如何准确表达用户的要求，怎

样与用户共同明确将要开发的是一个什么样的系统，是需求分析要解决的主要问题。也就

是说需求阶段的任务并不是确定系统怎样完成工作，而仅仅是确定系统必须完成哪些工作，

即对目标系统提出完整、准确、清晰、具体的要求。需求分析阶段所要完成的任务是以软

件计划阶段确定的软件工作范围为指南，通过分析综合建立分析模型，编制出软件需求规

格说明书。

教材

领书 单据

交费 发票

学费 单据

住宿 单据

学

生 学

生 审查并

开发票

注册

开单据

交费 申请

领书

住宿

单据 交费 发票 学

生 学

生 审查并

开发票 开单据

交费 申请

图 2.5 改进后的目标系统的逻辑模型

休学通知

软件工程基础教程

·26·

·26·

1. 认清问题、分析资料、建立分析模型

通过调查研究，系统分析员根据软件工作范围，充分理解用户提出的每项功能与要求。

同时从软件系统特征、软件开发的全过程，以及软件计划中给出的资源和时间约束来确定

软件开发的总策略。只有用户才知道自己需要什么，但是他们并不知道怎样利用软件来实

现自己的需要，用户必须把他们对软件的需求尽量准确、具体地描述出来；系统分析员知

道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，

必须通过与用户的沟通获取用户对软件的需求。

一般来说，当前系统是杂乱无章的，并且用户群体中的各个用户会从不同角度提出对

原始问题的理解及对用计算机要实现管理的软件系统的需求，但并非所有的用户提出的要

求都是合理的，所以必须全面理解用户的各项要求，不可能接受所有的要求。

在需求分析阶段，系统分析员要对收集到的大量资料和数据进行分析综合，透过现象

看本质，看到事物的内存联系及矛盾所在；同时，对于那些非本质的东西，找出解决矛盾

的办法；最后，通过“抽象”建立起描述软件需求的一组模型，即分析模型。分析模型应

该包含系统的界面要求、功能要求、性能要求(如响应时间、吞吐量、处理时间、对内外存

的限制等的要求)、安全性、保密性、可靠性、运行要求(如对硬件、支撑软件、数据通信

接口等的要求)、异常处理等对系统的综合需求，以及对于系统信息处理中数据元素的组成、

数据的逻辑关系、数据字典和数据模型等系统的数据要求。这些是形成软件需求规格说明

书、进行软件设计与实现的基础。

2. 编写软件需求规格说明书

分析模型建立后，通过软件需求规格说明书进行描述。该说明书是软件生命周期中一

份极为重要的文档。它是连接计划阶段和开发阶段的桥梁，是软件设计的依据。许多事实

表明，在软件需求规格说明书中的任何一个微小错误都有可能导致系统的错误，在纠正时

将会付出巨大的代价。

软件需求规格说明书是沟通用户与系统分析员的媒介，双方要用它来表达对于需要计

算机解决的问题的理解。书写时应当易于理解和无二义性，尤其是在描述的过程中最好不

使用用户不易理解的专业术语。

为了便于用户，尤其是不熟悉计算机的用户容易理解，软件需求规格说明书应该直观、

易读和易于修改，所以应尽量以图文结合的方式，采用自然语言，标准的图形、表格和简

单的符号来表示。

2.1.3 软件需求分析的步骤

在软件需求分析中，必须采用合理的步骤，才能准确地获取软件的需求，产生符合要

求的软件需求规格说明书。通过对上述实例的分析，可归纳为 4 个步骤：需求获取、分析

建模、文档编写、需求验证。

1. 需求获取

需求获取通常从分析当前系统包含的数据开始。首先分析现实世界，进行现场调查研

究，通过与用户的交流，理解当前系统是如何运行的，了解当前系统的机构、输入输出、

资源利用情况和日常数据处理过程，并用一个具体模型反映系统分析员对当前系统的理解，

这就是当前系统的物理模型的建立过程。这一模型应客观地反映现实世界的实际情况。

第 2章 软件需求分析

·27·

·27·

2. 分析建模

分析建模的过程，就是从当前系统的物理模型中，抽象出当前系统的逻辑模型，再利

用当前系统的逻辑模型，除去那些非本质的东西，抽象出目标系统的逻辑模型的过程，即

对目标系统的综合要求及数据要求的分析综合的过程，是需求分析过程中关键的一步。

首先，在理解当前系统“怎么做”的基础上，抽取其“做什么”的本质，从而从物理

模型中抽象出当前系统的逻辑模型。在物理模型中有许多物理的因素，随着分析工作的深

入，需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素，

得出反映系统本质的逻辑模型。

其次，分析目标系统与当前系统在逻辑上的差别，从当前系统的逻辑模型导出目标系

统的逻辑模型。从分析当前系统与目标系统变化范围的不同，决定目标系统与当前系统在

逻辑上的差别；将变化的部分看作是新的处理步骤，并对数据流进行调整；由外向里对变

化的部分进行分析，推断其结构，获取目标系统的逻辑模型。

最后，补充目标系统的逻辑模型。为了使已经得出的模型能够对目标系统作完整的描

述，还需要从目标系统的用户界面、尚未详细考虑的细节以及其他诸如系统能够满足的性

能和限制等方面加以补充。

3. 文档编写

已经确定的目标系统的逻辑模型应当得到清晰准确的描述。我们把描述目标系统的逻

辑模型的文档称为软件需求规格说明书。软件需求规格说明书是软件需求分析阶段最主要

的文档。同时，为了准确表达用户对软件的输入/输出要求，还需要制定数据要求说明书及

编写初步的手册，以及反映目标系统的用户界面和用户使用的具体要求。此外，依据在需

求分析阶段对目标系统的进一步分析，可以更准确地估计被开发项目的成本与进度，从而

修改、完善并确定软件开发实施计划。

4. 需求验证

由系统分析员提供的软件需求说明书的初稿看起来是正确的，但在实现的过程中却会

出现各种各样的问题，如需求不一致的问题、二义性问题等。这些都必须通过需求分析的

验证、复审来发现，确保软件需求规格说明书可作为软件设计和最终系统验收的依据。这个

环节的参与者有用户、管理部门、软件设计、编码和测试人员等。验证的结果可能会引起修

改，必要时要修改软件计划来反映环境的变化。需求验证是软件需求分析任务完成的标志。

2.2 软件需求获取的方法

软件需求分析总是从两方或多方之间的交流与通信开始,用户与开发者之间需要互相

通信，但是从开始通信到真正相互理解的道路通常是充满坎坷的。良好的通信技术有助于

加快理解的过程。

2.2.1 常规的软件需求获取的方法

为了详细地了解并正确地理解用户的需求，必须使用适当的方法与用户沟通。访谈是

与用户沟通的历史悠久的技术，至今仍被许多系统分析员采用。为了促使用户与系统分析

员共同分析需求，人们还采用了情景分析技术、简易的应用规格说明技术等来获取需求信

软件工程基础教程

·28·

·28·

息。最后，通过需求分析与确认的方式来保证需求获取信息的完整性与有效性。常规的需

求获取的方法有以下几种。

1. 访谈

访谈是最早使用的获取用户需求的技术，也是世界上依然广泛使用的需求分析技术。

访谈有两种基本形式：正式访谈和非正式访谈。正式访谈时，系统分析员将提出事先准备

好的具体问题，如询问学生收费的范围、学生的类别与学费的标准、学生教材确定的途径

等。在非正式访谈中，系统分析员将提出一些用户可以自由回答的开放性问题，以鼓励被

访问人员说出自己的想法。例如，询问用户对目前正在使用的系统有哪些不满意的地方，

对于未来系统的期望等。

当涉及的用户较多时，发放调查表是一个行之有效的方法。经过仔细考虑写出的书面

回答可能会比被访问者的口头回答更准确，系统分析员应仔细阅读收回的调查表，再有针

对性地访问用户，以便向他们询问在分析调查表时发现的问题。

2. 情景分析技术

情景分析技术也是获取用户需求的实用技术之一。情景分析就是对用户将来使用目标

系统解决某个问题的方法和结果进行分析。假设在使用学生收费系统软件中，给出一个具

体学生的姓名、专业、学生类别、年级时，就会有一个情景描述。系统分析员根据自己对

目标系统应具备的功能的理解，给出学生交费的情况以及学生教材的清单。学生有可能指

出，他是休学一年的学生，教材的情况和他同年级的学生是不一样的。系统分析员采用这

样的情景分析技术，往往能得到用户的特殊要求。

3. 简易的应用规格说明技术

在访谈的过程中，用户处于被动地位，不容易和系统分析员同心协力地识别和精化需

求；有时，系统分析员对用户的业务过程和术语不太熟悉，用户也不太熟悉计算机的处理

过程。这样，用户提供的需求信息，在系统分析员看来往往是零散和片面的，需要一个领

域专家来沟通。因而，建立一个由用户、系统分析员和领域专家组成的联合分析小组，对

于开发人员与用户之间的交流和需求信息的获取将非常有用。联合分析小组极大地方便了

系统分析员与用户之间的沟通，这种面向团队的需求收集法，称为简易的应用规格说明技

术。目前，这种技术已经成为信息系统领域使用的主流技术。

使用简易的应用规格说明技术分析需求的典型过程如下。

首先进行初步的访谈，通过用户对基本问题的回答，初步确定待解决问题的范围和解

决方案。要求开发者与用户分别写出“产品需求”。选定会议的时间与地点，并选举一位

主持会议的协调人。要求与会者在开会的前几天认真审查产品需求，创建能够准确地表达

出自己对目标系统的认识的列表。

会议讨论的第一个问题为是否需要这个新产品。当大家都同意确实需要新产品时，每

位与会者将自己在会前准备好的对目标系统的认识提出来供大家讨论。此时，严格禁止批

评与争论。

在所有与会人员针对某个议题进行讨论后，共同创建一张组合列表。在针对每个议题

的组合列表都建立起来后，由协调人主持讨论。目的是给每个议题都创建出一张意见一致

第 2章 软件需求分析

·29·

·29·

的列表。

根据已经得出的意见一致的列表，将与会者分成更小的组，每个小组的工作目标是为

每个项目制定小型规格说明。然后每个小组向全体与会者展示他们制定的小型规格说明，

通过讨论进一步精化各组小型规格说明。

在完成了小型规格说明之后，每个与会者提供同一产品的一整套确认标准，并将自己

制定的确认标准提交会议讨论，以创建出一致的确认标准。最后，由一名或多名与会者根

据会议成果起草完整的软件需求规格说明书。

简易的应用规格说明技术虽然不是解决需求分析阶段的万能灵药，但它具有可以使开发

者与用户不分彼此、齐心协力、密切合作等突出的优点，成为信息系统领域中获取需求信息

的主流技术。

由于需求分析是一项十分艰巨的工作，用户与系统分析员之间需要沟通的内容非常多，

在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。因此，对目标系统

的要求不可能经过与用户的一两次接触就能阐述清楚，更不能限制用户在回答过程中自由

发挥。在每次得出新的进展之后，要及时整理、分析用户提供的信息，去掉错误的、无关

的部分，整理有用的内容，以便在下一次与用户交流中确认；同时选择在下一次与用户交

流时需要进一步讨论的细节的问题，如此循环，一般要经过 2～5次才能完成需求信息的获取。

2.2.2 快速原型法在软件需求分析中的应用

快速原型法最初是一种软件过程模型。在实际的软件开发中，快速原型法常常被用作

一种有效的需求定义方法。快速原型是仓促建立的软件，该软件仅展示了目标系统的主要功

能，如学生收费软件应该包含输入屏幕，使用户通过学生提交的信息输出该学生应交纳的费

用信息，并且能够打印发票。这些方面可以结合到快速原型中。差错检查能力、文件更新能

力及复杂的特殊情况信息处理等可以不包括在内。问题的关键是如何通过快速原型反映用

户看得到的功能，如屏幕显示、报告输出等，而省略目标系统的隐含功能(如修改文件)。

在软件需求分析阶段，开发人员根据对软件的理解，利用快速开发工具先快速建立一

个快速原型。然后让用户对快速原型进行评估，开发人员观察并做记录。用户凭借自己丰

富的实践经验，告知开发人员快速原型是否满足他们的要求，指出需要改进的地方。开发

人员根据要求修改快速原型，用户进一步实践并提出新的要求与修改意见。这样反复操作，

直到双方能够确认用户的需求已经准确地包含在快速原型中。这样，快速原型才可作为拟

订软件需求规格说明书的基础。

快速原型开发的一个重要特点是“快”，全部的要点是尽可能快地建立原型，为用户

提供对目标系统尽可能多、尽可能好的理解。建立快速原型的目的就是使用户与开发人员

能够在对目标系统的需求上达成一致意见。所以，快速原型的屏幕布局不必要求完美，只

要它们没有损害快速原型的功能，不会使用户对产品的行为产生误解，快速原型的其他不

完美之处都是可以忽略的。

快速原型开发的另一个重要特点是必须可以修改。如果快速原型不符合用户的要求，

该原型必须能够迅速修改来满足用户的需求。第四代开发技术(4GT)是常用的创建快速原型

技术，它利用第四代语言或开发工具，包括数据库查询和报表语言、程序和应用软件生成

器以及其他高级非过程语言等。Borland公司的 Delphi，Sybase公司的 PowerBuilder，以及

软件工程基础教程

·30·

·30·

微软公司的 Visual Basic、Visual C++等都是很好的第四代开发工具。

2.3 分 析 建 模

为了更好地理解需求获取过程中用户描述的问题，可以采用创建模型的方式来实现。

这就是分析建模的过程。所谓模型，就是为了理解事物所做出的一种抽象，是对事物无歧

义的书面描述。模型由一组图形符号和组成这些符号的规则所组成。

2.3.1 分析模型

软件的分析模型通常是由一组模型组成，其中包括数据模型、功能模型和行为模型。

目前有两种主要的建立分析模型的方法：一种是基于数据流的结构化分析模型，它将系统

分成几个功能模块，各块之间用数据流进行通信；另一种是基于对象的面向对象分析模型，

它则将系统分解为一组互相关联的对象，每一对象由对象的属性和在对象上的操作构成。

1. 结构化分析模型

结构化分析(Structured Analysis, SA)

模型的组成结构如图 2.6 所示，可以看

出模型的核心是 DD(Data Dictionary，数

据字典)，这是系统所涉及的各种数据对

象的总和。从数据字典出发主要通过以

下 3 种图来构建该模型的 3 种模型。

� E-R 图(Entity Relation Diagram，

实体联系图)：用于描述数据对象

间的关系、构建软件的数据模型，

在实体—关系中出现的每个数据

对象的属性均可用数据对象进行

说明描述。

� DFD(Data Flow Diagram，数据流

图)：其主要作用是指明系统中数

据是如何流动和变换的，以及描述数据流如何进行变换。在 DFD 图中出现的每个功能

都会写在 PSPEC(Process Specification，加工说明)中，它们一起构成系统的功能模型。

� STD 图(Status Transfer Diagram，状态-变迁图)：用于指明系统在外部事件的作用下

将如何动作，表明系统的各种状态及各种状态间的变迁。所有软件控制方面的附加

信息包含在 CSPEC(Control Specification，控制说明)中，它们构成系统的行为模型。

早期的结构化分析模型只包括 DD、DFD 和 PSPEC，主要描述软件的数据模型与功能

模型。一方面随着软件开发技术的不断发展，软件系统要去满足用户更多、更复杂的数据

信息要求。在数据建模时，人们就将用于数据库设计方面的 E-R 图用于结构化分析，用来

描述包含较复杂数据对象和信息模型。另一方面，随着计算机实时系统应用的不断拓展，

在分析建模过程中，由实时发生的事件来触发控制的数据加工，无法用传统的 DFD 来表示。

控制描述

DD

图 2.6 结构化分析模型的组成结构

数据描述 加工说明

功能模型 数据模型

行为模型

第 2章 软件需求分析

·31·

·31·

由此在功能模型之外扩充了行为模型，用 CFD(Control Flow Diagram，控制流图)、CSPEC

和 STD 图等工具来描述。

2. 面向对象分析模型

面向对象分析是采用面向对象的思想进行软件需求分析建模的过程。通过对对象定义

属性，赋予操作，把该对象在系统中的活动特点描述出来，然后通过消息将对象内以及对

象与对象之间的关系反映出来，它的组成结构如图 2.7 所示。面向对象分析得到的模型包

含对象的 3 个要素即数据交换(功能模型)、静态结构(对象模型)和交互次序(动态模型)。面

向对象分析模型中具体的内容，将在第 7 章中做详细介绍，下面只简单介绍面向对象分析

模型中的 3 个模型。

� 对象模型：定位在哪个对象上，通过反映系统中的对象与对象之间的关系及表示对

象、类、属性和操作来表达目标系统的静态结构，与结构化分析模型中的数据模型

有相近的功能。利用类图及对象图建模。

� 功能模型：确定什么事件发生，反映的是系统模块的输入和输出。该模型从用户的

视角来表示系统，用例和场景用于功能模型的建模选择。

� 动态模型：决定在什么时候，

什么条件下发生。关心的是

时间变化、对象与对象之间

关系的变化。对象与对象之

间的相互作用，导致它们的

状态不断发生变化。一个事

件是指一个单独对象对另一

个的激励。该模型主要描述

目标系统的动态或行为，相

当于结构化分析模型中的行

为模型。以状态图和时序图

为工具建模。

2.3.2 分析建模的描述工具

本节主要介绍结构化分析模型的组成部分及常用描述工具，包括用于建立功能模型的

DFD 和 DD、用于建立数据模型的 E-R 图。由于在描述复杂事情时，图形比文字叙述要优

越得多，所以在此还将简单介绍在软件需求分析阶段常用的另外一种图形工具——层次方

框图。

1. DFD

任何软件系统从根本上都是对数据的加工或变换的工具。当数据在软件系统中移动时，

它将被一系列“变换”所修改。DFD 就是描述信息流和数据从移动到输出的过程中所经受

的变换的图形化技术。在 DFD 中没有任何具体的物理部件，它只是描绘数据在系统中流

动和被处理的过程。它可表现的范围可大到整个系统，小到一个模块。在软件需求分析中

常用一组 DFD 由粗到精地表示同一软件在不同抽象级别上的功能，这就是分层 DFD。如

动态模型

使用 实例

图 2.7 面向对象分析模型的组成结构

对象模型

功能模型

属性、操作、协作者

软件工程基础教程

·32·

·32·

图 2.8 所示的是 DFD 的一般形式，其基本组成如图 2.9 所示，由数据流、加工、文件、源

点/汇点组成。

(1) 数据流(data flow)：用箭头代表数据流的方向，由一组固定成分的数据组成，表示

数据的流向。它可以从一个加工流向另一个加工，从加工流向文件，从源点流向加工，从

加工流向汇点。除了流向文件或从文件流出的数据流不必命名外，每个数据流都必须有明

确的名字，反映该数据流含义。

(2) 加工(process)：在 DFD 中用圆框代表加工。它描述输入数据流到输出数据流之间

的变换。每个加工有一个名字和编号。编号反映该加工在分层 DFD 中的层次和位置，同时

还能够看出它与其他加工的联系。

如图 2.10 所示，在数据流图中，如果两个以上的数据流指向一个加工，或者从一个加

工引出两个以上的数据流，那么这些数据流之间往往存在一定的关系。为表示这些关系，

用“*”表示相邻的一对数据流同时出现；用“⊕”表示相邻的一对数据流只取其一。

图 2.10 多个数据流加工符号

图 2.8 DFD 基本形式 图2.9 DFD的基本组成

数据流

加工

文件

源/汇点

加工 1

加工 1

加工 1

数据流 1

数据流 2

数据流 3

数据流 6

数据流 5

数据流 4 源/汇点

A B

C

B

C

B

C

A

B

C

A

B

C

A

A

*

+

有 A 则有 B 或 C，或者两者都有

有 A 则有 B 与 C，两者同时都有

有 A 则有 B 或 C，但不会两者同时有

当 A 或 B 之一存在，

就有 C

当 A 或 B 都存在时

才有 C

第 2章 软件需求分析

·33·

·33·

(3) 文件(File)：用来表示暂时存储的数据，每个文件都必须有名字。流向文件的数据

流表示写文件，流出文件的数据流表示读文件，双向箭头表示对文件可读可写。

(4) 源点/汇点(Source/Sink)：通常指存在软件系统之外的人员和组织。它指出系统所需

数据的发源地和系统所产生的数据的归宿地。在一个软件系统中，有些源点和汇点可以是

同一个人或组织，源点和汇点可用同一个图形符号。

【例 2.2】 将图 2.5 改进后的目标系统的逻辑模型改成 DFD。

解：图 2.5 中有 2 个加工(审查并开发

票、开单据)，4 个数据流(交费申请、发票、

单据及休学通知)，数据的源点与汇点都是

“学生”。图中没有数据文件，在审查交

费申请开发票之前，至少要查以下信息：

学生的情况，该学生是什么类别(专科、本

科)，什么专业及住宿情况，才能决定需要

交纳的费用；资源的情况，主要是教材的

存量、宿舍的安排等。将这两个文件加入

到图中，并给加工加上编号，就得到学生

收费系统的 DFD，如图 2.11 所示。

2. DD

DD 是关于数据的集合，也是对 DFD 中包含的所有元素的定义的集合。它的作用是对

软件中的每个数据规定一个定义条目，在软件分析和设计过程中提供相关数据的描述信息，

以保持数据在系统中的一致性。DFD 和 DD共同构成系统的逻辑模型，没有 DD，DFD 就

不严格，没有 DFD，DD 也难于发挥作用。只有 DFD 和对 DFD 中每个元素的定义放在一

起，才能构成系统的规格说明。以下将介绍主要的 DD条目。

1) 数据流

数据流条目包括数据流名称、编号(用于字典管理)、简述(简述该数据流的含义)、组成

(描述该数据流由哪些数据项组成)、来源(描述该数据流来自哪个加工或源点)、去向(描述

该数据流流向哪个加工或汇点)、数据量(描述该数据流在软件系统中的数量)、峰值(描述在

某一时间范围内要处理数据流的最大数量，这是考虑处理速度的依据之一)和备注等。其中

数据流名称和组成是必需的，数据量和峰值也是需要的。

【例 2.3】 以图 2.11 中的“发票”为例，编写一个字典条目。

解：“发票”条目内容与格式如下：

数据流名：发票 组成：学号+姓名+学费+住宿费+{书号+单价+数量+总价}+总计费用

备注：

2) 文件

文件条目可以有如下内容：文件名、编号、简述(简述该文件的含义)、组成(描述该文

件由哪些数据流组成)、文件组织(描述该文件的类型、按什么关键字排序等)、读文件(描述

哪些加工需要读该文件)、写文件(哪些加工需要写入该文件)、数据量(描述该文件的记录个

图 2.11 高校学生收费系统数据流图

学生信息表

单据

发票

学

生 学

生

审查开

发票 1 开单据

2

休学通知

资源信息表

交费 申请

软件工程基础教程

·34·

·34·

数)和备注等。

【例 2.4】 为图 2.11 中的文件“学生信息表”编写字典条目。

解：“学生信息表”字典条目如下：

文件名：学生信息表

组成：系编号+专业编号+类别编号+班编号+年级+宿舍编号+用书记录编号

组织：按系、专业、类别、班级从小到大排列

备注：

3) 数据项

数据项条目包括数据项名、编号、简述(简述该数据项的含义)、单位(该数据项的计量

单位)、类型(描述该数据项的数据类型)、值域(描述该数据项的取值范围)、编辑方式(描述

该数据项在输出时的编辑要求)、与其他数据项的关系(有利于数据的合法性检查)和备注等。

无论是独立的或者包含在数据流或文件中的数据项，都应在字典中设置相应的条目。

【例 2.5】 定义上例中数据项“年级”。

解：“年级”数据项定义如下：

数据项名：年级

取值及含义：

F-freshman 一年级

M-sophomore 二年级

J-junior 三年级

S-senior 四年级

备注：F、M、J、S 可分别用 1、2、3、4 代替

4) 加工

在 DFD 中，有些加工最终分解成许多简单的加工，下面把不再需要分解的加工称为基

本加工。DD 中只列出基本加工的条目，因为其他的加工都可以被基本加工说明。一个基

本加工的条目主要包括以下内容：加工名、编号、简述(对该加工的简要说明)、输入/输出

数据流(描述该加工有哪些输入/输出/数据流)、输入/输出文件(描述该加工需要读、写哪些

文件)、加工逻辑(描述该加工在什么条件下做什么事)、异常处理(描述该加工可能遇到的异

常及其处理反应)、加工激发条件、执行频率和备注等。其中加工逻辑是最基本的部分，它

描述了输入数据流、输入文件与输出数据流、输出文件的逻辑关系。有关加工的描述在下

面的加工说明中将做进一步介绍。

在字典中允许使用以下符号描述数据元素组成的关系：“=”表示等价于；“+”表示

和，即两个分量连接；“[ ]”表示或，即从方括号中列出的若干个分量中取其一；“｛｝”

表示重复其中列出的内容，如 1｛｝2 中数据表示重复次数的上下限，括号中的内容最少重

复一次最多重复两次；“()”表示可选，即括号中的分量是可有可无的。以上符号和注释

符“*”一起将数据流或数据文件写成公式的形式。如在上述几个例子中的表示可简化为：

发票=学号+姓名+{发票行 }+总计费用

发票行=学费+住宿费+[书号+单价+数量+总价]

学生信息表=系编号+专业编号+类别编号+班编号+年级+宿舍编号+用书记录编号

第 2章 软件需求分析

·35·

·35·

系编号=2{数字}2 * 二位数字

类别编号=1{数字}1 * 一位数字

专业及班编号={数字} * 三位数字

年级=[F/M/J/S] * 4 个字母中任选一个

注意在用公式形式定义数据时，等号可读作“定义为”，等号左边的是要定义的数据，

等号右边是对数据的描述。公式形式比字典条目形式简洁，但内容不够丰富，一般用于 DFD

中的数据注释。

3. PSPEC(Process SPECification，加工说明)

PSPEC 是对 DFD 中每个加工所作的说明。由输入数据、加工逻辑和输出数据等组成。加

工逻辑阐明把输入数据转换为输出数据的策略，是 PSPEC 的主体。PSPEC 的描述工具通常有

3 种：结构化语言(Structured language)、判定表(Decision Table)和判定树(Decision Tree)。

1) 结构化语言

用自然语言加上结构化的形式，就构成结构化语言。它是一种介于自然语言与程序设

计语言之间的语言，既具有结构化程序的清晰易读的优点，又具有自然语言的灵活性，不

受程序设计语言的严格语法约束。结构化语言的语法分成内、外两层，外层语法描述操作

的控制结构，如顺序、选择和循环等，此控制结构将加工中的各个操作连接起来，内层的

语法一般没有什么限制。

使用结构化语言时，“若”后面表示的均为条件，“则”后面表示的均为要做的处理。

若使用结构化语言时，可采用 if、then、otherwise 等关键字。

【例 2.6】 假定学校录取新生时主要考虑两个条件(考分与体格检查结果)。首先检验考分，

其次再按不同的体检结果，分别做不同的处理。

解：本系统的加工说明可如下描述：

若成绩在录取分数之上

若体格检查合格

则发录取通知书

若体格检查不合格

则将考生档案转送下一志愿学校

若成绩在录取分数以下

若体格检查合格

则将考生档案转送下一志愿学校

若体格检查不合格

则发不录取通知书

【例 2.7】 使用结构化语言来描述图 2.11 的学生收费中“加工 1”(审查并发票)中审查教

材并发票的加工逻辑。

解：此例中，用如图 2.12 所示审查教材的发票的加工逻辑说明。

软件工程基础教程

·36·

·36·

2) 判定表

判定表采用表格化的形式，适用于含有复杂判断的加工说明。条件越复杂，规则越多，

越适宜用判定表的方式来描述。如果在加工逻辑中同时存在顺序、选择和循环结构，还可

在判定表中加上结构化语言，或者在结构化语言写的说明中插进判定表，以充分发挥各自

的特点。判定表一般由 4 个部分构成：条件所指对象、所有的操作、各种条件下的组合及

在对应的条件组合下操作是否执行。

【例 2.8】 用判定表描述学校录取新生的加工逻辑。

解：见表 2-1。

表 2-1 学校新生录取判定表

成绩≥录取分数 成绩＜录取分数 判定条件

体检合格 体检不合格 体检合格 体检不合格

录取 √

转下一志愿学校 √ √

不录取 √

3) 判定树

判定树是判定表的图形表示，其适用场合与判定表相同，系统分析员根据用户的习惯

可任选一种。

【例 2.9】 判定树描述学校录取新的加工逻辑，如图 2.13 所示。

解：在表达一个具体的基本加工逻辑时，结构化语言、判定表和判定树常常交叉使用，

互相补充。对于不太复杂的判定条件，或者使用判定表有困难时，使用判定树较好。而在一个

把学生的学号和姓名写在发票上，按学生的学号、系、类别、班号

检索“学生信息表”，获取当年该学生的学费、住宿费、书费，并获取当年该生的

教材清单及教材清单上的每一书号

把书费合计写到发票上

如果 书单中无此书号 则

否则 将书号写到出错通知上

按书号检索“资源信息表”文件，获取该书的单价与库存量 如果 库存量＜购书单.数量，则

否则 将书号写到出错通知上

将书号、单价、数量、总价等项目写入发票；

更新存书量，并写回“教材存量表”文件；累计书费合计

图 2.12 加工逻辑实例

第 2章 软件需求分析

·37·

·37·

加工逻辑中，如同时存在顺序、判断和循环结构时，使用结构化语言较好。对于复杂的判定，

若组合条件较多，使用判定表较好。总之，加工逻辑说明是结构化分析方法的一个组成部分，

使用的手段应当以结构化语言为主，若存在判断问题的加工逻辑，可辅之判定表和判定树。

图 2.13 判定树实例

4. E- R 图

为了把用户的数据要求清楚、准确地描述出来，系统分析员通常要建立一个概念模型。

概念模型是面向问题的数据模型，是按照用户的观点对数据建立模型。在需求分析模型建

立过程中，使用 E-R 图来建立数据模型。它描述了从用户的角度看到的数据，反映了用户

的现实环境，而与在软件系统中的实现方法无关。数据模型包含 3 种相互关联的信息：实

体(数据对象)、属性及联系。

1) 实体、属性和联系

E-R 图中的实体对应于客观世界中的存在的人或物，又称为数据对象。数据对象可以

是外部实体(如产生或使用信息的任何事物)、行为(如开发票)、角色(如学生、教师)、单位(如

计算机系、会计科)、结构(如文件)等，是由一组属性来描述的实体。实体之间是相互联系

的，与其他实体没有联系的实体是没有意义的。

属性定义了实体的性质，实体可以由一个或多个属性定义为“标识符”，用来区分不

同的实体。根据对所要解决的问题的理解来确定属性。如要开发高校学生收费系统，描述

学生可以用学号、姓名、性别、入学日期、所在系别、学生类别和所在班级等属性。常用

二维表的形式表示相关属性，表 2-2 为学生属性表。

表 2-2 学生属性表

学号 姓名 入学日期 所在系 专业 班级 类别 备注

03001423 张明 2003 年 9 月 计算机系 网络技术 一班 对口

客观世界中的事物是相互联系的，如学生与教师的教与被教、系与学生的管理与被管

理的联系。这种联系有 3 种不同的类型：一对一(如院长与学院的联系)、一对多(如系与学

生的联系)和多对多(学生与课程间的联系)。

2) 组成符号

E-R 图中有实体、属性和联系 3 种基本成分。通常用矩形框表示实体，用连接相关实

体的菱形框表示联系，用椭圆形或圆角矩形表示属性，用直线将各种成分连接起来。如

发录取通知书

档案转送下一学校

档案转送下一学校

通过录取分数

未过录取分数

体检合格

体检不合格

体检合格

体检不合格 发不录取通知

新生录取系统

软件工程基础教程

·38·

·38·

图 2.14 所示给出 3 种联系的示意图。

5. 层次方框图

层次方框图是用结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层

是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，

最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。

随着结构的精细化，层次方框

图对数据结构描绘得越来越详细，

这种结构非常适合于需求分析阶

段的需要。系统分析员从对顶层信

息的分类开始，沿图中每条路径反

复细化，

直到确定数据结构的全部细

节为止。

【例 2.10】 用层次方框图描

述某计算机公司全部产品的数据

结构。

解：如图 2.15 所示。

2.4 软件需求说明

软件需求说明(Software Requirement Specification，SRS，又称软件规格说明书)是系统

分析员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。它的作用主要是：

作为软件人员与用户之间事实上的技术合同说明；作为软件人员下一步进行设计和编码的

基础；作为测试和验收的依据。SRS 必须用统一格式的文档进行描述，为了使需求分析描

图 2.15 层次方框图实例

软件 硬件 服务

处理

机 存储

器 外部

设备 培训

硬件

编修 软件

服务

产品

操作

系统 编译

程序 软件

工具

系统

软件 应用

软件

院长

管理

学院

一对一

图 2.14 E-R 模型中的三种联系

系

管理

学生

一对多

学生

授课

课程

多对多

第 2章 软件需求分析

·39·

·39·

述具有统一的风格，可以采用已有的且能满足项目需要的模板，如国家标准 GB/T 9385

——1988《计算机软件需求说明编制指南》中描述的 SRS 模板，也可以根据项目特点和软

件开发小组的特点对标准进行适当的改动，形成自己的模板。软件需求说明主要包括引言、

任务概述、需求规定、运行环境规定和附录等内容。

1. 引言

1) 编写目的

阐明编写需求说明书的目的，指出预期的读者范围。

2) 项目范围

包括：待开发的项目名称及项目的开发目的；与项目的应用相关的利益目的及最终目

标；项目的委托、开发单位和主管部门；该软件系统与其他系统的关系。

3) 定义

列出文档中所用到的专门术语的定义和缩写词的原意。

4) 参考资料

包括项目经核准的计划任务书、合同或上级机关的批文；项目开发计划；文档所引用

的资料、标准和规范，列出这些资料的作者、编号、发表日期、出自单位或资料来源。

2. 任务概述

1) 产品概述

描述开发意图、应用目标、作用范围、应向读者说明的有关该项目的开发背景。

2) 用户特点

列出本软件最终用户的特点，说明操作人员、维护人员的教育水平和技术水平。

3) 条件与限制

设计系统时对开发者的条件与限制。

3. 需求规定

1) 对功能的规定

包括内部及外部功能的规定。

2) 对性能的规定

包括对精度、时间要求、灵活性、适应性等的规定。

3) 对输入输出的规定

包括所有输入输出数据、引用接口及接口控制文件、操作员控制的详细描述。

4) 数据管理的规定

包括静态数据、动态数据、数据库、数据字典和数据采集的详细描述。

5) 其他专门要求

如安全保密性、可使用性、可维护性和可移植性等。

4. 运行环境规定

1) 用户界面

如屏幕格式、报表格式、菜单格式、输入/输出时间等。

软件工程基础教程

·40·

·40·

2) 设备

对系统硬件的要求描述。

3) 软件接口

支持软件描述。

4) 故障处理

对出现的故障进行应急处理。

5. 附录

实际的需求说明最好有附录，主要可以描述如格式样本、成本分析、用户调查结果、

项目解决的问题描述、特殊的要求等相关信息。如果包含附录，必须指明是不是需求要考

虑的部分。

2.5 结构化分析方法

结构化分析方法是面向数据流进行需求分析的方法，是 20 世纪 70年代末提出并发展，

适合于数据处理类型软件的需求分析方法。对于一个复杂的问题，人们很难很快考虑到问

题的所有方面和全部细节，通常要将一个大的问题分解成若干个小问题，每个小问题分解

成若干个更小的问题，这样逐层分解，直到每个底层的问题都足够简单、容易解决，这样

复杂的问题便能得到解决。这个过程不会是像分生日蛋糕那样平均分成块，而是要根据系

统的逻辑特性和系统内部各部分之间的逻辑关系进行分解。在分解的过程中充分体现“抽

象”的原则，逐层分解中的上一层是下一层的抽象，系统的逻辑模型应该按照一定的层次

关系来组织。对于任何复杂的系统，结构化分析工作都可以按照逐层分解的方式有计划、

有步骤的进行，不同的系统只是分解的层次不同。最终结构化分析模型的结果则是由分层

数据流图、一份数据字典、一组加工说明及补充材料组成。

具体来说，结构化分析方法就是按照功能分解的原则，根据软件内部数据传递、变换

的关系，自顶向下逐层分解，直到找到满足所有功能要求的可实现的逻辑模型为止。结构

分析方法主要有数据流图、数据字典、结构化语言、判定表与判定树等几个工具。主要步

骤为：由顶向下对系统进行功能分解，画出分层数据流图；由后向前定义系统的数据和加

工，确定加工策略和形成数据字典，编写需求说明书；进行需求分析复审。

以下结合高校学生收费系统中的教材购销子系统来说明结构化分析的基本步骤。

2.5.1 画出分层数据流图

从系统的基本模型，逐层地对系统进行分解。每分解一次，系统的加工数量就会增多

一些，每个加工的功能也就更具体一些。继续重复分解，直到所有的加工都足够简单，不

必再分解为止。这种不需要再分解的加工就是常说的“基本加工”。通过这种分解，对所

分析的系统将获得一组分层次的数据流图，用以代替一张含有系统全部加工的总数据流图。

具体步骤如下。

1. 画出系统的输入/输出

把整个系统看成是一个加工，根据系统从外界的哪些源点接受哪些数据流，以及系统

的哪些数据流送到外界的哪些汇点，画出系统的输入/输出图。这张图称为顶层图。

第 2章 软件需求分析

·41·

·41·

2. 画出系统的内部

将顶层图的加工分解成若干个加工，并用数据流将这些加工连接起来，使得顶层图中

的输入数据流经一连串的加工处理后变换成顶层的输出数据流，这张图称为 0 层图。从一

个加工画出一张数据流图的过程就是对这个加工的分解过程。

确定加工的方法可以是：在数据流的组成或值发生变化的地方画一个加工，这个加工

功能就是实现这一变化；也可以根据系统的功能确定加工。

确定数据的方法可以是：当用户把若干数据看作一个单位来处理(这些数据一起到达，一

起加工)时，可把这些数据看成一个数据流。通常可以把实际工作中的单据作为一个数据流。

对于一些以后某个时间要使用的数据可以组织为一个文件。

3. 对图和加工编号

对于一个软件系统，其数据流图可能有许多层，第一层又有许多张图，为了区分不同

的加工和不同的数据流图，应该对每张图和每个加工进行编号，以利于管理。

1) 父图与子图

假定分层数据流图中的某张图(图 A)中的某个加工可用另一张图(图 B)来分解，就称图

A 是图 B 的父图，图 B 为图 A 的子图。在一张图中，有些加工需要进一步分解，有些加工

则不必分解。因此，如果父图中有 n 个加工，那么它可以有 0～n 张子图(这些子图位于同

一层)，但每张子图仅有唯一的父图与之对应。

2) 编号

顶层图只能一张，图中的加工只有一个，不必编号；0 层图只有一张，图中的加工号

分别是 0.1，0.2，…或者 1，2，…；子图号就是父图中被分解的加工号；子图中的加工号

由子图号、圆点、序号组成。例如，某图中的某加工号为 2.4.2，这个加工分解出来的子图

号就是图 2.4.2，子图中的加工号分别为 2.4.2.1、2.4.2.2 等。

4. 检查复审

画出系统的分层数据流图后，可根据以下需要注意的要点检查复审，来保证分层数据

流图的合理准确性。

1) 命名

检查数据流图中的命名是否合理，为数据流、加工、文件、源点和汇点的命名应该能

够反映各成分的实际含义，避免使用空洞的名字；一个加工的输出流不应与输出流同名，

即使它们的组成成分相同。

2) 加工

每个加工必须既有输入数据流，又有输出数据流。允许一个加工有多条数据流流向另

一个加工，也允许一个加工有两个相同的输出数据流流向两个不同的加工。

3) 文件

在自顶向下的分解过程中，若一个文件首次出现时只与一个加工有关，那么这个文件

应作为这个加工的内部文件而不必画出；在整套数据流图中，每个文件必须既有读文件的

数据流，又有写文件的数据流，但在某一张子图中可能只有读没有写，或只有写没有读。

软件工程基础教程

·42·

·42·

4) 保持父图与子图的平衡

父图中某加工的输出/输入数据流与它的子图的输入/输出数据流在数量和名字上相同。

如果父图的一个输入/输出数据流对应于子图中的几个输入/输出数据流，而子图中组成这些

数据流的数据项的全体正好是父图中的一个数据流，那么它们也算是平衡的。

5) 保持数据守恒

一个加工的所有数据流的数据必须能从该加工的输入数据流中直接获得，或者是该加

工能产生的数据。

6) 分解的速度适当

分解是一个逐步细化的过程。通常在上层可分解快一些，下层应慢一些，因为越是接

近下层功能越具体，分解太快会增加用户理解的困难。同一张图中的各个加工，分解的步

子应大致均匀，保持同步扩展。每一加工每次可分为 2～4 个子加工，最多不要超出 7 个。

【例 2.11】 用结构化方法为学生收费系统画出分层的数据流图。为了比较清楚地说明画出分

层数据流图，这里只取本系统的一个子系统教材——购销系统。该子系统有如下功能：

(1) 根据学校的教学计划，向选课的学生及时供应教材；

(2) 审查学生购书单的有效性，对有效书单发售所需的教材；

(3) 对属于计划供应但暂时缺货的教材进行缺书登记；

(4) 根据缺书登记补充采购所缺的教材，通知学生补购；

(5) 将缺书登记表汇总为待购计划；

(6) 待购教材到货后，及时通知学生补购。

解：画出系统分层数据流图的第一步，即画出顶层图。

这里，将教材购销系统当做一个大的加工，标明系统的输入与输出及数据的源点与汇

点(即外部项)显示教材购销系统的顶层图。如图 2.20 所示，系统从学生接受购书单，经处

理后把领书单返回给学生，使学生可凭单到书库领书。对脱销的教材，系统用缺书单的形

式通知书库；新书进库后，也由书库将进书单通知返回系统。

接下来画 0层的数据流图，把系统分解为销售和采购两大加工。如图 2.21 所示，学生

应与销售子系统联系，保管员应与采购子系统联系。两个子系统之间也存在两项数据联系：

其一是缺书登记表，由销售子系统把脱销的教材传送给采购子系统；其二是进书通知，直

接由采购子系统将教材入库信息通知销售子系统。

继续分解，就可获得第 1层数据流图。其中图 2.22 由销售子系统扩展而成，图 2.23 由

采购子系统扩展而成。

购书单

学

生 学

生

教材

购销

系统 进书通知 领书单

缺书单

图 2.20 教材购销系统的顶层 DFD

第 2章 软件需求分析

·43·

·43·

在图 2.22 中，销售子系统被分解成 6 个加工，编号为 1.1～1.6。审查有效性，首先要

核对购书单的内容是否与学生用表(F3)相符，还要通过售书登记表(F4)检查学生是否已经买

过这些教材。若发现购书单中有学生不用或者是买重了的教材，便发出无效书单，只有通

过了审查的教材保留在有效购书单中。“开发票”加工框按购书单的内容查对教材表存量

表(F1)，把可供应的教材写入发票，数量不足或全缺的教材写入暂缺书单。前者在 F4 中登

记后开出领书单发给购书的学生，后者则登记到缺书登记表(F2)中，等待接到进书通知后

再补售给学生。补售的手续及数据流程与第一次购书单相同。注意，在图 2.22 中销售子系

统的数据流图中将采购由原来系统内部的一个加工框变成销售子系统中的一个外部项。

图 2.22 教材购销系统的 1层 DFD－销售子系统

采购子系统在图 2.23 中被分解为 3 个加工。由销售子系统建立起来的缺书登记表(F2)，

首先按书号汇总后登入待购教材表(F5)中，然后再按出版社分别统计缺书单，送给书库保

进书购书单

进书通知 领书单

缺书单

图 2.21 教材购销系统的 0层 DFD

学

生

学

生 1

销售 2

采购

F2 缺书登记表

F1 教材存量表

发票

发票 暂缺 书单

领书

有效 购书单 无效书单

进书通知

购书单

学

生 学

生

F2 缺书登记表

F1 教材存量表

1.5 登记 缺书

F4 售书登记表 F3 学生用书表

1.6 产生 补书单

1.1 审查 有效性

1.2 开发票

1.3 打印 发票

1.4 登记售书打印书单

采

购

补售

书单

软件工程基础教程

·44·

·44·

管员作为采购教材的依据。在汇总缺书时要再次核对教材存量表(F1)，分出版社统计时还

要参阅教材一览表(F6)，可以知道这些缺书的出版社。新书入库后及时修改教材存量表的

待购教材表中的有关教材数量，同时把进书信息通知销售部门，使销售人员能通知缺书的

学生来补买。

以上三层 4张数据流图(图 2.20～图 2.23)，一起构成了教材购销系统的分层数据流图。

随着分层的继续，加工越来越细。第 1层共有 9 个加工框，是由足够简单的基本加工组成。

从分析上例的过程可以看出，分层数据流图采用逐步细化的扩展方法，避免一次出现

过多细节，有利于控制问题的复杂程度，便于实现；用一组图代替一张总图，用户中的不

同业务人员可以选择与本身有关的图形，不必阅读全图，例如在本例中，销售人员只需阅

读图 2.22，书库保管员只需阅读图 2.23，这样就方便了用户。

图 2.23 教材购销系统的 0层 DFD－采购子系统

2.5.2 确定数据定义与加工策略

分层数据流图为整个系统描述了一个概要，下一步应该考虑系统的细节，如定义数据、

确定加工等。

最低一层数据流图包含了系统的全部数据和加工。从数据流图的汇点开始分析数据定义

与加工策略。因为汇点的数据代表系统的输出，要求是明确的。由这里开始，沿着数据流图

一步步向数据源点回溯，能够看清楚每一个数据项的来源去向，有利于减少错误与遗漏。

以图 2.22 为例，“领书单”是系统的主要输出数据流。从向用户的调查中得知，领书

单至少要包括学号、姓名、书号和数量 4 个数据项。而它的数据流，图中框 1.4 的输入数

据流的组成是：

发票＝学号姓名＋｛书号＋单价＋数量＋总价｝＋书费合计

可见领书单中的全部内容，都能在发票中找到。框 1.4 的策略之一是从中选择有用的数

据项写入领书单。其次，该框还要登记售书，防止学生重复购买，所以售书登记表(F4)中组

成应与领书单的组成相同。再往前追溯到框 1.2，输入这个框中的“有效购书单”的组成：

有效购书单＝学号＋姓名＋｛书号＋数量｝

与发票相比较，它缺少单价、总价和书费合计 3 个数据项。显然，框 1.2 在出发票前，

必须计算每种书的总价和所有售书的合计书费。但“单价”从哪里来呢？在图 2.22 中，

进书通知 进书通知 销

售

保

管

员

2.3 修改

库存与

待购量

F1 教材存量表

F2 缺书登记表

F6 教材一览表

2.1 按书号

汇总缺

2.2 按出版社统计缺书

F5 待购教材表

缺书单

第 2章 软件需求分析

·45·

·45·

框 1.2 可访问的文件只有一个，即教材存量表(F1)。可见该文件不仅要在存储各种现有的数

据，还应包括它们的单价。即：

教材存量表＝｛书号＋单价＋数量｝

现在再考查框 1.2 的加工策略。接到有效购书单以后，它首先要访问教材存量表(F1)，

查清有哪些书的数据不能满足购书单的要求，将暂缺书单送到框 1.5，并由该框把信息存入

缺书登记表(F2)。为方便以后的补售，暂缺书单、补售书单和缺书登记表的组成，都可以

与有效购书单相同，即

暂缺书单＝学号＋姓名＋｛书号＋数量｝

补售书单＝学号＋姓名＋｛书号＋数量｝

缺书登记表＝｛学号＋姓名＋｛书号＋数量｝｝

对当前可以供应的教材，一方面要计算每种书的单价和书费累计，另一方面要更改存

书量，把剩余的写回到教材存量表中。有效购书单的上述数据流程及处理流程也适应于补

售书单，不再重复。

继续回溯，就可找到框 1.1，或者由补售书单找到框 1.6，请读者继续分析分别得出这

两个框的加工策略和有关数据的定义。

上述分析结束后，系统分析员应对数据流图的每个数据逐一定义，每个基本加工逐个

进行加工说明，并汇编成数据字典。

综上所述，分层数据流图产生了系统的全部数据和加工，通过对这些数据和加工的定

义，常常对分析员提出一些新问题(如前面所说的教材“单价”的问题)，促使他进行新的

调查研究，并可能导致对数据流图的更改。画数据流图，定义加工和数据，再画，再定义，

形成一个循环的过程，直到产生一个为用户和系统分析员都同意的文档——软件需求规格

说明书。

2.5.3 复审

需求分析的文档完成后，应由用户和系统分析员共同进行复审。因为需求说明是软件

设计的基础，复审吸收设计人员参加，并由本项目的软件人员任复审组长。复审结束后，

用户和开发人员均应在需求说明书上签字，作为软件开发合同的组成内容。签字后再有更

改，双方要重新协商，达成协议方能修改。

2.6 需 求 验 证

软件需要分析阶段的结果是软件开发项目的重要根据，大量统计数字表明，软件系统

中约 15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开

发成本，对目标系统提出一组要求后，必须严格验证需求的正确性。这个环节的参与者有用

户、管理部门、软件设计、编码和测试人员。一般说来，应该从下述几个方面进行验证。

1. 一致性

所有的软件需求都必须是统一的，任何一条需求都不能和其他需求矛盾。用自然语言

书写的软件需求规格说明书是难于验证的，特别是目标规模大、软件需求说明书较长的时

候，人工复审没有更好的方法进行测试。一些没有保证的、冗余的、遗漏和不一致的问题

软件工程基础教程

·46·

·46·

可能不容易被发现而被保留下来，为以后的软件设计留下后患。为了克服这困难，人们使

用形式化的语言书写软件需求规格说明书，可以用软件工具验证需求的一致性。

2. 现实性

指定的需求应该是用现有的硬件技术和软件技术能够基本实现的。如果超出了现有的

技术基础，就会增加软件实现的难度，提高软件开发成本，甚至导致软件开发的失败。由

此，验证时，应该参照以往开发系统的经验，分析现有的软、硬件实现目标系统的可行性。

必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。

3. 完整性与有效性

需求必须是完整的，软件需求说明书中必须包括用户需要的每个功能或性能。需求必

须是正确有效的，确实能解决用户的实际问题。只有用户才真正知道软件需求说明书是否

完整、准确地描述他们的需求。检验需求的完整性与有效性必须在用户的合作下才能完成。

而大多用户并不能清楚地说明自己的需求，也不能根据软件需求说明书确认是否满足自己

的实际需求。使用快速原型方法是比较现实的解决方案。让用户试用一段时间原型系统，

让他们能够认识到他们的真正需要什么。对比现有的需求分析，可以提出更符合实际的要

求。同时，软件设计、编码及测试人员的参与，更进一步加深与用户的沟通，理解用户的

真实需求，有益于软件开发的各个环节的联系，保证目标系统的完整性与有效性。

2.7 软件需求规格说明书书写范例

本节以学生收费管理系统软件需求说明书为例，让大家在结构和内容上对软件需求说

明书有个大概的了解，因为篇幅关系，大多数内容没有写全。大家在学习时可以根据本章

所讲内容进行修改添加。

1. 引言

随着信息社会的高科技化、商品经济的高效益化，计算机的应用已经普及到经济和社

会生活的各个领域。为了适应学校对学生收费工作的需要，出现了基于计算机的学生收费

系统，这为各级学生收费工作带来了极大的方便。该软件是以 SQL语言作为实现语言，以

ASP 作为主要技术手段。通过操作手册，使用户可以了解本软件的工作过程，考虑到不同

层次的用户，一方面可以通过简单的鼠标和键盘操作实现收费工作中的相关操作，另一方

面也可以使有一定计算机基础的用户根据自己的需求对相关的内容进行相应的修改，以便

适应不同学校的实际情况。

1) 编写目的

本需求的编写目的在于研究高校学生收费管理系统软件的开发途径和应用方法。

本需求的预期读者是与收费系统开发相联系的决策人、开发组人员、辅助开发者、使

用本项目的领导、具体使用者和软件验证者。

2) 项目范围

项目名称：学生收费管理系统

项目开发者：学生收费管理系统开发小组

第 2章 软件需求分析

·47·

·47·

项目用户：财务部门、学生工作部门、教材管理部门、住宿管理部门

本产品将财务部门、学生管理部门、宿舍管理部门、教材管理部门等联系到一起，便

于进行学生收费、注册、宿舍和教材等各部分的管理，同时，还可以让学生通过查询自己

的交费使用情况，增加了学生对相关费用的了解。

3) 参考资料

《实用软件工程》 郑人杰，殷人昆，陶永雷编著 清华大学出版社

《软件工程》 张海藩编著 清华大学出版社

《数据库原理与应用》 李昭原主编 科学出版社

《SQL Server 2000高级开发指南》 精英科技编著 中国电力出版社

《ASP 后台数据库网站制作实例经典》梁嘉超、卢山、夏运强编著 清华大学出版社

2. 任务概述

1) 产品概述

� 软件开发意图：为了使学生收费管理系统更加完善，以校院网络作为基础，利用计

算机系统实现学生管理各个相关部门的联系，减轻学生收费相关管理人员的工作负

担，增加学校收费的透明度，实现对学生各种相关事务的统一管理。

� 该软件的应用目标：通过本软件使管理人员利用计算机，快速方便地管理学生收费、

学生注册、教材发放和宿舍管理等相关事务，使分散、杂乱的管理变得统一化。

� 该软件的作用范围：本软件适应于高等学校，是比较完善的学校管理软件，对学生

的收费、学籍的注册、教材的领取和宿舍的管理等可以进行宏观调整、管理。

� 该软件开发背景：随着学校规模的日益扩大、学生人数的增多，人工的服务系统非

常费时，学生开学时交费，注册、教材和宿舍等都会运用大量的人力和物力，给学

校管理工作带来极大的不方便。为了解决以上问题，决定开发本软件。

2) 用户特点

本软件的使用对象是学生管理部门工作人员，掌握一般计算机的基本操作就可以利用

该软件进行相关操作。

3) 条件与约束

� 项目的开发经费不超过 1万元。

� 项目的开发时间不超过半年。

� 主负责人 1名，开发小组 5 人，其他人员 2名。

� 在管理方针、硬件限制、并行操作安全和保密方面有一定限制。

4) 预计不良后果

假设开发经费不到位，管理不完善，数据处理不规范，各部门需求分析调查不细致，

本项目的开发会受到很大影响。

3. 需求规定

1) 对功能的规定

� 外部功能：该软件具有输入/输出和查询等功能。

� 内部功能：该软件集命令、编程和编辑于一体，完成过滤、定位显示等功能。

软件工程基础教程

·48·

·48·

2) 对性能的规定

� 精度：在精度需求上，根据使用需要，在各项数据的输入/输出及传输过程中，可以

满足各种精度的需求。

� 时间特性要求：在软件方面、响应时间、更新处理时间方面满足用户要求。

� 灵活性：当用户需求，如操作方式、运行环境、结果精度、数据结构与其他软件接

口等发生变化时，设计的软件能做适当调整，满足不同用户的要求。

3) 输入/输出要求(略)

4) 数据管理能力要求(略)

5) 故障处理要求(略)

6) 其他专门要求(略)

7) 保密性(略)

4. 运行环境规定

1) 设备

运行该软件所适用的具体设备要求：客户端是奔腾以上的 CPU、内存在 128 MB 以上

的计算机，硬盘容量在 10 GB 以上。数据库服务器的内存在 256 MB 以上，硬盘容量在 100

GB 以上。

2) 支持软件(略)

3) 接口

� 用户接口：本产品的用户一般需要通过终端进行操作，进入主界面后单击相应的窗

口，分别进入相对应的界面。不同部门人员的操作权限不同。用户对程序的维护要

有备份。

� 软件接口：Windows 9x/2000/NT/XP操作系统，服务器安装 SQL Server 2000企业版

服务器端工具，用户终端安装 SQL Server 2000 客户端工具。

4) 控制

本软件是以 SQL语言来控制软件运行的。

习 题

1．说明以下常用缩略语的含义

SRS、SA、OOA、DFD、DD、PSPEC、STD、ER、IPO。

2．名词解释

访谈、情景、简易的应用规格说明技术、快速原型法、数据流、加工、文件、源点、

汇点、数据项、数据字典。

3．填空题

(1) __________是软件生存期中重要的一步，是软件定义阶段的最后一个阶段，是关系

到软件开发成败的关键步骤。

(2) 在软件需求分析中，必须采用合理的步骤，才能准确地获取软件的需求，可归纳

第 2章 软件需求分析

·49·

·49·

为 4 个步骤：__________、__________、__________、__________。

(3) 访谈是最早使用的获取用户需求的技术，也是世界上仍然广泛使用的需求分析技

术。访谈有两种基本形式：__________和__________。

(4) 软件的分析模型通常由一组模型组成，包括 __________ 、 __________ 和

__________。从数据字典出发主要通过以下 3 种图来构建该模型的 3 种模型：__________、

__________和__________。

(5) 数据流图由_________、_________、_________、_________组成。

(6) 加工说明的描述工具通常有 3 种：__________、__________、__________。

4．单项选择题

(1) 软件需求分析阶段最重要的技术文档之一是( )。

A. 项目开发计划 B. 设计说明书

C. 需求规格说明书 D. 可行性分析报告

(2) 在软件需求分析之前有必要进行( )。

A. 程序设计 B．可行性分析

C. ER 分析 D．3NF 分析

(3) 软件需求分析阶段建立原型的主要目的是( )。

A. 确定系统的功能和性能要求 B. 确定系统的运行要求

C. 确定系统是否满足用户需求 D. 确定系统是否满足开发人员需求

(4) 软件开发的需求活动，其主要任务是( )。

A. 给出软件解决方案 B．给出系统模块结构

C. 定义模块算法 D．定义需求并建立系统模型

(5) 软件需求分析阶段的研究对象是( )。

A. 用户要求 B. 分析员要求

C. 系统要求 D. 软硬件要求

(6) DFD 用于描述系统的( )。

A. 数据结构 B. 控制流程 C.基本加工 D. 软件功能

(7) DFD 中的每个加工至少需要( )。

A. 一个输入流 B. 一个输出流

C. 一个输入或输出流 D. 一个输入流和一个输出流

(8) 数据字典不包括的条目是( )。

A. 数据项 B. 数据流 C. 数据类型 D. 数据加工

(9) 软件需求规格说明书的作用不包括( )。

A. 软件验收的依据 B. 用户与开发人员对软件要做什么的共同理解

C. 软件可行性研究的依据 D. 软件设计的依据

(10) 软件需求分析是保证软件质量的重要步骤，它的实施应该是在( )。

A. 编码阶段 B. 软件开发全过程 C. 软件定义阶段 D. 软件设计阶段

5．思考题

(1) 软件需求分析的任务是什么？

软件工程基础教程

·50·

·50·

(2) 软件需求分析主要经过哪些步骤？

(3) 常规的需求获取的方式有哪些？你认为比较有效的方式是哪种？请说明理由。

(4) 简述快速原型法的原理及步骤。

(5) 主要有哪几种分析模型？它们各自的特点是什么？

(6) 结构化分析建模常用的描述工具有哪些？请说明各自的特点。

(7) 软件需求规格说明书主要是由哪些部分组成？它的作用是什么？

(8) 为什么数据流图要分层？画分层数据流图一般需要注意什么？

(9) 补充图 2.16 某计算机公司产品的层次方框图。

(10) 利用 Warnier 图描述图 2.16 中产品信息的具体情况。

(11) 试用改进后的 IPO 图描述教材购销系统采购及销售子系统。

(12) 为什么要进行需求验证？主要是从哪些方面考虑？

6．设计题

(1) 对学校网上选课系统进行需求分析，并写出软件需求说明书。

(2) 某图书管理系统有以下功能：

① 借书：输入读者借书证。系统首先检查借书证是否有效，若有效，对于第一次借书

的读者，在借书文件上建立档案；否则，查阅借书文件，检查该读者所借图书是否超过 10

本，若已达到 10 本，拒借，未达到 10 本，办理借书(检查库存、修改库存目录并将读者借

书情况登入借书文件)。

② 还书：从借书文件中读出与读者有关的记录，查阅所借日期，如果超期(3个月)作罚款

处理；否则，修改库存目录与借书文件。

③ 查询：可通过借书文件、库存目录文件查询读者情况、图书借阅情况及库存情况，

打印各种统计表。

请就以上系统功能画出分层的 DFD，并建立重要条目的数据字典。