软件工程之软件需求分析

软件需要解决的是用户所面临的现实问题，但是，这些现实问题需要由软件技术人员来解 决。情况往往是，开发软件的技术人员精通计算机技术，但并不熟悉用户的业务领域；而用户 清楚自己的业务，却又不太懂计算机技术。因此，对于同一个问题，技术人员和用户之间可能 存在认识上的差异。也因此，在软件技术人员着手设计软件之前，需要由既精通计算机技术又 熟悉用户应用领域的软件系统分析人员，对软件问题进行细致的需求分析。 需求分析是软件工程过程中一个重要的里程碑。在需求分析过程中，软件系统分析人员通 过研究用户在软件问题上的需求意愿，分析出软件系统在功能、性能、数据等诸多方面应该达 到的目标，从而获得有关软件的需求规格定义，其信息流如图 4-1 所示。
 需求分析是在软件系统分析人员的操作下进行的，在这个过程中，用户和开发者之间需要 达成的是对系统的一致性需求认识。实际上，可以把软件系统分析人员看成是软件用户与软件 开发技术人员之间的信息通道，其作用是使用户对软件问题的现实描述，能够有效地转变为开 发软件的技术人员所需要的对软件的技术描述，以方便技术人员对软件的技术构建

需求分析是在软件系统分析人员的操作下进行的，在这个过程中，用户和开发者之间需要 达成的是对系统的一致性需求认识。实际上，可以把软件系统分析人员看成是软件用户与软件 开发技术人员之间的信息通道，其作用是使用户对软件问题的现实描述，能够有效地转变为开发软件的技术人员所需要的对软件的技术描述，以方便技术人员对软件的技术构建。

 

一、需求分析任务

需求分析需要实现的是将软件用户对于软件的一系列意图、想法转变为软件开发人员所需要的有关软件的技术规格，并由此实现用户和开发人员之间的有效通信，它涉及面向用户的用 户需求和面向开发者的系统需求这两个方面的工作内容。

1.用户需求

用户需求是用户关于软件的一系列意图、想法的集中体现，涉及软件的操作方式、界面风格、报表格式，用户机构的业务范围、工作流程，以及用户对于软件应用的发展期望等。因此， 用户需求也就是用户关于软件的外界特征的规格表述。 实际上，用户需求提出了一个有关软件的基本需求框架，具有以下特点：

　　（1）用户需求直接来源于用户，可以由用户主动提出，也可以通过与用户交谈，或对用户 进行问卷调查等方式获取。由于用户对计算机系统认识上的不足，分析人员有义务帮助用户挖掘需求，例如，可以使用启发的方式激发用户的需求想法。如何更有效地获取用户需求，既是 一门技术，也是一门思维沟通艺术。

　　（2）用户需求需要以文档的形式提供给用户审查，因此需要使用流畅的自然语言或简洁清 晰的直观图表来进行表述，以方便用户的理解与确认。

　   （3）可以把用户需求理解为用户对软件的合理请求，这意味着，用户需求并不是开发者 用户的盲目顺从，而是建立在开发者和用户共同讨论、相互协商的基础上。

　   （4）用户需求主要是为用户方管理层撰写的，但用户方的技术代表，软件系统今后的操作 者，以及开发方的高层技术人员，也有必要认真阅读用户需求文档。

 

2.系统需求

系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅 读的，并将作为软件开发人员设计系统的起点与基本依据。 系统需求需要对系统在功能、性能、数据等方面进行规格定义，由于自然语言随意性较大， 在描述问题时容易发生歧义，因此系统需求往往要求用更加严格的形式化语言进行表述，例如 PDL 伪码，以保证系统需求表述具有一致性。 系统需求涉及有关软件的一系列技术规格，包括：功能、数据、性能、安全等诸多方面的 问题。

 

（1）功能需求

功能需求是有关软件系统的最基本的需求表述，用于说明系统应该做什么，涉及软件系统 的功能特征、功能边界、输入输出接口、异常处理方法等方面的问题。也就是说，功能需求需 要对软件系统的服务能力进行全面的详细的描述。 在结构化方法中，往往通过数据流图来说明系统对数据的加工过程，它能够在一定程度上 表现出系统的功能动态特征。也就是说，可以使用数据流图建立软件系统的功能动态模型。

（2） 数据需求

数据需求用于对系统中的数据，包括：输入数据、输出数据、加工中的数据、保存在存储 设备上的数据等，进行详细的用途说明与规格定义。 在结构化方法中，往往使用数据字典对数据进行全面准确的定义，例如，数据的名称、别 名、组成元素、出现的位置、出现的频率等。当所要开发的软件系统涉及到对数据库的操作时， 还可以使用数据关系模型图（ER图）对数据库中的数据实体、数据实体之 间的关系等进行描述。

（3） 其他需求

其他需求是指系统在性能、安全、界面等方面需要达到的要求。

 

二、需求分析过程

需求分析是对软件系统的后期分析，需要进行一系列的活动，包括：分析用户需求、建立 需求原型、分析系统需求和进行需求验证等，其活动流程如图 4-2 所示。

（1）需求分析可以可行性分析中软件系统的高层模型为前提，首先需要进行的是分析用户 需求，由此可以提出关于软件的需求框架。 （2）由于用户对计算机信息系统认识上的模糊性，以致直接来源于用户的需求想法往往存 在着许多缺陷，例如：需求冲突、需求遗漏。为提高用户需求的有效性，可以按照需求框架的 要求建立需求原型让用户确认，然后再通过需求原型去提取系统模型。

（3）系统需求是面向技术人员的。因此，它不仅需要从需求原型中提取系统模型，而且需 要对系统模型进行细节化处理，例如：数据流细化、数据字典分解、类模型的定义等，由此获 得对系统的详细的技术性需求说明。

（4）对需求框架、系统模型和需求细节等文档进行有效性验证，由此产生出用户方、开发 方都能接受的关于软件的需求规格说明书。

 

三、用户需求获取

优秀软件总是能够最大限度地满足用户需求。因此，有效获取用户需求，是实施软件开发 时需要完成的第一项工作。

1.研究用户

在建立软件抽象模型过程中，用户可以被当作为一个抽象概念，泛指诸多从系统获得服务 的系统以外的对象，例如：软件使用机构，软件操作人员，以及从软件获得信息服务的其他系 统或设备。也就是说，可以把用户看作为系统的外部应用接口。但从软件的商业服务角度来看， 用户则主要是指购置软件的机构、使用软件的部门、操作软件的人。 软件是为用户开发的，为了使软件能够更好地为用户服务，在软件需求阶段，软件开发者 应该尽量充分地和用户进行沟通，了解用户的意图。例如，用户希望软件为他提供哪些方面的 服务，用户在操作软件时有哪些工作习惯，喜欢什么样的工作界面等。 软件往往需要为各种不同的用户服务，例如，用户机构负责人、使用软件的部门主管、软 件操作人员，他们都是用户，但由于所处位置不同，因此会有不同的需求。软件操作人员大多需要较长时间地操作软件，因此他们会特别关心软件的工作方式、界面布局；使用软件的部门 主管则一般不会直接操作软件，但他需要从软件中得到年度报表之类的打印数据，因此比较关 心软件能够提供哪些方面的报表，报表格式如何等。 用户情况是复杂的，为了更好地研究用户，有必要对软件用户做一些分类，例如：按软 件需求层次不同，将用户分为高层用户、中层用户和基层用户；按使用软件时间长短不同， 将用户分为熟练用户和非熟练用户；按是否直接操作软件系统，将用户分为直接用户和间接 用户。

2. 从调查中获取用户需求

直到今天，用户调查仍是最基本的用户需求信息收集方法。应该说，用户需求信息来源是 多方面的，为了保证用户需求的完整性，在需求分析过程中，软件系统分析人员往往需要调查 各类能够代表用户意愿的相关人员，如图 4-3 所示。

 

实际上，针对不同的应用项目通常会有不同的调查内容，需要采用不同的调查策略。例如， 开发一个信息管理系统，其用户需求调查一般会涉及以下方面的内容：

（1）调查用户的组织机构，包括：该组织的部门组成，各部门的职责等。由此得到的调查 结果将作为分析软件系统领域边界的基本依据。 （2）调查用户各部门的业务活动，包括：各个部门输入和使用什么数据，如何加工处理这 些数据，输出什么数据，输出到什么部门等。这是需求调查的重点内容，其结果将作为分析软 件系统工作流程的基本依据。

（3）调查用户对软件系统的各项具体要求，包括：数据格式、操作方式、工作性能、安全 保密等方面的要求。

 

在调查过程中，可以根据不同的问题和条件，使用不同的调查方法。比较常用的调查方法 有以下几种：

   a. 访谈用户

访谈用户就是面对面地跟单个用户进行对话。例如，请用户机构高层人员介绍用户的组织 结构、业务范围、对软件应用的期望。

   b. 开座谈会

当需要对用户机构的诸多部门进行业务活动调查与商讨时，可以考虑采用开一个座谈会的 方式。这既有利于节约调查时间，又能使各部门之间就业务问题进行协商，以方便对与软件有 关的业务进行合理分配与定位。

  c. 问卷调查

问卷调查一般是通过精心设计的调查表去调查用户对软件的看法。当面对一个庞大的用户 群体时，可能需要采用问卷调查形式进行用户调查。例如在开发通用软件时，为了获得广大用 户对软件的看法，就不得不采取问卷方式。如果调查表设计得合理，这种方法很有效，也易于 为用户接受。

  d. 跟班作业

跟班作业就是软件分析人员亲身参加用户单位业务工作，由此可直接体验用户的业务活动 情况。这种方法可以更加准确地理解用户的需求，但比较耗费时间。

e.收集用户资料

尽管有待开发的软件需要在较长时间以后才能交付用户使用，但跟软件有关的工作用户却 一直在以其他方式或通过其他系统进行着，并且也一直在产生结果。用户资料主要就是指这些 结果，例如：年度汇总报表、提货单、工资表等。软件分析人员应该认真收集这些资料，由此 可以更加清楚地认识用户的软件需求。

 

3.通过原型完善用户需求

需求原型可用来收集用户需求，对用户需求进行验证，由此可帮助用户克服对软件需求的 模糊认识，并使用户需求能够更加完整地得以表达。例如，用户对软件应该提出哪些方面的服 务，操作界面应该如何等可能拿不定主意，为了使用户能够更加直观地表述自己的需求意愿， 可以先构造一个原型给用户体验。 原型需要根据用户的评价而不断修正，这也有利于挖掘用户的一些潜在需求，使得用户需求能够更加完整地得以表达。一般情况下，开发人员将软件系统中最能够被用户直接感受的那 一部分东西构造成为原型。例如，界面、报表或数据查询结果。实际上，在诸多原型中，界面 原型是应用得最广泛的原型。 如图 4-4 所示，

 

 

需求原型可以建立在用户所提出的需求框架基础上。需求原型的作用是能 够方便系统模型的创建。也就是说，需求原型可以方便由用户需求到系统需求的过渡。

 

（1）仓库管理系统将被计划部门、仓库管理部门、采购部门、销售部门的相关工作人员使 用。其中，计划部门制定商品计划，涉及：设置商品类别、登记商品、制定商品报损计划和进 行商品流通数据汇总；仓库管理部门完成仓库的日常管理，涉及：商品入库、出库、报损和查 询等多项操作；采购部门可以查询商品库存情况、打印商品定货报表；销售部门可以查询商品 库存情况和提交商品定货请求。

（2）由于不同部门有不同的任务，因此系统需要提供针对部门的权限管理机制和针对工作人员的登录注册机制。系统将通过一位系统管理员进行部门授权与工作人员注册管理。 

（3）进入仓库管理系统的工作人员需要有惟一的个人身份标识，它既是工作人员登录系统 时的身份验证依据，也是工作人员在进行商品操作时的经手人标记。尽管工作人员的姓名也可 以用做其身份标识，但不同的工作人员有可能会出现姓名重复，因此有必要为工作人员设置一 个专门的身份标识码。

（4）仓库以商品品种为基本单位进行管理，所有商品都要由计划部门按品种进行登记，涉 及商品编码、名称、类别、库存下限值等数据。其中，商品库存量初始值为零。

（5）仓库商品涉及入库、出库、报损这三种流通方式。凭采购部门填写的入库单进库，凭 销售部门填写的出库单出库，凭计划部门制定的报损计划报损。商品的任何流通都需要以流水 方式记录到商品流通表中，并对商品库存量进行更新。当商品出库、报损时，必须考虑到该商 品的当前库存量是否能够满足操作需要。出库、报损后，若商品库存量低于库存下限值，将自 动产生定货请求。

（6）可以按商品类别或品种进行商品库存情况和当月商品流通情况的查询。另外，仓库管 理系统需要自动在月底对商品流通数据进行盘查，包括：按月打印商品流通分类汇总报表，并 按月备份商品流通数据，然后将已备份的商品流通数据进行合计整理。

 

四、结构化分析建模

人在求解问题时，首要需要做的是理解问题，并且对问题理解得越透彻，则这个问题就越 容易解决。所谓模型，就是为了理解问题而对问题做的一种符号抽象。可以把模型看作为一种 思维工具，利用这种工具可以把问题规范地表示出来。 模型一般由一组图示符号和组织这些符号的规则组成。因此，分析时期的建模，就是针对 用户需求、系统需求等，采用图示方式进行直观描述。 软件问题往往是复杂的，而建模可以使问题简化。人的头脑每次只能处理一定数量的信息， 模型通过把系统分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。分析 时期建立软件模型的作用是多方面的，可以通过模型实现由用户需求向系统需求的过渡，并可 通过模型获得对系统需求的更具细节性的推论。实际上，分析时期产生的模型还可以被引用到 系统设计中去，作为设计前导。 为了开发复杂的软件系统，往往需要从不同角度去构造系统模型。例如，用于描述系统功能组织结构的层次模型，用于描述系统中数据加工流程的数据流模型，用于描述数据实体及其 关系的数据关系模型，用于描述系统行为过程的系统状态模型等。

1.功能层次模型

功能层次模型图使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来表达系 统所具有的功能层级关系。 实际上，不仅可以使用层次图清晰地说明系统的功能组成关系，也可以使用功能层次图对 系统的功能关系进行调整，从而使系统的诸多功能得到更加合理地分配。

 

2.数据流模型

（1）数据流图特点

数据流模型由 DeMarco 于 1978 年提出，并随着他的结构化分析思想一起被广为流行。数据流图用于描述系统对数据的加工过程，其图形符号是一些具有抽象意义的逻辑符号。表 4-1 所列是数据流图的基本符号。 在软件定义时期，数据流图被用来描述系统的逻辑加工步骤。由于数据流图能够为有待开发的系统提供一种简洁的逻辑图形说明，能够方便用户对系统分析的理解，因此，它也被用做 开发者和用户之间的信息交流工具。

 

 （2）数据流图的用途

可以依靠数据流图来实现从用户需求到系统需求的过渡。例如，可以将用户需求陈述中的 关键名词、动词提取出来，其中的名词可以作为数据流图中数据源、数据存储，而动词则可以 作为数据流图中的数据加工进程。

数据流图也能够方便系统物理模型与逻辑模型之间的转换，可以将 3.1.3 节中系统流程图 经过符号转换而获得系统的数据流图，例如图 3-3 的系统流程图，通过转换符号可以得出图 4-6 的数据流图。数据流图的这个特点表明，可以基于系统的基本物理框架而抽取它的逻辑模型。

 

软件系统是复杂的，为了方便问题的解决，有必要将系统进行分解，由此将一个大的复杂 问题解剖为许多小的相对简单的问题。例如，可以按照系统的功能构成，将系统分解为许多子 系统，各子系统又可以再分解为许多更小的功能模块，由此可以不断深入地了解软件系统的功 能细节。由于数据流图使用的是抽象的图形符号，因此，它不仅能够描述系统对数据的加工步 骤，而且能够依靠对其图形符号的逻辑细化而方便地实现对系统中数据加工步骤的有效分解。

 

（3） 数据流细化过程

数据流细化的过程即是从上至下对系统功能进行分层描述的过程，如图 4-7 所示。其中， 高层数据流对功能的描述是抽象的，但通过逻辑细化能够深入到系统内部的低层数据流，而使 对功能的描述逐步具体化。结构化分析就是基于数据流的细化实现的，它是结构化分析方法的 关键。 实际上，数据流图对系统的描述可以从任何层面开始，只要那个层面的诸多软件问题是清 晰的，则在该层面上获得的数据流图也就可以是清晰的。但是，进入系统的层面越深，则遇到的问题点越多，数据流越复杂。为了更加清楚地表现系统的功能，数据流图往往从容易辨别的 高层开始，然后通过数据流的细化逐步深入。这个过程也就是从抽象到具体的解决问题方法在 软件分析上的具体体现。

 

当面对一个有待开发的新系统进行数据流描述时，数据流图往往需要从最顶层画起，使用 一个数据处理框来表示整个系统，以反映系统与周围环境的关系，然后通过数据流的细化而获 得 0 层、1 层，以及更下层的数据流图。 图 4-8 是一个“工资管理系统”的顶层数据流图，其中的处理框表示所要描述的系统，而 三个外部接口（人事处、财务处、员工所在工作部门）则可以表示系统的工作环境。系统与外 部接口之间的通信可以通过数据流，图 4-8 中有四个数据流，即：职工清单、档案工资、业绩 工资、工资报表。
 

当需要对高层数据流细化以获得对低层数据流的描述时，一种有效的方法是对高层数据流 图中的数据加工进行合理分解。通过把一个数据加工分解为多个数据加工可以看到这个数据加 工的内部细节。 例如，图 4-8 所描述的“工资管理系统”数据流图。假如“工资管理系统”可以具有以下三项功能：

（1）输入职工名册清单；

（2）从员工的档案工资和业绩工资的计算中产生工资数 据；

（3）依据人事部门提供的职工清单按月打印出员工的工资报表。

那么，可以考虑将“工资 管理系统”分解为以下三项处理，即：

（1）提供职工清单；

（2）产生工资数据；

（3）打印工 资报表。

图 4-9 即是依照上述功能分解而从顶层数据流图细化出来的 0 层数据流图。从 0 层数据流 图可以看到数据流在细化时具有以下特点： （1）与上一层数据处理“工资管理系统”相关的数据流被继承了下来。

（2）上一层数据处理“工资管理系统”中不可见的内部数据流变成了可见的外部数据流。

数据流细化被用来分析系统的内部功能构造。然而，面对一个具有一定规模的软件系统， 0 层数据流图往往只能对其功能进行一般性的高层描述。因此，为了使数据流对系统功能的描 述更加具体，数据流细化往往还需要继续深入下去。 实际上，可以使用数据流进行软件结构的映射（结构化设计）。一般情况下，假如希望将 数据流用于软件设计，则对数据流细化更需要以设计中的模块构件作为分解目标。 因此，可以考虑对“工资管理系统”进行更加深入的数据流细化。例如，“工资管理系统” 0 层数据流图中的“产生工资数据”处理，假如其工资数据的产生涉及数据录入、数据计算等 更加具体的数据操作，则“产生工资数据”处理可以进一步分解为：“录入档案工资”、“录 入业绩工资”、“计算工资”这三项处理。 图 4-10 即是对“产生工资数据”处理框进一步细化后产生出来的 1 层数据流图。其中的 数据加工流程是：

（1）来源于“人事处”和“员工所在工作部门”的“档案工资”、“业绩工资”数据流， 经“录入档案工资”、“录入业绩工资”的处理之后，被分别存入到“档案工资表”、“业绩 工资表”这两个数据存储之中。

（2）系统可以从“档案工资表”和“业绩工资表”这两个数据存储读取数据，然后通过“计算工资”的处理产生出“工资数据”数据流。这个数据流将被存入到“工资数据表”中。

显然，这又是一个既涉及细化又包含继承的分析过程。与“工资管理系统”直接相关的数 据流成分被继承了下来（人事处、员工所在工作部门、工资数据表），而图 4-9 中不可见的内 部数据流则经过细化变成了可见的外部数据流。

 

（4） 数据流图中符号的命名

数据流图中的图形符号一般都需要命名，并遵循以下命名规则：

a.数据接口：使用名词或名词短语命名。例如：人事处、财务处、工资数据录入员、系 统管理员、读卡设备、打印设备。

b.数据存储：使用名词或名词短语命名。例如“工资数据表”。当数据存储是存储介质 上某个存储单元的存储片段时，其名称还需要用到限定词，例如“在职人员档案工资”。

c.数据流：使用名词或名词短语命名。但为了提高数据流图的清晰度，从数据存储中流 出，或流入数据存储的数据流，在不会发生名称混淆的前提下，可以省略名称。例如图 4-9 中 从“档案工资表”、“业绩工资表”流出，或流向“档案工资表”、“业绩工资表”的数据流。
d.数据处理：数据处理涉及处理方式与处理对象两方面的内容，一般使用“动词+名词 短语”的动宾结构来进行命名。例如，“录入档案工资”、“打印工资报表”。由于对数据流的细 化是通过对数据处理的分解实现的，考虑到对细化后的数据流图进行分层检索的便利，可以对 处理框进行合适的数字编码。例如，“2. 产生工资数据”、“2.1  录入档案工资”、“2.2  录入 业绩工资” 、 “2.3  计算工资”。

（5）数据流图中的数据字典

在需求分析中，数据字典是各类数据描述的集合，能够提供对数据的详细规格定义，并可 用于验证数据，以发现系统在数据需求描述中是否出现遗漏。 数据流图中的数据字典能够提供对图中的诸多数据元素的更加详细的说明。其一般要求是：

　　　　　　（1）对数据的定义应该是严密、精确、一致的，不能有二义性；

　　　　　　（2）需要对数据流图中的 每一个被命名的数据元素进行定义；

　　　　　　（3）需要分类定义各种不同种类的数据元素，或采用类别 代号加以区别。 数据流图中的数据字典通常包括数据项、数据结构、数据流、数据存储、数据接口和数据 处理过程这几个部分的数据内容。其中，数据项是数据的最小组成单位，若干个数据项可以组 成一个数据结构。数据字典就是通过对数据项和数据结构的定义来描述数据流、数据存储的逻 辑内容的。

　　　　　　（1）数据项 数据项是不可再分的数据单位。对数据项的描述通常包括以下内容： ｛数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数 据项的逻辑关系｝

　　　　　　（2）数据结构 数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由 若干个数据结构组成，或由若干个数据项和数据结构混合组成。对数据结构的描述通常包括以 下内容： ｛数据结构名，含义说明，组成：｛数据项或数据结构｝｝ 在定义数据结构时，可以采用以下符号说明数据的组成： =   被定义为，表示数据组成。 +  与，用于连接两个数据分量。 [⋯|⋯] 或，从若干数据分量中选择一个，方括号中的数据分量用“|”号隔开。 m{⋯}n 重复，重复花括号内的数据，最少重复 m 次，最多重复 n 次。 (⋯)  可选，圆括号内数据可有可无。

　　　　　　（3）数据流 数据流是数据结构在软件系统内传输的路径。对数据流的描述通常包括以下内容： ｛数据流名，说明，数据流来源，数据流去向，组成｛数据结构｝，平均流量，高峰期流量｝
 其中，数据流来源是说明该数据流来自哪个过程。数据流去向是说明该数据流将到哪个过 程去。平均流量则是指在单位时间（每天、每周、每月等）里的传输次数。高峰期流量则是指 在高峰时期的数据流量。

　　　　　　（4）数据存储 数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。对数据存储的描 述通常包括以下内容： ｛数据存储名，说明，编号，流入的数据流，流出的数据流，组成｛数据结构｝，数据量， 存取方式｝ 其中，数据量是指每次存取多少数据，每天（或每小时、每周等）存取几次等信息。存取 方式则包括：是批处理还是联机处理，是检索还是更新，是顺序检索还是随机检索等。另外， 流入的数据流要指出其来源，流出的数据流要指出其去向。 可以使用表格将数据字典分类列出。例如前面介绍的“工资管理系统”数据流图中的数据 字典，即可以通过表 4-2、表 4-3、表 4-4、表 4-5 列出。

 

3.数据关系模型(ER图)

许多应用软件系统往往需要通过数据库来存储数据。从结构上来看，数据库系统是独立于 软件系统之外的专门系统，因此，在系统建模过程中，数据库需要进行专门的分析与设计。其 中，需求分析时期建立的数据库模型称为概念模型。

数据关系模型图也称为 ER 图，是应用最广泛的数据库分析建模工具。数据关系建模方法 最早由 Chen 于 20 世纪 70 年代中期提出，它以现实数据为建模依据，通过从现实数据中抽取数据实体、数据关系和数据属性这三类图形元素，建立数据库的概念模型。

　　（1）数据实体

数据实体是对应用领域中现实对象的数据抽象。例如，课程教学中的教师、学生和课程这 三个现实对象，就可以作为数据实体对待。

　　（2）数据关系

数据关系是指不同数据实体之间存在的联系，包括：一对一、一对多、多对多三种类型的 关系。数据关系类型及其描述如表 4-6 所列。

　　（3）数据属性

数据属性是指在数据实体与数据关系上所具有的一些特征值。例如，教师的编号、姓名、 性别、职称、学历，是教师实体的属性；学生的学号、姓名、性别、专业、班级，是学生实体 的属性；课程的课号、课名、学分、计划课时量，是课程实体的属性。而学习的成绩，则是学 习关系的属性；讲授的实际课时量，则是讲授关系的属性。 在数据关系图中，数据实体用矩形表示，数据关系用菱形表示，数据属性用椭圆形表示。 其中，能够用来标记实体的关键属性则通过在属性名称上加下划线来表示。 图 4-11 是教师、学生、课程这三个实体之间存在的教学关系的数据关系图的描述。

对于一些比较复杂的数据关系，为了方便分析，在画数据关系图时可以只画出实体、关系和关键属性，而其一般属性则可以省略，例如图 4-12。

 

 

4.系统状态模型

（1）状态图特点

状态图于 1987 年由 Harel 首先提出，其使用状态、事件等图形符号来描述系统的行为活 动，用以反映系统因某个外部事件的干预而由一个可能的状态转换到另一个状态。表 4-7 所列 为状态模型图中一些常用的图形符号及其描述。

状态模型图是通过系统的内部状态、外部事件为基本元素来描绘系统的工作流程的，这种 建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。 另外，状态模型也被 UML 建模语言采纳。在面向对象建模之中，状态模型可以用来对对象 的状态及其变换进行细节描述。

 

（2）状态图应用举例

下面是一台全自动洗衣机的大致活动过程：

（1）在洗衣机接通电源以后，洗衣机将进入待命状态。

（2）在洗衣机进入待命状态以后，操作者可以选择“设置”或“工作”。若选择“设置”， 洗衣机将进入设置状态；若选择“工作”，洗衣机将进入工作状态。

（3）在洗衣机进入设置状态以后，操作者可以设置洗衣水位，洗衣机工作流程，并可在完 成设置之后选择“确定”返回待命状态。

（4）在洗衣机进入工作状态以后，洗衣机将按照设置的流程进行工作。若洗衣机在洗衣过 程中选择暂停，洗衣机将进入暂停等待状态；若洗衣机在洗衣过程中出现洗衣故障，洗衣机将 鸣报警音，并进入故障等待状态。在洗衣机完成流程规定的工作以后，洗衣机进入结束等待状态。
（5）在洗衣机进入暂停等待状态以后，操作者可选择“恢复”，使洗衣机返回工作状态。

（6）在洗衣机进入故障等待状态以后，操作者可在排除洗衣故障之后，选择“恢复” ， 使洗衣机返回工作状态。

（7）在洗衣机进入结束等待状态以后，操作者可以切断电源结束洗衣过程。 根据上述活动内容，可以画出该洗衣机的状态图模型。其状态图模型如图 4-13 所示。

 

 

需要注意的是，图 4-13 中的工作状态是一个复合状态。也就是说该状态中包含了子状态。 假如洗衣机的常规工作流程是：累积洗涤 10 分钟，然后进入漂洗状态；累积漂洗 6 分钟，然后 进入脱水状态；累积脱水 1 分钟，然后进入结束鸣音状态。则工作状态的下层子状态图如图 4-14 所示。
 

 

 

五、需求有效性验证

需求有效性验证是指对已经产生的需求结论所要进行的检查与评价，它是需求分析过程中 一个必不可少的环节。 需求分析是软件开发过程中一个非常关键的阶段。它是软件设计、实现的基础，同时也是用户对软件产品进行确认的基本依据。但是，需求分析过程中产生出来的结论难免存在问题。 例如，某项功能被遗漏了，某些功能之间发生了操作上的冲突，某些数据字节数不够大等。更 加重要的是，这些问题看起来或许并不显眼，但它所影响的是软件系统的整体构造。 实际情况往往是：需求分析中的小问题，假如是在后续的开发过程中或是在系统开发出来 并投入使用以后才被发现，就会导致代价巨大的返工。因此，在需求分析结果出来以后，需要 对其进行严格的有效性验证，由此尽早地发现需求文档草稿中存在的问题。

 

1.需求验证内容

在需求有效性验证过程中，为了确保软件需求的正确性，需要对需求文档草稿从有效性、 一致性、完整性、现实性等几个方面进行有效性验证。

（1）有效性验证

需求有效性验证用于确认每一项需求定义都能符合用户的实际需要。由于一个软件系统在 其运行过程中一般需要面对许多不同的用户，他们分别会有一些不同的个性需求意愿，因此， 有效性验证还包括对用户需求个性差异的协商。

（2） 一致性验证

一致性验证用于检查发现在需求文档中可能存在的需求冲突，例如，同一个功能出现了不 同的描述或存在相互矛盾的规程约束。

（3）完整性验证

完整性验证用于检查发现用户确实需要的，但没有写入需求文档中一些功能、约束等，以 使最终确定下来的需求文档能够更加完整的体现用户的需求意愿。

（4）现实性验证

现实性验证用于检查需求文档中所提出的功能、性能、安全等方面的需求，哪些还不能够 利用现有技术加以实现，以确保用户的一系列需求都能够具有现实意义，都能够最终实现。

（5）可检验性验证

可检验性验证用于判断需求文档中的各项需求是否有适合于用户操作的检测方法，可以使 得当系统开发完成并交付用户使用时，开发人员能设计出一组合适的检查方法来进行用户需求 检验，由此最大限度地保证用户的需求意愿能够得以实现。

 

2.需求验证方法

在进行需求有效性验证时，需要有一定的方法、工具提供支持。例如，需求评审、需求原 型评价和基于 CASE 工具的需求一致性分析等。

　　　　 1. 需求评审

需求评审是传统的需求检查手段，采用专门评审小组的方式实施对需求文档的有效性评 价。其评审工作的开展需要有开发人员、用户的共同参与，他们一同检查文档中的不规范之处 和遗漏之处，一起讨论需求中存在的问题，并需要对一些需求分歧进行协商。 需求评审可以是非正式的也可以是正式的。其中，非正式评审一般是在正式评审之前进行 的准备性工作。非正式评审往往由项目负责人召集，由尽可能多的项目相关人员一起参与讨论， 然后就诸多需求结论是否正确给出一个基本判断。 在非正式评审结果产生以后，接着需要进行正式的需求评审。这时，软件开发机构需要拿 着经过非正式评审的需求文档访问用户，逐条地向各个用户解释需求含义。 在正式评审过程中，软件评审小组一般需要针对以下问题进行专门的检查与评价：

　　　　（1）一致性：需求文档对需求的描述是否有不一致的地方？

　　　　（2）完整性：是否还有需要的但没有写到需求文档中的功能？

　　　   （3）可检验性：需求描述是否可实际测试？

              （4）可读性：需求描述能否被用户读懂？

   　　    （5）可跟踪性：是否清晰地记录了需求的出处？ 

 　　　  （6）可调节性：需求是可调节的吗？假如需求出现变更，能否不对系统带来太大的影响？

　　　　2. 需求原型评价

本章 4.3.3 节主要说明了如何使用需求原型完善用户的需求，但在这个过程中也包括对用 户需求的有效性验证。例如，可以根据需求文档为用户创建一个可以运行的系统模型，使用户 通过模型进行更加接近实际的系统需求检验。 需求原型主要用来提供给用户评价，以方便用户进行需求确认。为了使需求原型评价更加 有效，分析人员有必要从不同方面对用户评价作些引导。例如，为了启发用户的评价行为，可 以针对界面原型提出以下问题：

　　　　（1）界面所显示的功能是你所期望的吗？

　　　　（2）有遗漏的功能吗？

　　　   （3）有多余的功能吗？

         　 （4）你感觉界面复杂吗？

需求原型评价还有利于发现用户的一些潜在需求。因此，在通过原型进行需求验证的时候， 除了需要从用户对原型的评价中确认用户的想法之外，还有必要观察用户对原型的操作，以此 发现用户所需要的而未能表达出来的需求。 用于需求评价的原型一般是抛弃型原型，当需求被确定之后，原型会被抛弃。这种原型能 够快速创建，容易修改，可以加快需求工程速度，降低需求成本。 需求原型也可以是进化型原型，特别是当开发者在需求原型上花费时间太多的时候，就自 然会产生出要把原型进化为目标系统的想法。若要使需求原型能够进化则一般需要满足以下两 个条件：

其一：原型创建工具和目标系统创建工具应该尽量一致，以方便从原型到目标系统的无缝 过渡。例如，使用 Microsoft Visual Basic、Inprise Delphi 等基于组件的可视化开发工具作 为原型创建工具。

其二：原型创建时必须考虑到软件的健壮性、可靠性、可维护性，以及工作性能等技术性 要素，以保证原型质量标准和目标系统质量标准是一致的。 以上条件意味着，要使原型能够进化，开发者就要在原型创建时投入更多的时间、精力。 显然这就不得不增大原型创建费用。一般来讲，项目越小则原型进化的价值也就越大。

 

　　　　3. 基于 CASE 工具的需求一致性分析

如果需求文档中的需求元素是用结构化或形式化语言描述的，则可以使用需求 CASE 工具 来进行需求一致性分析。 需求 CASE 工具的工作流程如图 4-15 所示。其中，需求处理器用于处理使用形式化语言描 述的需求，并将产生的需求结果存入需求数据库中。以后，需求分析器可以使用方法规则或符 号规则对需求数据库中的需求结果进行一致性检查，并能够根据检查结论产生出关于需求一致性的分析报告。

 

六、需求规格定义

需求规格说明书是需求分析阶段需要交付的基本文档，涉及引言、术语定义、用户需求、 系统体系结构、系统需求等有关软件需求及其规格的诸多描述与定义。应该说，有关软件系统 的一系列需求结论都需要以正式文档的形式写进这份文档之中。 需求规格说明书将成为开发者进行软件设计和用户进行软件验证的基本依据，其作用是使 软件用户和软件开发者双方在软件正式开发之前能够对需要开发的软件有一个共同认可的规格 定义。 需求规格说明书具有里程碑的意义，涉及比较广泛的读者群。几乎所有与软件项目有关的 人员，包括用户、项目管理人员、系统开发人员、系统测试人员和系统维护人员等，都需要阅 读这份文档，并或多或少地受到它的一定范围与程度的约束。

•  软件用户：提出需求，按照需求规格说明书对软件系统进行验收。

•  项目管理人员：根据需求规格说明书制定项目详细开发计划，安排项目进程。

•  系统开发人员：以需求规格说明书为依据进行系统设计与实现。

•  系统测试人员：以需求规格说明书为依据进行系统有效性测试。

•  系统维护人员：通过需求规格说明书来帮助对系统功能与构造的认识。

 

小结:

1. 需求分析任务

（1）用户需求 用户需求是用户关于软件的一系列意图、想法的集中体现，是用户关于软件的外界特征的 规格表述。

（2）系统需求 系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅 读的，并将作为软件开发人员设计系统的起点与基本依据。主要包括：功能、数据、性能、安 全等诸多方面的需求问题。

2. 需求分析过程
需求分析是对软件系统的后期分析，需要进行的活动包括：分析用户需求、建立需求原型、 分析系统需求和进行需求验证等。

 

3. 用户需求获取

（1）用户调查是最基本的用户需求信息收集方法，比较常用的调查方法包括：访谈用户、 开座谈会、问卷调查、 跟班作业、收集用户资料。

（2）需求原型可被用来解决用户对软件系统在需求认识上的不确定性。一般情况下，开发 人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。例如，界面、报表或 数据查询结果。

4. 结构化分析建模

所谓模型，就是对问题所做的一种符号抽象。可以把模型看作为一种思维工具，利用这种 工具可以把问题规范地表示出来。主要的分析模型包括：

（1）功能层次模型。它使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来 表达系统所具有的功能层级关系。

（2）数据流模型。用于描述系统对数据的加工过程，其图形符号是一些具有抽象意义的逻 辑符号，主要的图形符号包括：数据接口、数据流、数据存储和数据处理。可以依靠数据流图 来实现从用户需求到系统需求的过渡。结构化分析就是基于数据流的细化实现的，它是结构化 分析方法的关键。

（3）数据关系模型。也称为 ER 图，是应用最广泛的数据库建模工具。需要通过数据实体、 数据关系和数据属性这三类图形元素建立数据关系模型。

（4） 系统状态模型。通过系统的外部事件、内部状态为基本元素来描绘系统的工作流程， 这种建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。

5. 需求有效性验证

需求有效性验证是指对已经产生的需求结论所要进行的检查与评价。 一般需要对需求文档草稿从有效性、一致性、完整性、现实性等几个方面进行有效性验证。 比较常用的需求有效性验证方法与工具包括：需求评审、需求原型评价和基于 CASE 工具的需求 一致性分析。

6. 需求规格定义

需求规格说明书是需求分析阶段需要交付的基本文档，将成为开发者进行软件设计和用户 进行软件验证的基本依据，涉及引言、术语定义、用户需求、系统体系结构、系统需求等有关 软件需求及其规格的诸多描述与定义。