笔记内容大部分来源于课本《软件工程导论》，侵删
可行性研究是用较小的成本杂较短的时间内确定是否存在可行的解法
而需求分析是回答“系统必须做什么”这个问题
*结构化分析方法遵守的准则：
- 理解并描述问题的信息域，建立数据模型
- 定义软件应完成的功能，建立功能模型
- 描述外部事件结果的软件行为，建立行为模型
- 对描述信息、功能和行为的模型进行分解，用层次的方式展示细节
3.1需求分析的任务
需求获取难的原因：
- 需求的动态性
- 模糊性
- 开发者与用户要达成一致的认识
- 需求复杂而庞大
需求分析的任务
①确定对系统的综合要求
*综合任务：
- 功能需求
- 性能需求
- 可靠性和可用性需求
- 出错处理需求
- 接口需求
- 约束
- 逆向需求（不应该做什么）
- 将来可能提出的要求（可扩展性和可维护性）
②分析系统的数据要求（重要任务）
常利用图形工具辅助描绘数据结构
③导出系统的逻辑模型
常用数据流图、实体联系图、状态转换图、数据字典和主要的处理算法去描述这个逻辑模型
④修正系统开发计划
3.2与用户沟通获取需求的方法
需求要：表述清楚、无二义性、尽可能量化
- 访谈：分为正式和非正式访谈
（访问时使用情景分析技术往往非常有效） - 面向数据流自顶向下求精
采用结构化分析方法 - 简易的应用规格说明技术
让用户也写需求，再通过会议起草完整的软件需求规格书 - 快速建立软件模型
快速建立旨在演示目标系统主要功能的可运行程序
3.3分析建模与规格说明
需求分析过程应该建立3种模型：数据模型、功能模型、行为模型
需求分析除了建立分析模型外还应写出软件需求规格说明书
3.4实体-联系图
为了把用户的数据要求描述出来，系统分析员需要建立面向问题的概念性数据模型。
数据模型包含3种互相关联的信息：数据对象、数据对象的属性、数据对象彼此间相互连接的关系
数据对象：只封装了数据而没有对施加于数据上的操作的引用（数据对象与面向对象范型的不同）
属性：定义了数据对象的本质
联系：数据对象彼此之间相互连接的方式称为联系，也称为关系（包括一对一(1:1)、一对多(1:N)、多对多(N:N)联系）
通常使用实体-联系图（ER图）建立数据模型
ER模型：用ER图描绘的数据模型称为ER数据模型
ER图包含的3中基本成分：实体（矩形框）、关系（连接相关实体的菱形框）、属性（椭圆形或圆角矩形）。
3.5数据规范化
范式：消除数据冗余的程度（第一级范式冗余度最大，第五范式冗余度最小）
范式级别越高，冗余程度越小，拆分越多，大多数场合下第三范式比较实用
3.6状态转换图
状态：任何可以被观察到的系统行为模式（规定了系统对事件的响应方式）
状态图中的状态主要有：初态（只能有1个）、终态（可以有0个或多个）、中间状态
事件：在某个时刻发生的事情，是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象
符号：状态图中，初态用实心圆、终态用一对同心圆（内圆为实心圆）、中间状态用圆角矩形表示，状态转换用带箭头的连线表示。
- 中间状态中包括三部分：状态名（必要）、状态变量（可选）、活动表（可选）
*活动表语法格式：事件名（参数表）/动作表达式。（事件名可以是任何事件的名称常用entry/exit/do，动作表达式描述应做的具体动作） - 状态转换：箭头指明转换方向，箭头线上标明触发转换的事件表达式（未标明则在状态的内部活动结束后自动转换）
*事件表达式的语法格式：事件说明[守卫条件]/动作表达式。（事件说明的语法：事件名（参数表）；守卫条件是一个布尔表达式；动作表达式是一个过程表达式）
书本P67例子
3.7其他图形工具
-
层次方框图
用树形结构的一系列多层次的矩形框描绘数据的层次结构
（顶层框代表完整的数据结构，下面各层矩形框代表这个数据的子集，最底层框是实际数据元素）
-
Warnier图
用树形结构描绘信息，可以表明信息的逻辑组织
-
IPO图
是输入、处理、输出图的简称
3.8验证软件需求
从四个方面验证软件需求的正确性：一致性、完整性、现实性、有效性
- 验证需求的一致性
靠人工技术审查验证软件系统规格说明书的正确性 - 验证需求的现实性
参照以往的开发经验，采取仿真或性能模拟技术 - 验证需求验证的完整性和有效性
与用户密切合作，使用原型系统了解用户的真正需求
