第3章 需求分析
3.1 需求分析任务
3.1.1 确定对系统的综合要求
1. 功能需求
通过需求分析应该划分出必须完成的所有功能。
2. 性能需求
性能需求指定系统必须满足的定时约束或容量约束
3. 可靠性和可用性需求
可靠性需求定量地指定系统的可靠性
可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
4. 出错处理需求
出错处理需求说明系统对环境错误应该怎样响应
系统本身的错误的检测，主要在系统关键部分设置，而且应该尽可能的少
5. 接口需求
用户接口、硬件接口、软件接口、通信接口
6. 约束
设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
需求阶段的设计约束为用户或环境强加给项目的限制条件。
7. 逆序需求
逆向需求说明系统不应该做什么。
8. 将来可能提出的要求
3.1.2分析系统的数据要求
数据结构：表示数据元素之间的逻辑关系。数据字典定义数据。
3.1.3导出系统的逻辑模型
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
3.2与用户沟通获取需求的方法
3.2.1 访谈
正式访谈：系统分析员提出一些事先准备好的具体问题
非正式访谈：分析员提出一些用户可以自由回答的开放性问题，以鼓励被访问
人员说出自己的想法。
3.2.2 面向数据流自顶向下求精
3.2.3 简易的应用规格说明技术
3.2.4 快速建立软件原型
快速建立软件原型是最准确、最有效、最强大的需求分析技术。
3.3 分析建模与规格说明
3.3.1 分析建模
结构化分析实质上是一种创建模型的活动
3.3.2 软件需求规格说明书
需求规格说明书通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。
3.4 实体-联系图
概念性的数据模型(信息模型)
①概念性的数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。
②它描述了从用户角度看到的数据，它反映了用户的实现环境，而且与在软件系统中的实现方法无关。
③数据模型中包含3种相互关联的信息：数据对象、数据对象的属性、数据对象的关系。
3.4.1 数据对象
数据对象彼此之间是有联系的
3.4.2 属性
属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”。用标识符属性可以作为关键字。
3.4.3 联系
数据对象彼此之间相互连接的方式称为联系，也称为关系。
3.5 数据规范化
数据结构规范化：是为了减少软件系统冗余信息，避免出现插入异常或删除异常，简化修改数据的过程。
通常用范式定义消除数据冗余的程度。第一范式数据冗余程度最大，第五范式(5NF)数据冗余程度最小。
从实用角度看，在大多数场合选用第三范式都比较恰当。
3.6 状态转换图
状态转换图(简称状态图)，通过描绘系统的状态及引起系统状态转换的事件，来描述系统的行为。
3.6.1 状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
3.6.2 事件
事件是某个特定时刻发生的事情，它是引起系统做动作或状态转换的控制信息
3.6.3 符号
行为指对象达到某种状态时所做的一系列处理操作。
3.6.4 例子
3.7 其他图形工具
3.7.1 层次方框图
层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构
3.7.2 Warnier图
Warnier图也用树形结构描绘信息，可以表明信息的逻辑组织。
3.7.3 IPO图
IPO图是输入处理/输出图。能方便的描绘输入数据，对数据的处理和输出数据间的关系。
3.8 验证软件需求
3.8.1 从哪些方面验证软件需的正确性
为了提高软件产品质量，确保软件开发成功，降低开发成本，必须严格验证目标系统的正确性。
3.8.2 验证软件需求的方法
① 验证需求的一致性
② 验证需求的现实性
③ 验证需求的完整性
