195.需求分析

第3章  需求分析

   

• 基本任务是准确地回答：“系统必须作什么?” 。

       对目标系统提出完整、准确、清晰、具体的要求。

• 系统分析员应该写出软件需求规格说明书。

 

需求分析应遵照下述准则：

 

(1) 必须理解并描述问题的信息域，创建数据模型。

(2) 必须定义软件应完成的功能，创建功能模型。

(3) 必须描述做为外部事件结果的软件行为，创建行为模型。

(4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展现细节。

 

3.1  需求分析的任务

 3.1.1  肯定对系统的综合要求

1. 功能需求

    指定系统必须提供的服务，划分出系统必须完成的全部功能。

2. 性能需求

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

3. 可靠性和可用性需求

4. 出错处理需求

    当应用系统发现它本身犯下一个错误时所采起的行动。可是，仅限于对系统的关键部分有选择地提出这类出错处理需求。

5. 接口需求

    描述应用系统与它的环境通讯的格式。 

    常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通讯接口需求。

6. 约束

    描述在设计或实现应用系统时应遵照的限制条件。

    常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。

7. 逆向需求

    说明软件系统不该该作什么。

    用于澄清真实需求，消除可能发生的误解的那些逆向需求。

8. 未来可能提出的要求

    对系统未来可能的扩充和修改预作准备。

 

3.1.2  分析系统的数据要求

这是软件需求分析的一个重要任务。

    一般采用创建数据模型的方法(ER图)。

表示方法：

    数据结构（表示数据元素之间的逻辑关系）

    数据字典（不够形象直观）

    层次方框图和Warnier图（3.7节介绍）

存储方式：

    数据库或文件。

 

3.1.3  导出系统的逻辑模型

• 综合上述两个步骤的结果导出系统的逻辑模型

• 用如下工具描述

    数据流图

    实体联系图

    状态转换图

    数据字典

    主要的处理算法

 

3.1.4  修正系统开发计划

•修正可行性分析中制定的开发计划

•估计比较准确的系统成本和进度

 

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

3.2.1 访谈

• 正式

• 非正式

• 调查表

• 情景分析技术

 

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

    结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

• 可行性研究得出的是目标系统的高层数据流图

• 需求分析的目标之一就是把数据流和数据存储定义到元素级。

•  从数据流图的输出端着手分析，输出数据决定了系统必须具备的最基本的组成元素。

　　输出数据组成元素经过调查访问不难搞清。

       每一个输出数据元素又是从哪里来的呢?

       或者是从外面输入到系统中来，或者是经过计算由系统中产生出来的。

• 从输出端往输入端回溯，可肯定每一个数据元素的来源，及有关的算法。

    可是，高层数据流图中许多细节没有包括，所以回溯时经常遇到下述问题：

         某个数据元素须要用到数据流图中目前尚未的数据元素，

         或者得出这个数据元素须要用的算法尚不彻底清楚。

• 数据元素纳入数据字典

• 算法记录在IPO图中

• 增补数据流图

• 请用户复查

    复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。

• 追踪更详细的数据流，把数据流图扩展到更低的层次。经过功能分解完成数据流图的细化。

    在分析追踪时可能产生新的问题，这些问题的答案可能又在数据字典中增长一些新条目，或产生新的或精化的算法描述。

    最终获得对系统数据和功能要求的满意了解。

   下页图3.1粗略地归纳了上述分析过程。

 

 

图3.1 面向数据流自顶向下求精过程

 

3.2.3  简易的应用规格说明技术

    为了解决上述问题，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。

    这种方法提倡用户与开发者密切合做，商讨不一样方案并指定基本需求。

•初步访谈，肯定问题和解决方案

•开发者和用户分别写“产品需求”

•开会前，将“产品需求”分发

•每一个人审查“产品需求”，列出系统对象

•开会，合并对象（消去冗余），获得意见一致的列表

•分小组讨论，制定小型规格说明

•综合讨论，起草软件规格说明书

 

3.2.4  快速创建软件原型

•快速原型就是快速创建起来的旨在演示目标系统主要功能的可运行的程序。其特性：

      快速

      容易修改

•为了快速地构建和修改原型，一般使用下述3种方法和工具：

    第四代技术（使得软件工程师可以快速地生成可执行的代码，是较理想的快速原型工具）

    可重用的软件构件（使用一组已有的软件构件来装配原型）

    形式化规格说明和原型环境（调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码）

 

3.3  分析建模与规格说明  

3.3.1  分析建模

    为了更好地理解复琐事物，人们经常采用创建事物模型的方法。

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

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

 

    根据结构化分析准则，需求分析过程应该创建3种模型，它们分别是数据模型、功能模型和行为模型。

数据模型

实体－联系图，描绘数据对象及数据对象之间的关系，用于创建数据模型。

功能模型

数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具备变化数据的功能，是创建功能模型的基础。

行为模型

3.6节状态转换图（状态图），指明做为外部事件结果的系统行为。描绘了系统的各类行为模式(称为“状态”)和在不一样状态间转换的方式。是行为建模的基础。

 

3.3.2  软件需求规格说明

    是需求分析阶段得出的最主要的文档。

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

•  天然语言的规格说明具备容易书写、容易理解的优势，为大多数人所欢迎和采用。

 

 3.4 实体——联系图

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

3.4.1 数据对象

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

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

3.4.2 属性

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

3.4.3 联系

客观世界中的事物彼此间每每是有联系的。
数据对象彼此之间相互链接的方式称为联系，也称为关系。联系可分为如下3种类型。

一对一联系(1∶1)
一对多联系(1∶N)
多对多联系(M∶N)

(1) 一对一联系(1∶1)
例如，一个部门有一个经理，而每一个经理只在一个部门任职，则部门与经理的联系是一对一的。
(2) 一对多联系(1∶N)
例如，某校教师与课程之间存在一对多的联系“教”，即每位教师能够教多门课程，可是每门课程只能由一位教师来教(见图3.2)。
(3) 多对多联系(M∶N)
例如，图3.2表示学生与课程间的联系(“学”)是多对多的，即一个学生能够学多门课程，而每门课程能够有多个学生来学。

 

 

 

3.4.四、实体联系图的符号

一般，使用实体联系图(entityrelationship diagram)来创建数据模型。能够把实体联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。

ER图中包含了实体(即数据对象)、关系和属性3种基本成分，一般用矩形框表明实体，用链接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性链接起来。

ER模型能够做为用户与分析员之间有效的交流工具。

 

 

 3.5  数据规范化

 

    软件系统常用的各类长期保存的信息，一般以必定方式组织并存储在数据库或文件中，为减小数据冗余，避免出现插入异常或删除异常，一般须要把数据结构规范化。

3.6  状态转换图

    用于创建软件系统的行为模型。

    经过描绘系统的状态及引发系统状态转换的事件，来表示系统的行为。

    此外，还指明了做为特定事件的结果系统将作哪些动做(例如，处理数据)。

    所以，状态图提供了行为建模机制。

3.6.1  状态

状态：

    是任何能够被观察到的系统行为模式，一个状态表明系统的一种行为模式。

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

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

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

    当描绘单程生命期时，须要标明

        初始状态(系统启动时进入初始状态)和

        最终状态(系统运行结束时到达最终状态)。

     描绘循环运行过程时没必要。

3.6.2  事件

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

    例如，内部时钟代表某个规定的时间段已通过去，用户移动或点击鼠标等都是事件。

    简而言之，事件就是引发系统作动做或(和)转换状态的控制信息。

3.6.3  符号

初态用实心圆表示，

终态用一对同心圆(内圆为实心圆)表示。

中间状态用圆角矩形表示，

    能够用两条水平横线把它分红上、中、下3个部分。

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

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

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

 

 

 

活动表的语法格式：事件名(参数表)/动做表达式

• “事件名”能够是任何事件的名称。

    常用下述3种标准事件：entry，exit和do。

        entry指定进入该状态的动做，

        exit指定退出该状态的动做，

        do指定在该状态下的动做。

• 须要时能够为事件指定参数表。

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

• 两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。

   状态变迁一般是由事件触发的，在状态转换的箭头线上标出触发转换的事件表达式；若是在箭头线上未标明事件，则表示在源状态的内部活动执行完以后自动触发转换。

 

事件表达式的语法以下：

事件说明［守卫条件］／动做表达式

• 事件说明的语法为：事件名(参数表)。

• 守卫条件是一个布尔表达式。

    若是同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。

    若是只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。

• 动做表达式是一个过程表达式，当状态转换开始时执行该表达式。

3.6.4  例子

图3.4（见书57页）

    没有人打电话时电话处于闲置状态；

    有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；

    这时若是拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态；

    若是拿起听筒很长时间不拨号(超时)，则进入超时状态；……。

 

 

3.7  其余图形工具  

3.7.1  层次方框图

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

    树形结构顶层的矩形框，表明完整的数据结构，

    下面的各层矩形框表明这个数据的子集，

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

    例如，描绘一家计算机公司所有产品的数据结构能够用图3.5中的层次方框图表示。

 

 

 

图3.5 层次方框图的一个例子

 

 3.7.1  层次方框图

 

 

    从对顶层信息的分类开始，沿图中每条路径反复细化，直到肯定了数据结构的所有细节时为止。

3.7.2  Warnier图

    表示信息层次结构的另一种图形工具。

    但这种图形工具比层次方框图提供了更丰富的描绘手段。

用Warnier图能够代表信息的逻辑组织，

    它能够指出一类信息或一个信息元素是重复出现的，

    也能够表示特定信息在某一类信息中是有条件地出现的。

 

 图3.6中的Warnier图表示

    一种软件产品要么是系统软件要么是应用软件。

    系统软件中有P1种操做系统，P2种编译程序，此外还有软件工具。

    软件工具是系统软件的一种，它又能够进一步细分为编辑程序、测试驱动程序和设计辅助工具，并标出了每种软件工具的数量。

 

 

图3.6 Warnier图的一个例子

3.7.3  IPO图

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

    IPO图使用的基本符号既少又简单，所以很容易学会使用这种图形工具。

    在左边的框中列出有关的输入数据，

    在中间的框内列出主要的处理，

    在右边的框内列出产生的输出数据。

    处理框中列出处理的次序暗示了执行的顺序。

    在IPO图中还用粗大箭头指出数据通讯的状况。

   

图3.7是一个主文件更新的例子，经过这个例子不难了解IPO图的用法。

 

 

 

图3.7 IPO图的一个例子图

    建议使用一种改进的IPO图(也称为IPO表)，图中包含某些附加的信息，比原始的IPO图更有用。如图3.8所示。

    在需求分析阶段可使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。

   当许多附加信息暂时还不具有时，在软件设计阶段能够进一步补充修正这些图，做为设计阶段的文档。

    这正是在需求分析阶段用IPO图做为描述算法的工具的重要优势。

 

 

图3.8 改进的IPO图的形式

3.8  验证软件需求  

3.8.1  从哪些方面验证软件需求的正确性

    软件系统中15%的错误起源于错误的需求。

通常说来，应该从下述4个方面进行验证：

(1) 一致性：全部需求必须是一致的，任何一条需求不能和其余需求互相矛盾。

(2) 完整性：需求必须是完整的，规格说明书应该包括用户须要的每个功能或性能。

(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上能够实现的。

(4) 有效性：必须证实需求是正确有效的，确实能解决用户面对的问题。

3.8.2  验证软件需求的方法

1. 验证需求的一致性

•人工审查（正确性不能保证）

•形式化描述软件需求的方法：当软件需求规格说明书是用形式化的需求陈述语言书写时，能够用软件工具验证需求的一致性。

2. 验证需求的现实性

• 经验

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

3. 验证需求的完整性和有效性

• 用户是需求的权威，可是不能很好表达本身的需求

• 根据需求开发一个软件系统，用户试用，成本翻倍

• 创建快速原型系统，使用户提出更符合实际的要求

 

3.8.3  用于需求分析的软件工具

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

这类软件工具应该知足下列要求：

(1) 必须有形式化的语法(或表)，使能够用计算机自动处理使用这种语法说明的内容；

(2) 使用这个软件工具可以导出详细的文档；

(3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，而且应该可以产生一组报告指明对完整性分析的结果；

(4) 使用这个软件工具以后，应该可以改进通讯情况。