软件工程：第三章 需求分析

导学目标

1. 了解需求分析的目的和基本任务等

2. 了解常见的获取需求的方式

3. 掌握需求分析建模和结构化分析方法

4. 掌握实体联系图（E-R图）画法

5. 了解数据规范化分类及目的

6. 掌握状态转换图的画法

7. 了解层次方框图和IPO图

第一节 需求分析的任务

3.1.1 需求分析

软件定义时期的最后一个阶段，准确的回答系统必须做什么这个问题

系统分析员和用户一起商定

清楚、准确、具体的描述软件产品必须具备的功能、性能、运行规则等各方面的要求

3.1.2 需求分析的任务

基本任务

• 准确的回答系统必须做什么的问题

具体任务

• 确定软件系统的综合需求

• 分析系统的数据需求

  • 数据模型、信息模型E-R图、层次方框图

• 导出软件系统的逻辑模型

  • 数据流图、E-R图、状态转化图、数据字典、算法

• 修正系统的开发计划

• 验证软件需求分析的正确性

• 编写软件规则需求说明书

确定软件系统的综合需求

1. 功能需求：系统必须提供的服务

   • 系统要做什么？

   • 系统什么时候做什么？

   • 系统何时修改或者升级？

2. 性能需求：系统必须满足的定时约束或者容量约束等

   • 软件开发的技术性指标，包括响应时间、存储容量限制、执行的速度以及吞吐量

3. 可靠性和可用性需求

   • 系统可靠性要求？

   • 系统平均出错时间？

   • 出错后重启系统允许的时间？

4. 出错处理需求

   • 系统对环境错误应该如何响应

5. 接口需求：系统与它的环境通信格式要求

   • 用户接口需求

   • 硬件接口需求

   • 软件接口需求

   • 通信接口需求

6. 约束需求：设计或实现约束时应遵守的限制条件例如精度、工具、语言、设计、标准、平台等

   • 环境约束

   • 界面约束

   • 用户或者人的因素约束

   • 文档约束

   • 数据约束

   • 资源约束

   • 安全保密要求约束

   • 软件成本消耗与开发进度需求

7. 逆向需求：说明系统不应该做什么

8. 将来可能提出的要求

3.1.3 需求分析的注意事项

工作大致分为4个阶段

1. 对问题的识别

2. 分析与综合

3. 制定规格说明

4. 评审

3个基本原则

• 必须能够表达和理解问题的数据域和功能域

• 必须按自顶向下、逐步分解的方式对问题进行分解和不断细化

要给出系统的逻辑视图和物理视图

3.1.4 优秀需求分析的特点

• 完整性

• 正确性

• 可行性

• 必要性

• 划分优先级

• 无二义性

• 可验证性

第二节 获取需求的方法

3.2.1 需求获取存在的问题

• 客户说不清楚自己的需求

• 需求常常变化

• 问题的复杂性和对问题空间理解的不完备性与不一致性

3.2.2 需求获取的方法

访谈

• 基本形式：正式、非正式访谈

• 需要收集大量人员意见：使用调查表

• 情景分析技术：对用户将来使用目标系统解决某个具体问题的方法和结果进行分析

• 情景分析技术的用途：

  • 一定程序上演示目标系统的行为，方便用户理解

  • 保证用户在需求分析过程中扮演一个积极主动的角色

面向数据流自顶向下求精

• 结构化分析方法

• 从系统的高层数据流图输出端出发

• 对不清楚的地方可以与用户和其他人员交流

• 利用数据流图、数据字典、IPO图向用户解释系统

• 根据用户反馈进行补充

• 细化数据流图

  

简易的应用规格说明

• 面向团队的需求收集法

• 提倡用户与开发者密切合作

• 信息系统领域使用的主流技术

• 典型过程

  • 初步访谈

  • 开发者和用户分别写产品需求

  • 组织会议，会前审查产品需求

  • 会议讨论，严禁批评与争论

  • 针对每个议题创建一张意见一致的列表

  • 小组制定小型规格说明，供大家讨论

快速建立软件原型(了解)

• 实现用户看得见的功能

• 快速

• 容易修改

第三节 需求分析建模

3.3.1 需求分析的四个阶段

1. 调查研究

   • 系统分析员协同程序员向用户做需求调查，根据可行性报告和项目开发计划报告，确定系统必须做什么，并获得当前系统的具体模型，用数据流图或者IPO 图表示出来

   • 【补充数据字典、修改IPO 图】

2. 分析综合

   • 系统分析员从数据流和数据结构出发，逐步细化所有软件的功能，剔除其中不合理部分，增加其需要的部分，最终合成系统的解决方案，并给出目标系统的详细逻辑模型

   • 【系统分析员和用户追踪数据流图，复查系统逻辑模型】

3. 书写需求分析文档

   • 把分析的结果用正式的文档记录下，主要包括4份文档资料：系统规格说明书、数据需求、用户系统描述、修正的开发计划

   • 【系统规格、数据要求、用户系统描述等文档】

4. 需求分析评审

   • 作为需求分析的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性以及其他需求给与评价。

   • 【评审结果】

3.3.2 需求分析阶段常用的模型（逻辑模型）有三种

• 数据模型

  • E-R图：描述数据对象与数据对象之间的关系

• 功能模型

  • 数据流图：描述数据在软件系统中移动时被变换的逻辑过程

• 行为模型

  • 状态转换图：描绘了系统中的各种状态以及不同状态间转换的方式

需求分析步骤

3.3.3 结构化分析方法

• 结构化分析方法是70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法

• 核心思想是分解化简问题、物理与逻辑表示分开、进行数据与逻辑抽象

• 适用于分析大型数据处理系统，特别适合企事业管理系统

• 使用的建模工具主要包括

  • 数据流图：表达系统内数据的流动情况

  • 数据字典：用于定义系统中的数据元素

  • 结构化语言、判断表、判定树：描述数据流的加工的工具

第四节 实体联系图

3.4.1 概念性模型

定义

• 概念性模型也叫做信息模型，是一种面向问题的数据模型，按照用户的观点对数据进行建模

最常用的概念数据模型

• 实体联系图（Entity-Relationship Diagram），简称ER图

作用

• 有助于理解业务和系统中数据组成的关系及交互

• 可以使用简单的符号使不熟悉计算机的用户也能理解

组成ER模型的三要素

1. 数据对象

   • 具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象

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

   • 数据对象使用矩形框表示

   • 数据对象之间是彼此有关联的

2. 属性

   • 定义了实体或者联系所具有的性质

   • 用椭圆形或者圆角矩形表示

3. 联系

   • 数据对象彼此之间相关连接的方式

   • 联系可以是一对一、一对多、多对多的关系

   • 用菱形框表示

   • 联系也可以有属性

3.4.2 实例分析

一个图书馆借阅管理数据库要求提供下述服务：

（１）可随时查询书库中现有书籍的品种、数量与存放位置。所有各类书籍均可由书号唯一标识。

（２）可随时查询书籍借还情况，包括借书人单位、姓名、借书证号、借书日期和还书日期。我们约定：任何人可借多种书，任何一种书可为多个人所借，借书证号具有唯一性。

（３）当需要时，可通过数据库中保存的出版社的电报编号、电话、邮编及地址等信息下相应出版社增购有关书籍。我们约定，一个出版社可出版多种书籍，同一本书仅为一个出版社出版，出版社名具有唯一性。

根据上述描述，画出满足需求的E-R图

第五节 数据规范化

目的

• 减少数据冗余

• 避免插入或者删除异常

• 简化数据修改的过程

范式

• 范式消除数据的冗余程度

• 范式分为1NF~5NF，1NF 冗余程度最大，5NF 冗余程度最小

  • 第一范式（1NF）

    • 数据的冗余程度最大

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

  • 第二范式（2NF）

    • 满足一范式条件

    • 每个非关键字属性都由整个关键字决定

  • 第三范式（3NF）（一般使用最多）

    • 满足第二范式条件

    • 每个非关键字属性都仅由关键字决定，一个非关键字属性值不能依赖于另一个非关键字属性值

第六节 状态转换图

3.6.1 状态转换图

状态转换图

• 简称状态图

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

状态

• 任何可以被观察到的系统行为模式

• 一个状态代表系统的一种行为模式

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

• 主要状态

  • 初态（初始状态）：仅1个

  • 终态（最终状态）：0-N个

  • 中间状态

• 状态图可以表示系统循环运行的过程，而不关心循环如何启动

• 状态图可以表示系统单程生命期，需注明初始状态和最终状态

事件

• 某个特定时刻发生的事情

• 引起系统做动作或从一个状态转换到另一个状态

• 简而言之，事件就是引起系统做动作或状态转换的控制信息

符号

• 在状态图中，初态是实心圆

• 终态是同心圆（内圆为实心圆）

• 中间状态是圆角矩形，共分成上中下三个部分

  • 状态名称（必须有）

  • 状态变量名和值（可选）

  • 活动表（可选）

示例

示例名词解释

• 活动表

  • 语法格式：事件名（参数表）/动作表达式

  • 事件名可以是任何事件的名称，经常使用3种标准事件

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

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

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

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

  • 动作表达式：描述应该做的具体动作

• 事件表达式

  • 语法格式：事件说明[守卫条件]/动作表达式

  • 事件说明的语法：事件名（参数表）

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

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

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

3.6.2 案例

图书状态图

电话系统状态图

第七节 其他图形工具

3.7.1 层次方框图

• 用树形结构的一系列多层次的矩形框描述数据的层级结构

• 示例

  

3.7.2 IPO 图

• 输入、处理、输出图的简称

• IBM 公司发展完善的一种图形工具

• 示例