第三章需求分析

需求分析的任务

综合需求(由整体)

系统的综合需求分为功能需求、性能需求、可靠性可用性需求、出错处理需求、接口需求、约束、逆向需求、将来可能的需求。

功能需求

指系统必须提供的服务,应该包含所有系统必须完成的功能,

性能需求

指系统必须满足的时间与空间上的约束,通常包含响应时间、存储容量、安全性等。

可靠性与可用性需求

指定量的指定系统的可靠性。(例如系统在一定时间内的出错概率和可用时间)

出错处理需求

指系统对于环境错误应该如何响应。(例如收到一条格式不符的信息)(外部的错误)

接口需求

接口需求描述系统与它的环境通信的格式。

(常见的有:用户接口需求,硬件接口需求,软件接口需求,通信接口需求)

接口是什么?
这里的接口就类似于类的接口一样,我要完成这个任务,
我需要别人提供哪些信息?我需要提供给别人哪些信息?

约束

约束是系统在设计时应该遵守的限制条件。

(常见约束:精度,工具和语言的约束,设计约束,应该使用的标准,应该使用的硬件平台)

逆向需求

系统不应该做什么

将来可能提出的需求

现阶段系统不需要实现,但是以后可能扩充的功能

数据需求(到局部)

建立数据模型(E-R图)

数据元素可通过数据字典表示,但不够直观,因此为了提高可理解性,常常利用图形工具辅助描绘。(层次方框图和warnier图)

导出系统的逻辑模型(到输出)

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

修正系统开发计划(到反馈)

前期的需求分析获得了对于系统更深层次的了解,可比较准确的估计系统的开发成本和进度,修正原来的开发计划。

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

1.访谈

书面回答也算访谈,而且由于书面回答经过考虑,效果会更好,调查的范围也能更广。

可使用情景分析法:

即给用户举个例子,让用户发现问题,明确客户的具体需求。

好处:

1.便于客户理解,可让分析员发现一些目前不知道的需求

2.提高客户在需求分析时的积极性

非正式访谈

随便扯皮,了解需求

正式访谈

直接询问,我们系统应该做成什么样子

2.面向数据流自顶向下求精

其实就是分冶法

在前面的可行性研究中,我们已经得到了目标系统较为高层的数据流图,现在要做的,就是把原先那些数据流进行再细化、再分解。

一般从数据流图的输出端开始分析(原因:系统的功能就是产生这些输出,因此输出决定了最基本的组成元素),向上回溯,遇到不确定的细节 (例如这一步处理需要用到什么算法?)向客户和技术人员请教,将其记录。

3.简易的应用规格说明书

目的:为了解决前两种方法导致的,用户的被动和与开发者之间的误解。

步骤:

1.初步的访谈
2.开发者和用户分别写出产品需求
3.开会讨论,各自展示需求
4.得出了意见一致,制订小型规格说明
5.根据会议结果,起草完整的需求说明

4.快速建立软件模型

通常使用下述三个方法:

1.第四代技术
2.可重用的软件构件
3.形式化规格说明和原型环境

快速原型应该有两点特质:“快速” “容易修改”

快速:要尽可能快的给用户提供一个系统模型

容易修改:因为系统可能重复修改很多遍,如果修改时间过长,必定延误开发时间。

分析建模和规格说明

分析建模

为了开发复杂的系统,应从不同功能角度抽象出目标系统的特性

(数据模型、功能模型、行为模型)

软件需求规格说明

要使用自然语言,完整、准确、具体地描述

系统的数据要求、
功能需求、性能需求、
可靠性和可用性要求、出错处理需求、
接口需求、约束、
逆向需求以及将来可能提出的要求。

就是上面提到的一些东西,这里要成体系的成文章的写出来。

实体联系图

数据模型中包含三种互相关联的信息:

1.数据对象
2.数据对象的属性
3.数据对象彼此间的关系

数据对象

数据对象是可以被定义的一组实体

数据对象可以看作是不包含方法

属性

属性就是数据对象的性质。

即“键”。

属性可以帮助人们通过多个属性来找到对应的对象。

联系

联系可分为以下三种:

一对一联系:一个部门只有一个经理
一对多联系:老师上课
多对多联系:学生选课

image

实体 联系图的符号

即ER图
包含:

实体:矩形框
关系:菱形框
属性:椭圆形或圆角矩形

数据规范化

为减少数据冗余,避免出现操作异常,简化修改数据的结构

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

第一范式、第二范式、...第五范式

随着范式的上升,数据的冗余程度会变小

但是,也会导致存储更加复杂、稳定性变差、性能下降等问题

因此,一般使用第三范式较为恰当。

范式举例:

image

image

image

状态转换图

状态

主要的状态有:

初态
终态
中间状态

注意:在一张状态图中,初态只能有一个,但终态可以有0至多个。

事件

让系统从一个状态转化成下一个状态的事情。

例如:单击鼠标

符号

初态用实心圆表示,终态用一对同心圆表示,中间状态用圆角矩阵表示。

中间态符号

中间状态可以有三层

第一层:状态名称
第二层:状态变量的名字和值
第三层:活动表

活动表经常使用三种标准事件:entry、exit、do

分别为进入状态时的动作,退出状态时的动作,在该状态下的动作

状态转换符号

状态之间的带箭头的连线是状态转换。

一般在线上会标明触发事件,代表这件事件导致状态转换,如果没有标明事件,则说明前状态执行完后自动转换。

image

其他图形工具

在描述复杂事物时,图形比文字优越许多。

前面已经介绍了

1.数据流图
2.实体联系图(E-R图)
3.状态图

接下来再介绍三种可能用到的图形工具

层次方框图

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

例子:

image

Warnier图

和层次方框图类似,Warnier图也用树形结构描绘信息,但是这种图形工具比层次方框图提供了更丰富的描绘手段。

总之就是层次方框图plus,包含更多信息

例子:

image

IPO图

就是输入、处理、输出图的简称,由IBM公司完善

例子:

image

验证软件需求(似乎不是重点)

验证软件需求的方面

主要有4个:

一致性:
    所有需求必须是一致的,不能和其他需求相互矛盾
完整性:
    规格说明书应该包括用户指定的所有功能
现实性:
    需求可以通过现有的硬件和软件技术实现
有效性:
    必须证明需求是正确有效的,可以解决用户面临的问题

验证软件需求的方法

验证一致性

。。。