需求分析是软件定义时期的最后一个阶段，它的基本任务是准确回答 “系统必须做什么？”。
需求分析的任务还不是确定系统怎样完成它的任务，而仅仅是确定系统必须完成那些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
需求分析的基本准则：
（1）必须理解并描述问题的信息域，并建立数据模型。
（2）必须定义软件应完成的功能，并建立功能模。
（3）必须描述作为外部事件结果的软件行为，建立行为模型。
（4）对数据、功能、行为模型进行分解，用层次的方法展示细节。
一、需求分析的任务
（1）确定对系统的综合要求
1、功能需求
2、性能需求
3、可靠性和可用性需求
4、出错处理需求
5、接口需求
6、约束（精度；工具和语言；设计约束了；标准约束等）
7、逆向需求（说明软件不应该做什么）
8、将来可能提出的要求
（2）分析系统的数据要求
软件系统本质上都是信息处理系统。
数据字典定义数据，图形工具辅助描绘数据结构（层次方框图，Warnier图）。
（3）导出系统的逻辑模型
综合上述两项分析的结果可以导出系统详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述逻辑模型。
（4）修正系统开发计划
二、分析建模与规格说明
（1）实体—联系图（ER图）
目的:
为了把用户的数据要求清楚准确地描述起来系统分析员通常建立一个概念性的数据模型
要素:
- 实体型：用矩形表示，矩形框内写明实体名；
- 属性：用椭圆形或圆角矩形表示，并用无向边将其与相应的实体连接起来；多值属性由双线连接；主属性名称下加下划线；
- 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型
在E-R图中要明确表明1对多关系，1对1关系和多对多关系:
- 1对1关系在两个实体连线方向写1;
- 1对多关系在1的一方写1，多的一方写N
- 多对多关系则是在两个实体连线方向各写N,M
（2）数据规范化：
第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。
第二范式：满足第一范式条件，而且每个非关键字属性都由整个关键字决定（而不是由关键字的一部分来决定）。
第三范式：符合第二范式的条件，每个非关键字的属性都仅由关键字决定，而且一个非关键字不能仅仅是对另一个非关键字属性的进一步描述（即一个非关键字属性不依赖于另一个非关键字属性值）。
多数场合使用第三范式。
同理，数据库的三大范式：
◆ 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
考虑这样一个表：【联系人】（姓名，性别，电话）
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。
◆ 第二范式（2NF）：首先是 1NF，另外包含两部分内容，① 表必须有一个主键；② 没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 （一个表只描述一件事情）。
考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。
◆ 第三范式（3NF）：首先是 2NF，另外① 非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。(表中的每一列只能依赖于主键）。
考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。
（3）状态转换图 （行为模型）
状态是任何可以被观察到的系统行为模式。
状态图中定义的状态有初态、终态和中间态。一张状态图只能有一个初态，有0至多个终态。
（4）层次方框图
用树形结构的 一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不可再分割的元素）。
（5）IPO图
IPO图是输入输出图的简称。
