需求分析

需求分析的任务

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

2、确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

3、系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。

传统与现代需求方法的比较

需求管理存在的问题

1、范围问题：系统目标、边界未被良好定义，用户和开发团队理解不一致。

2、理解问题：用户不能完全了解自己需要什么，对系统能力、局限更加不清楚；工程师不理解用户的问题域和应用环境。

3、易变问题：需求随时间发生变化。

需求工程

1、20世纪80年代中期，形成了软件工程的子领域——需求工程。

2、进入20世纪90年代后，需求工程称为软件界研究的重点之一。

3、Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”。

阶段划分

确定对系统的综合要求

分析系统的数据要求

导出系统的逻辑模型

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

修正系统开发计划

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

访谈

面向数据流自顶向下求精

简易的应用规格说明技术

1、简易的应用规格说明技术是一种面向团队的需求收集法。

2、这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。

分析需求的典型过程

1. 初步访谈，准备会议

        首先进行初步的访谈，初步确定待解决的问题的范围和解决方案；然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举协调人。

2. 会前审查需求，确定列表

        要求每位与会者在开会的前几天认真审查产品需求，并且列出对象、操作这些对象或与这些对象交互的服务、约束条件和性能标准。

3.会上讨论列表，创建组合列表
        每位与会者展示列表供大家讨论。大家共同创建一张组合列表；由协调人主持讨论这些列表。

4.分组制定小型规格说明
        与会者分成更小的小组，为每张列表中的项目制定小型规格说明；每个小组都向全体与会者展示他们制定的小型规格说明，供大家讨论。
5.制定确认标准，起草需求规格说明书
        每个与会者都制定出产品的一整套确认标准，并提交会议讨论，以创建出意见一致的确认标准；最后，起草完整的软件需求规格说明书。

简易的应用规格说明技术的优点

1、开发者与用户不分彼此，齐心协力，密切合作

2、即时讨论并求精

3、有能导出规格说明的具体步骤

快速建立软件原型

快速原型的特性

1、“快速”

快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型。因此，原型的某些缺陷是可以忽略的。

2、“容易修改”

如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。如果修改耗时过多，势必延误软件开发时间。

快速原型通常使用下述3种方法和工具

(1) 第四代技术（4GL）

        第四代技术包括众多数据库查询（如SQL）和报表语言（如ADF）、程序和应用系统生成器（如Power Builder和Oracle的应用开发环境）以及其他非常高级的非过程语言。

        第四代技术使得软件工程师能够快速地生成可执行的代码，它们是较理想的快速原型工具。

第四代技术特点：

        简单易学，用户界面良好，面向问题、非过程化程度高，用户只需告知系统做什么，而无需说明怎么做。用4GL编程使用的代码量较少，并可成数量级地提高软件生产率。

程序设计语言划代：

        1GL是汇编语言；

        2GL是高级程序设计语言，如FORTRAN，ALGOL，BASIC，LISP等；

        3GL是增强性的高级程序设计语言，如PASCAL，ALGOL68，FORTRAN77等；

        4GL是按计算机科学理论指导设计出来的结构化语言，如ADA，MODULA－2，SMALLTALK－80，JAVA，VB，VC，VF等。

(2)可重用的软件构件
        另外一种快速构建原型的方法，是使用一组已有的软件构件(也称为组件)来装配(而不是从头构造)原型。
        软件构件可以是数据结构(或数据库)，或软件体系结构构件(即程序)，或过程构件(即模块)。

(3)形式化规格说明和原型环境

        非形式化方法:自然语言描述

        半形式化方法:数据流图或实体-联系图

        形式化方法:基于数学的技术

分析建模与规格说明

分析建模

1、模型：就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。

2、结构化分析过程：实质上是一种创建模型的活动。系统分析员从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。

3种分析模型

1、数据模型

2、功能模型

3、行为模型

分析模型的结构

规格说明

我国定义了GB856D-1988国家标准，给出了需求规格说明的内容框架：

实体-联系图

数据对象

1、数据对象：是对软件必须理解的复合信息的抽象。复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象。

2、数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。

3、数据对象彼此间是有关联的。

属性

1、属性：定义了数据对象的性质。必须把一个或多个属性定义为“标识符” 。

2、根据对问题的理解来确定特定数据对象的合适的属性。

联系

1、联系：数据对象彼此之间相互连接的方式称为联系，也称为关系。

2、联系可分为以下3种类型：

（1）一对一联系(1∶1)

（2）一对多联系(1∶N)

（3）多对多联系(M∶N)

3、联系也可能有属性。

实体-联系图的符号

例一

某校教学管理系统的ER图

ER图优点及数据建模工具

ER图的优点：

1、比较接近人的习惯思维方式；

2、用简单的图形符号表达系统分析员对问题域的理解，用户也容易理解，可以作为用户与分析员之间有效的交流工具。

数据建模工具：以自动化的方式创建ER图、数据字典及相关模型。

1、AllFusion ERWin 辅助设计数据库、数据对象、结构、关键元素

2、Oracle Designer 建模、应用系统和数据库设计

3、Meta Scope 图形化显示数据

4、Model Sphere Visible Analyst 模型可视化分析

5、ER/Studio 支持实体-关系建模

例二

银行储蓄系统的ER图

银行计算机储蓄系统的工作过程大致如下：

1、储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息，并印出存单给储户；

2、如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。

数据规范化

数据结构规范化

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

范式

通常用“范式(normal forms)”定义消除数据冗余的程度。第一范式(1 NF)数据冗余程度最大，第五范式(5 NF)数据冗余程度最小。

范式级别越高，存储同样数据需要分解成更多张表，因此，“存储自身”过程越复杂。

随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。

范式级别提高则需要访问的表增多，因此性能(速度)将下降。

第一范式

每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构

第二范式

满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)

第三范式

符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)

状态转换图

状态转换图：通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

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

状态

状态：是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式

状态规定了系统对事件的响应方式

状态主要有：

        初态(即初始状态)，只能有1个

        终态(即最终状态)，可以有0至多个中间状态

状态图分类：

        表示系统循环运行过程，通常不关心循环是怎样启动的

        表示系统单程生命期，需要标明初始状态和最终状态

事件

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

符号

初态：用实心圆表示

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

中间状态：用圆角矩形表示，分成上、中、下3部分：

        上面部分-----为状态的名称

        中间部分-----为状态变量的名字和值

        下面部分-----是活动表

带箭头的连线：称为状态转换，箭头指明了转换方向

主要符号

活动表的语法格式

事件名(参数表)/动作表达式

“事件名”可以是任何事件的名称

常用的3种标准事件：

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

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

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

需要时可以为事件指定参数表

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

事件表达式的语法

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

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

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

如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生

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

例一

电话系统

例二

银行储蓄系统——存款过程的状态图

银行储蓄系统——取款过程的状态图

其他图形工具

层次方框图

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

树形结构的顶层是一个单独的矩形框，它代表完整的数据结构；

下面的各层矩形框代表这个数据的子集；

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

某计算机公司的全部产品的层次方框图：

Warnier图

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

特点：用Warnier图可以表明信息的逻辑组织，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。

软件产品的Warnier图：

IPO图

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

基本形式：是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。

主文件更新处理的IPO图：

改进的IPO图

这种图中包含某些附加的信息，在软件设计过程中将比原始的IPO图更有用。在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。

验证软件需求

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

1、一致性，所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾

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

3、现实性，指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的

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

验证软件需求的方法

用于需求分析的工具

软件工具应该满足下列要求：

1、必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；使用这个软件工具能够导出详细的文档

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

3、使用这个软件工具之后，应该能够改进通信状况。