软件工程 之需求分析2

软件工程需求分析

基本概念

需求分析阶段的任务

在可行性分析的基础上，进一步了解确定用户需求。准确地回答 “系统必须做什么？” 的问题。

1. BOEHM对软件需求的定义：
   　 研究一种无二义性的表达工具，它能为用户和软件人员双方都接受并能够把“需求”严格地、形式地表达出来。
2. 需求分析的成果：
   获得需求规格说明书。
3. 获取需求的途径：
   必须通过与用户沟通获取用户对软件的需求。

由于需求分析方法不同，描述形式不同。其实现步骤如下图所示


需求分析的具体任务是：
1．确定系统的综合要求
　　• 确定系统功能要求
　(最主要的需求，确定系统必须完成的所有功能）
　　• 确定系统性能要求
（可靠性、联机系统的响应时间、存储容量、安全性能等）
　　• 确定系统运行要求
　（环境要求：系统软件、数据库管理系统、外存和数据通信接口等）
　　• 将来可能提出的要求
（对将来可能提出的扩充及修改作预准备）
2．分析系统的数据要求
软件系统本质上是信息处理系统，因此，必须考虑：
　　• 数据 （需要哪些数据、数据间联系、数据性质、结构）
　　• 数据处理 （处理的类型、处理的逻辑功能）
3．导出系统的逻辑模型
　　DFD 图
4．修正系统的开发计划
　　通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。

需求工程过程

“问题识别——分析综合——编写文档——分析评审”
问题识别：
　　双方确定问题的综合需求。这些需求包括功能需求（最主要的需求）、性能需求、环境需求和用户界面需求，另外还有可靠性、安全性、保密性、可移植性和可维护性等方面的需求。
分析综合：
导出软件的逻辑模型
编写文档：
　　⑴编写“需求说明书”，把双方共同的理解与分析结果用规范的方式描述出来；
　　⑵编写初步用户使用手册；
　　⑶编写确认测试计划；
　　⑷修改完善项目开发计划。
-分析评审：
　　 作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。

需求分析的原则

近几年来已提出许多软件需求分析与说明的方法，每一种分析方法都有独特的观点和表示方法，但都适用下面的基本原则。

1、能够表达和理解问题的信息域以建立数据模型

对于计算机程序处理的数据，其信息域包括信息流（如下图，即数据通过一个系统时的变化方式)、信息内容和信息结构，而功能域反映上述三方面的控制信息。

2、建立描述系统的功能和行为的模型

建立模型的过程是“逐步精化”的综合分析的过程。通过对模型的不断深化认识，来达到对实际问题的深刻认识。

3、能够对问题进行分解和不断细化，建立问题的层次结构。

分解是为了降低问题的复杂性，增加问题的可解性和可描述性。分解可以在同一个层次上进行（横向分解），也可以在多层次上进行（纵向分解）。

需求分析的方法

不同的开发方法，需求分析的方法也有所不同，常见的分析方法有：

功能分析方法
将系统看作若干功能模块的集合，每个功能又可以分解为若干子功能,子功能还可继续分解,分解的结果已经是系统的雏形。

结构化分析方法
是一种以数据、数据的封闭性为基础，从问题空间到某种表示的映射方法，由数据流图（DFD图）表示。

信息建模法
是从数据的角度对现实世界建立模型的,基本工具是E-R图。

面向对象的分析方法
面向对象的分析方法（OOA）的关键是识别问题域内的对象，分析它们之间的关系，并建立起三类模型。

获取需求的方法

1.访谈

访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。

• 访谈有两种基本形式：正式的和非正式的访谈。
• 正式访谈时，系统分析员将提出一些事先准备好的具体问题。
• 在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。

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

数据决定了需要的处理和算法，数据显然是需求分析的出发点，结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
把一个复杂的问题划分成若干小问题，然后再分别解决，将问题的复杂性降低到人可以掌握的程度。分解的方法可分层进行，方法原理是先考虑问题最本质的方面，忽略细节，形成问题的高层概念。然后再逐层添加细节。即在分层过程中采用不同程度的“抽象”级别，最高层的问题最抽象，而低层的较为具体。

当认为某一层比较复杂时到底应该划分为多少个子系统，针对不同的系统的处理不同。划分的原则可以根据业务工作的范围、功能性质、被处理数据对象的特点。一般情况下上面一些层的划分往往按照业务类型划分的比较多，下面一些层往往按照功能的划分比较多。
依照这个策略，对于任何复杂的系统，分析工作都可以有计划、有步骤及有条不紊地进行。

软件需求规格说明

通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。
通常用自然语言,完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
由于自然语言的不一致、歧义、含糊、不完整及抽象层次混乱等问题，有些人主张用形式化方法描述用户对软件系统的需求，第4章将简要地介绍形式化说明技术。

实体-联系图

实体联系图 Entity-Relationship

• E-R图为实体-联系图，提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。
• 构成E-R图的基本要素是实体型、属性和联系，其表示方法为：
• 实体型：用矩形表示，矩形框内写明实体名；
• 属性：用椭圆形表示，并用无向边将其与相应的实体连接起来；
• 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1 : 1，1 : n或m : n）

1 两个实体型之间的联系

用图形来表示两个实体型之间的这三类联系

2 软件需求规格说明

通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。
通常用自然语言,完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
由于自然语言的不一致、歧义、含糊、不完整及抽象层次混乱等问题，有些人主张用形式化方法描述用户对软件系统的需求，第4章将简要地介绍形式化说明技术。

3.两个实体型之间的联系

用图形来表示两个实体型之间的这三类联系

一对一联系（1:1）

实例
一个班级只有一个正班长
一个班长只在一个班中任职
定义：
如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1:1 。

一对多联系（1:n）

实例
一个班级中有若干名学生，
每个学生只在一个班级中学习

定义：
如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1:n。

多对多联系（m:n）

实例
课程与学生之间的联系：
一门课程同时有若干个学生选修
一个学生可以同时选修多门课程

定义：
如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体B具有多对多联系，记为m:n。

4.两个以上实体型之间的联系

两个以上实体型之间一对多联系

若实体集E1，E2，…，En存在联系，对于实体集Ej（j=1，2，…，i-1，i+1，…，n）中的给定实体，最多只和Ei中的一个实体相联系，则我们说Ei与E1，E2，…，Ei-1，Ei+1，…，En之间的联系是一对多的。

多个实体型间的一对一联系

一对夫妇一个孩

两个以上实体型间的多对多联系

供应商、项目、零件三个实体型一个供应商可以供给多个项目多种零件每个项目可以使用多个供应商供应的零件每种零件可由不同供应商供给。

5.ER图–概念模型的一种表示

实体－联系方法(E-R方法)
用E-R图来描述现实世界的概念模型
E-R方法也称为E-R模型

• 实体型

用矩形表示，矩形框内写明实体名。

• 属性

用椭圆形表示，并用无向边将其与相应的实体连接起来

• 联系
  联系本身：
  　　 用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1:1、1:n或m:n）。　　
  联系的方法：
  
  联系的属性：
  　　联系本身也是一种实体型，也可以有属性。如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来。
  　　

数据规范化

数据规范化使用“范式”，到达消除数据冗余的目的，数据库原理进行……

状态转换图

• 结构化分析方法应当遵循准则：
  　（1）必须理解并描述问题的信息域——建立数据模型；
  　（2）必须定义软件应完成的功能——建立功能模型；
  　（3）必须描述作为外部事件结果的软件行为——建立行为模型。
• 状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

此外，状态图还指明了作为特定事件的结果，系统将做哪些动作(例如，处理数据)。
因此，状态图提供了行为建模机制，可以满足第3条分析准则的要求。

状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
在状态图中定义的状态主要有：
初态(即初始状态)、终态(即最终状态)和中间状态。
在一张状态图中只能有一个初态，而终态则可以有0至多个。

事 件

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

符 号

• 初态用实心圆表示；

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

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

• 上面部分为状态的名称（不可缺）；

• 中间部分为状态变量的名字和值（可选）；

• 下面部分是活动表（可选）。

• 活动表的语法格式如下：
  　事件名(参数表)/动作表达式
  　在活动表中经常使用下述3种标准事件：
  　entry，exit和do。
  　entry事件指定进入该状态的动作；
  　exit事件指定退出该状态的动作；
  　do事件则指定在该状态下的动作。
  　状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。

• 事件表达式的语法如下：
  　事件说明［守卫条件］／动作表达式
  　其中，事件说明的语法为：事件名(参数表)。
  　守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。
  　动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

其他图形工具

1.层次方框图

层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。

2.Warnier图

Warnier图是表示信息层次结构的另外一种图形工具，比层次方框图提供了更丰富的手段。
用Warnier图可以表明信息的逻辑组织：
可指出一类或一个信息元素是重复出现的；
也可表示特定信息在某一类信息中是有条件地出现的。
因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。

3. IPO图

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

数据字典表示

存折的定义格式

存折＝户名＋所号＋账号＋开户日＋性质＋（印密）＋
1{存取行}50
所号＝“001”…“999”
户名＝2{字母}24
账号＝“00000000001”…“99999999999”
开户日＝年＋月＋日
性质＝“1”…“6”
印密＝（“0”|“000001”…“999999”）
存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核
日期＝年＋月＋日
年＝“0001”…“9999”
月＝“01”…“12”
日＝“01”…“31”
摘要＝1{字母}4
支出＝金额
存入＝金额
余额＝金额
金额＝“0000000.01”…“9999999.99”
操作＝“00001”…“99999”
复核＝“00001”…“99999”
字母＝[“a”…“z”|“A”…“Z”]

决策表

决策表由4个部分组成：
左上部分是条件茬，在此区域列出了各种可能的单个条件；
左下部分是动作茬，在此区域列出了可能采取的单个动作；
右上部分是条件项，在此区域列出了针对各种条件的每一组条件取值的组合；
右下部分是动作项，这些动作项与条件项紧密相关，它指出了在条件项的各组取值的组合情况下应采取的动作。

决策树

决策树（decision tree）也是用来表达加工逻辑的一种工具，有时侯它比决策表更直观。
检查订货单的决策树

验证软件需求

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

软件系统中15%的错误起源于错误的需求，因此，应该从下述4个方面进行验证：

• (1) 一致性，需求不能和其他需求互相矛盾。
• (2) 完整性，规格说明书应该包括用户需要的每一个功能或性能。
• (3) 现实性，指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
• (4) 有效性，必须证明需求是正确有效的，确实能解决用户面对的问题。

2.验证软件需求的方法

1. 验证需求的一致性

自然语言书写的需求，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。
　　由于人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发不能在正确的基础上顺利进行。
　　形式化的描述软件需求的方法较好地弥补了上述缺点。

2. 验证需求的现实性

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

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

只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。
　　然而许多用户只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。
　　使用原型系统是一个比较现实的方法。