第三章 需求分析

第三章 需求分析

软件需求是指用户对所开发的软件在功能、性能、环境、可靠性等各方面的要求

需求分析主要回答待开发的系统必须做什么，并用需求规格说明书的形式准确、详细、规范地表达出来

需求分析的方法，都应遵守下述准则：

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

注意关注：数据模型、功能模型、行为模型

3.1 需求分析的任务

基于计算机的系统的系统元素：包括硬件、软件、人、数据库、文档和过程。

软件开发是要实现目标系统的物理模型。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统做什么的问题

需求分析的任务就是对目标系统提出完整、准确、清晰、具体的要求。

四项主要任务：

1. 确定对系统的综合要求
2. 分析系统的数据要求
3. 导出系统的逻辑模型
4. 修正系统开发计划

功能需求：指定系统必须提供的服务

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

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

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

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

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

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

将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，对系统将来可能的扩充和修改预做准备。

3.1.2 分析系统的数据要求

软件系统本质上是信息处理系统，要考虑数据和数据处理的问题。

1. 建立数据模型
2. 描绘数据结构
3. 数据结构规范化

3.1.3 导出系统的逻辑模型

导出系统的详细的逻辑模型

描述逻辑模型的工具通常有：

• 数据流图
• 实体-联系（E-R）图
• 状态转换图
• 数据字典和

3.1.4 修正系统开发计划

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

3.2 与用户沟通获取需求的方法

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

3.2.2 面向数据流自顶向下求精

软件系统的基本功能都是把输入数据转变成需要的输出信息。数据显然是需求分析的出发点。需求分析的目标之一就是把数据流和数据存储定义到元素级

结构化分析方法的实质：自顶向下逐步求精。进一步细化可行性研究阶段获得的高层数据流图。包括建立：

• 详细的数据流图
• 数据字典
• 实体关系（E-R）图
• IPO图

3.2.4 快速建立软件原型

要点：实现用户看得见的功能，珄略目标系统隐含的功能。

快速原型化方法：

优点：

1. 可以增进软件开发者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。
2. 可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。
3. 有的原型可以直接成为产品，有的略加修改就可成为最终系统的一个组成部分。

原型分类：

1. 探索型：目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。
2. 实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。
3. 进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统

原型开发主要分类：

1. 进化式原型开发

基本思路是：先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统。

2. 抛弃式原型开发

基本思路是：原型的根本作用是弄清楚需求和为风险评估提供补充信息。通过评估后，原型被抛弃，重新规划和实施系统的开发。

3.3 分析建模与规格说明

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

模型通常由一组图形符号和组织这些符号的规则组成。

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

• 实体练习图，描述数据对象及数据对象之间的关系，适用于建立数据模型的图形。
• 数据流图是建立功能模型的基础
• 状态转换图描绘了系统的各种行为模式和在不同状态间转换的方式。状态转换图是行为建模的基础

结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。

扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体-关系图、数据流图和控制流图、状态-迁移图为工具，数据字典为核心，从不同视点建立系统的分析模型。

3.3.3 软件需求规格说明

软件需求规格说明是需求分析阶段得出的最主要的文档。

通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。

3.4 实体联系图

数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。

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

数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。总之，可以由一组属性来定义的实体都可以被认为是数据对象。

3.5 数据规范化

软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

通常用“范式”定义消除数据冗余的程度。

3.6 状态转换图

为了直观地分析系统的动作，从特定的视点出发描述系统的行为，需要采用动态分析的方法。

状态转换图是一种常用的动态分析方法。它是描述系统的状态如何响应外部信号，而进行转换的一种图形表示。

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

3.6.1 状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的相应方式。

状态主要有：初态（即初始状态）、终态（即最终状态）和中间状态。

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

3.6.2 事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。

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

3.6.3 符号

在状态图中，初态用实心圆表示，终态用一对同心圆（内圆为实心圆）表示。

中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。

上面部分为状态的名称，这部分是必须有的；

中间部分为状态变量的名字和值，这部分是可选的；

下面部分是活动表，这部分也是可选的。

活动表的语法格式如下：

时间名（参数表）/动作表达式。其中，“事件名”可以是任何事件的名称。

在活动表中经常使用下述3种标准事件：entry，exit和do。

entry事件指定进入该状态的动作

exit事件指定退出该状态的动作

do事件指定在该状态下的动作

状态图种两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。

事件表达式的语法如下：

事件说明[守卫条件]/动作表达式

其中，事件说明的语法为：事件名（参数表）

3.7.1 层次方框图

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

3.7.2 Warnier图

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