第二章意外地少,第三章好像也不是特别多,要是全都这么少就好了!

需求分析的任务

  • 确定对系统的综合要求

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

    建立数据模型——ER图

    描绘数据结构——层次方框图和Warnier图

    数据结构规范化

  • 导出系统的逻辑模型

    软件系统详细的逻辑模型通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述

  • 修正系统开发计划

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

  • 访谈
  • 面向数据流自顶向下求精
  • 简易的应用规格说明技术
  • 快速建立软件原型

分析建模与规格说明(软件需求规格说明)

分析建模:

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

软件需求规格说明(文档):

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

状态转换图

概念

通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作(例如,处理数据)。

状态

状态是任何可以被观察到的系统行为模式,一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式

状态主要有:

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

  • 终态(即最终状态),可以有0至多个

  • 中间状态

状态图分类:

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

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

事件

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

符号

初态:用实心圆表示;

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

中间状态:用圆角矩形表示,分成上、中、下3部分。

1、上面部分—–为状态的名称;

2、中间部分—–为状态变量的名字和值;

3、下面部分—–是活动表。

带箭头的连线:称为状态转换,箭头指明了转换方向。

image-20200804102834346状态图中使用的主要符号

活动表的语法格式:

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

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

常用的3种标准事件:

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

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

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

需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。

事件表达式的语法:

事件说明[守卫条件]/动作表达式

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

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

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

img例子

其他图形工具

层次方图

image-20200804103119830

warnier图

image-20200804103147193

IPO图

image-20200804103158837

image-20200804103213752

验证软件需求

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

  • 一致性:所有需求必须是一致的,任何一条需求不能和其他需求互相矛盾。

  • 完整性:需求必须是完整的,规格说明书应该包括用户需要的每一个功能或性能。

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

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