需求分析
需求分析是软件定义的最后一个阶段,它的基本任务是准确地回答“系统必须做什么”这个问题。
- 为什么要进行需求分析?通常对软件有哪些需求?
- 需求分析阶段有哪些任务?获取需求通常采用哪些方法?
- 描绘系统精确的逻辑模型,通常需要建立哪些模型?简述各模型的作用。
- 层次方框图、Warnier图的作用是什么?二者有何区别?
- 什么是IPO图?IPO图的作用是什么?
- 验证软件需求需要从哪几方面进行验证?
软件的需求
1、用户解决问题或达到目标所需要的条件或权能
2、系统和系统部件要满足合同、标准、规范或其他正式文档所需具有的条件或权能
3、一种反应上面(1)(2)所述条件或权能的文档说明。
需求分析的任务
基本任务是准确的回答:“系统必须做什么”。
分析软件需求和编写软件需求规格说明书。
具体任务:
确定对系统的综合要求
分析系统的数据要求
导出系统的逻辑模型
修正系统的开发计划
需求分析的步骤
需求获取:问题识别
需求提炼:分析建模
需求描述:编写《需求规格说明书》
需求验证:需求分析评审
分析建模与规格说明
三种模型:
功能模型:
数据流图
数据模型:
E-R图
行为模型:
状态转换图
数据流图(见第二章)
实体-联系图(E-R图)
概念
E-R图也称实体-联系图(Entity Relationship Diagram),提供了表示实体类型、属性和联系的方法,用来描述现实世界的概念模型。
构成
ER图有实体(entity)、属性(attribute)、关系(relationship)三部分。
用“矩形框”表示实体型,矩形框内写明实体名称;
用“椭圆框”表示实体的属性,将属性名记入框中;
用”菱形框“表示实体型之间的关系,在菱形框内写明关系名。
用”实心连线“表示:实体与属性之间;实体与联系之间;联系与属性之间用直线相连,并在直线上标注联系的类型。
关联关系的一般性约束
一对一联系(1 ∶1)
对于两个实体集A和B,若A中的每一个值在B中至多有一个实体值与之对应,反之亦然,则称实体集A和B具有一对一的联系。
例如:一个学校只有一个校长,而一个校长只在一个学校中任职,则学校与校长之间具有一对一联系。
一对多联系(1 ∶N)
对于两个实体集A和B,若A中的每一个值在B中有多个实体值与之对应,反之B中每一个实体值在A中至多有一个实体值与之对应,则称实体集A和B具有一对多的联系。
例如:一个学校的教师与课程之间存在一对多的联系“授课”,即每位教师可以教多门课程,但是每门课程只能由一位教师来教,则课程与课程之间具有一对多联系。
多对多联系(M ∶N)
对于两个实体集A和B,若A中每一个实体值在B中有多个实体值与之对应,反之亦然,则称实体集A与实体集B具有多对多联系。
例如:一个学生可以学多门课程,而每门课程可以有多个学生来学习,则学生与课程间的联系“选修 ”是多对多的。
数据规范化
- 第一范式:
- 第二范式:
- 第三范式:
状态转换图
在需求分析过程中应该建立起软件系统的行为模型。状态转换图通过描绘系统的状态以及引起系统状态转换的事件,来表示系统的行为。此外,状态图还指明了作为特点事件的结构,系统将做哪些动作。
在状态图中,初态用实心圆表示、终态用一对同心图(内圆为实心圆)表示。
中间状态用圆角矩形表示,可以用两条水平做线把它分成上,中、下三个部分。上面部分为状态的名称,这部分是必有的。中间部分为状态变量的名字和值,这部分是可选的;下面部分是活动表,这部分也是可选的。
活动表的语法格式如下:
事件名(参数表)/动作表达式
其中.“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件:entry,exit和do。enty事件指定进人该状态的动作,exit事件指定退出该状态的动作,而do事件则指定在该状态下的动作。需要时可以为事件定参数表。活动表中的动作表达式描述应做的具体动作。
状态图中两个状态之间带箭头的连线称为状态转换,箭头指明了转换方向。状态变迁通常是由事件触发的,在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式;如果在箭头线上未标明事件,则表示在源状态的内部活动执行完之后自动触发转换。
事件表达式的语法如下:
事件说明[守卫条件]/动作表达式
其中,事件说明的语法为:事件名(参数表)。
守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件,则当且仅当事件发生且布尔表达式为真时,状态转换才发生。如果只有守卫条件没有事件说明,则只要守卫条件为真,状态转换就发生。动作表达式是一个过程表达式,当状态转换开始时执行该表达式。
其他图像工具
- 层次方框图
用树形结构来描述数据的层次结构
层次结构图(结构图):
层次方框图和层次结构图的区别:
- Warnier图
可以表明信息的逻辑组织
- IPO图
是描绘输入数据、数据处理和输出数据之间关系的图形工具
改进后的IPO图
验证软件需求
需求验证的四个方面
一致性:需求不互相矛盾
完整性:包括用户需要的每一个功能或性能
现实性:现有技术可以实现
有效性:需求是正确的,确实能解决用户面对的问题