这一章节非常重要！！！
尤其是里面的E-R图、数据流图，状态装换图的画法，非常的重要！！！

• 第3章 需求分析
• 3.1 需求分析的任务
• 3.1.1 确定对系统的综合要求
• ① 功能需求
• ② 性能需求
• ③ 可靠性和可用性需求
• ④ 出错处理需求
• ⑤ 接口需求
• ⑥ 约束
• ⑦ 逆向需求
• ⑧ 将来可能提出的要求
• 3.1.2 分析系统的数据要求
• 3.1.3 导出系统的逻辑模型
• 3.1.4 修正系统开发计划
• 3.2 与用户沟通获取需求的方法
• 3.2.1 访谈
• 3.2.2 面向数据流自顶向下求精
• 3.2.3 简易的应用规格说明技术
• 3.2.4 快速建立软件原型
• 3.3 分析建模与规格说明
• 3.3.1 分析建模
• 3.3.2 软件需求规格说明
• 3.4 实体联系图（☆☆☆☆☆）
• 3.4.1 数据对象
• 3.4.2 属性
• 3.4.3 联系
• 3.4.4 实体-联系图的符号
• 3.4.5 实例1
• 3.4.6 实例2
• 3.5 数据流图（☆☆☆☆☆）
• 3.5.1 符号
• 3.5.2 实例
• 步骤一：从问题描述中提取数据流图的4种成分
• 步骤二：着手画数据流图的基本系统模型
• 步骤三：把基本系统模型细化，描绘系统主要功能
• 步骤四：主要功能进一步细化
• 3.5.3 命名
• 3.6 状态转换图（☆☆☆☆☆）
• 3.6.1 状态
• 3.6.2 事件和行为
• 3.6.3 符号
• 3.6.4 例子
• 3.7 数据字典（☆☆☆☆☆）
• 3.7.1 数据字典的内容
• ① 数据流的描述
• ② 数据元素的描述
• ③ 数据存储的描述
• ④ 处理的描述
• 3.7.2 数据字典的定义方法
• 3.7.3 数据字典的用途
• 3.7.4 数据字典的实现
• 3.8 其他图形工具
• 3.8.1 层次方框图
• 3.8.2 Warnier图
• 3.8.3 IPO图
• 3.9 验证软件需求
• 3.9.1 从哪些方面验证软件需求的正确性
• 3.9.2 验证软件需求的方法
• 3.9.3 用于需求分析的软件工具

第3章 需求分析

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

需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么” 这个问题。

需求分析的任务是还不是决定系统怎样完成它的工作，仅仅是确定系统必须完成哪些工作。

需求分析的四个准则：

1. 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。
2. 必须定义软件应完成的功能，这条准则要求建立功能模型。
3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。
4. 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求。通常对软件系统有下述几方面的综合要求。

• 功能需求
• 性能需求
• 可靠性和可用性需求
• 出错处理需求
• 接口需求
• 约束
• 逆向需求
• 将来可能提出的要求

① 功能需求

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

② 性能需求

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

③ 可靠性和可用性需求

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

④ 出错处理需求

这类需求说明系统对环境错误应该怎样响应。
例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么？

⑤ 接口需求

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

⑥ 约束

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

⑦ 逆向需求

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

⑧ 将来可能提出的要求

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

任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响。
因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。
利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。
为了提高可理解性，常常利用图形工具辅助描绘数据结构。
常用的图形工具有层次方框图、Warnier图。

综合上述两项分析的结果可以导出系统的详细的逻辑模型。
通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。

• 正式访谈时，系统分析员将提出一些事先准备好的具体问题。
  例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等。
• 在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题， 以鼓励被访问人员说出自己的想法。
  例如，询问用户对目前正在使用的系统有哪些不满意的地方。

当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。

在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

情景分析技术的用处主要体现在下述两个方面。

• （1）它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。
• （2）由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。

结构化分析方法的实质：
面向数据流自顶向下逐步求精进行需求分析的方法。
通过可行性研究已经得出了目标系统的高层数据流图。

数据流图是帮助复查的极好工具，从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。
这些解释集中反映了通过前面的分析工作分析员所获得的对目标系统的认识。

随着分析过程的进展，经过提问和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。

简易的应用规格说明技术是为了解决使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。
由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想，经常发生误解、还可能遗漏重要信息。
为解决上述问题，提出面向团队的需求收集发；
面向团队的需求收集法，称为简易的应用规格说明技术。
提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。

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

1. 进行初步的访谈
2. 开发者和用户分别写出“产品需求”。
3. 开会讨论，各自展示需求列表
4. 得出了意见一致，为需求列表制定小型规格说明
5. 根据会议结果，起草完整的软件需求规格说明

快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序，快速原型应该具备的特性：

• 快速原型应该具备的第一个特性是“快速”。
• 快速原型应该具备的第二个特性是“容易修改”。

为了快速地构建和修改原型，通常使用下述3种方法和工具。

1. 第四代技术
   包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。
2. 可重用的软件构件
   使用一组已有的软件构件来装配原型。
3. 形式化规格说明和原型环境
   人们已经研究出许多形式化规格说明语言和工具（第4章），用于替代自然语言规格说明技术。用户能够使用可执行的原型代码去进一步精化形式化的规格说明。

模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。

为了开发复杂的系统，应从不同角度（模型）抽象出目标系统的特性（数据模型、功能模型、行为模型）

尽管目前有许多不同的用于需求分析的结构化分析方法，但是，所有这些分析方法都遵守4条准则。

1. 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。
2. 必须定义软件应完成的功能，这条准则要求建立功能模型。
3. 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型
4. 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
自然语言的规格说明具有容易书写、容易理解的优点，为大多数人欢迎和采用。

使用实体-联系图建立数据模型；
实体-联系图简称E-R图(Entity Relationship Diagram)，
ER图描绘的数据模型称为ER模型。

数据模型中包含3种相互关联的信息：

• 实体（数据对象）
• 数据对象的属性
• 数据对象彼此间相互连接的关系。

数据对象是对软件必须理解的复合信息的抽象。

数据对象可以是外部实体（例如产生或使用信息的任何事物）、事物（例如报表）、行为（例如打电话）、事件（例如响警报）、角色（例如教师、学生）、单位（例如会计科）、地点（例如仓库）或结构（例如文件）等。

总之，可以由一组属性来定义的实体都可以被认为是数据对象。

属性定义了数据对象的性质。
必须把一个或多个属性定义为“标识符”，也就是说，当人们希望找到数据对象的一个实例时，用标识符属性作为“关键字”(通常简称为“键”)。

数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
数据流图建立软件系统的功能模型。
在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具。

数据流图的4种基本符号：

• 正方形表示数据的源点或终点：人员、部门、计算机外部设备或传感器装置
• 圆角矩形代表变换数据的处理：.系列程序、单个程序或程序-一个模块;人工处理过程。
• 开口矩形代表数据存储：文件、文件一部分、数据库元素或记录一部分，可存在磁盘、磁带、磁鼓、主存、微缩胶片任何介质上。
• 箭头表示数据流，即特定数据的流动方向：在处理之间有向流动的数据项或数据集合。

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

1. 从问题描述中提取数据流图的4种成分
   从上面对系统的描述可以知道“采购部每天需要一张订货报表”。
   “通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。

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

3. 第三步：考虑数据流和数据存储
   系统把订货报表送给采购部，因此订货报表是一个数据流，事务需要从仓库送到系统中，显然事务是另一个数据流。
   产生报表和处理事务这两个处理在时间上明显不匹配——每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。
   因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储。

步骤一：从问题描述中提取数据流图的4种成分

分析结果：
源点：仓库管理员
终点：采购员
处理：处理事务、产生报表等
数据流：事务、订货信息、订货报表等
数据存储：订货信息、库存信息

步骤二：着手画数据流图的基本系统模型

步骤三：把基本系统模型细化，描绘系统主要功能

步骤四：主要功能进一步细化

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

数据流命名时应注意的问题

1. 名字应代表整个数据流的内容，而不是仅仅反映它的某些成分
2. 不要使用空洞的、缺乏具体含义的名字
3. 在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解

为“处理”命名时应注意的问题

1. 通常先为数据流命名，然后再为与之相关联的处理命名。
2. 名字应该反映整个处理的功能，而不是它的一部分功能。
3. 名字最好由一个具体的及物动词加上一个具体的宾语组成。
4. 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。
5. 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。

状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。
此外，状态图还指明了作为特定事件的结果系统将做哪些动作。
因此，状态图建立软件系统的行为模型。

软件行为模型：状态、事件、行为。

状态是任何可以被观察到的系统行为模式。

在状态图中定义的状态主要有：

• 初态(即初始状态)
• 终态(即最终状态)
• 中间状态。

在一张状态图中只能有一个初态，而终态则可以有0至多个。

状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。

事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。
例： 用户移动鼠标或单击鼠标等都是事件。

事件就是引起系统做动作或(和)转换状态的控制信息。

行为：进入某状态后所作动作

在状态图中，

• 初态用实心圆表示，
• 终态用一对同心圆(内圆为实心圆)表示。
• 中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。
  上面部分为状态的名称，这部分是必须有的；
  中间部分为状态变量的名字和值，这部分是可选的；
  下面部分是活动表，这部分也是可选的。

活动表的语法格式如下：
事件名(参数表)/动作表达式
“事件名”可以是任何事件的名称。
在活动表中经常使用下述3种标准事件：entry，exit和do。

• entry事件：指定进入该状态的动作，
• exit事件：指定退出该状态的动作，
• do事件：指定在该状态下的动作。需要时可以为事件指定参数表。

活动表中的动作表达式描述应做的具体动作。

状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。
状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；
如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
事件表达式的语法如下：
事件说明[守卫条件]/动作表达式
事件说明的语法为：事件名(参数表)。

为了具体说明怎样用状态图建立系统的行为模型，下面举一个例子。

概念：
数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合，半形式化方法表达。

数据字典的作用是在软件分析和设计的过程中给人提供关于数据的描述信息。

① 数据流的描述

② 数据元素的描述

③ 数据存储的描述

④ 处理的描述

定义数据字典的方法：对数据自顶向下分解。

4种由数据元素组成的数据的方式：

1. 顺序：即以确定次序连接两个或多个分量。
2. 选择：即从两个或多个可能的元素中选取一个。
3. 重复：即把指定的分量重复零次或多次。
4. 可选：一个分量是可有可无的（重复零次或一次）

举例2：
某程序设计语言规定，用户说明的标识符是长度不超过8个字符的字符串，其中，第一个字符必须是字母字符，最后的字符既可以是字母字符也可以是数字字符。
标识符=字母字符+字母数字串
字母数字串=0{字母或数字}7
字母或数字=[字母字符|数字字符]

数据字典最重要的用途是作为分析阶段的工具。
数据字典中包含的每个数据元素的控制信息是很有价值的。
数据字典是开发数据库的第一步，而且是很有价值的一步。

在开发大型软件系统的过程中，数据字典的规模和复杂程度迅速增加，人工维护数据字典几乎是不可能的。

在开发小型软件系统时暂时没有数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据的信息。
下面给出第2.4节的例子中几个数据元素的数据字典卡片，以具体说明数据字典卡片中上述几项内容的含义。

描述复杂的事物时，图形远比文字叙述优越得多，它形象直观容易理解。
（1）用于建立功能模型的数据流图；
（2）用于建立数据模型的实体-联系图；
（3）用于建立行为模型的状态图。
本节再简要地介绍在需求分析阶段可能用到的另外3种图形工具。

IPO图是输入、处理、输出图的简称，它是由美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

它的基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。用粗大箭头清楚地指出数据通信的情况。

需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。
为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。
一般说来，应该从下述4个方面进行验证。
（1）一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
（2）完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
（3）现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
（4）有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。

至少必须从一致性、完整性、现实性和有效性这4个不同角度验证软件需求的正确性。
那么，怎样验证软件需求的正确性呢?验证的角度不同，验证的方法也不同。

1. 验证需求的一致性
   当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。
   但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。
   为了克服上述困难，人们提出了形式化的描述软件需求的方法。

2. 验证需求的现实性
   为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。
   必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。

3. 验证需求的完整性和有效性
   只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。
   使用原型系统是一个比较现实的方法，用户通过试用原型系统，能获得许多宝贵的经验，从而可以提出更符合实际的要求。

为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。

（1）必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容。
（2）使用这个软件工具能够导出详细的文档。
（3）必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果。
（4）使用这个软件工具之后，应该能够改进通信状况。

1977年美国密执安大学开发了PSL/PSA（问题陈述语言/问题陈述分析程序）系统。
这个系统是CADSAT（计算机辅助设计和规格说明分析工具）的一部分。其中PSL是用来描述系统的形式语言，PSA是处理PSL描述的分析程序。

PSL/PSA系统的功能主要有下述4种。
（1）描述任何应用领域的信息系统。
（2）创建一个数据库保存对该信息系统的描述符。
（3）对描述符施加增加、删除和更改等操作。
（4）产生格式化的文档和关于规格说明书的各种分析报告。