基本任务：对目标系统提出完整、准确、清晰、具体的要求，即准确的回答“系统必须做什么？”这个问题。
为什么需要需求分析：
因为在可行性研究阶段，我们是以最小的代码和最短的时间内确定是否存在可行的解法方法，忽略了很多细节，在这个阶段需要详细描述。
分析方法必须遵守的准则：
（1） 必须理解并描述问题的信息领域，根据这条准则应该建立数据模型。
（2） 必须定义软件完成的功能，根据这条准则应该建立功能模型。
（3） 必须描述作为外部事件结果的软件行为，要求建立行为模型。
（4） 必须对描述信息，功能和行为的模型进行分解，用层次的方式展示细节。
需求分析的任务
综合要求：
1． 功能需求
指定系统必须完成的服务
2． 性能需求
指定系统必须满足的定时约束或容量约束等约束。
3． 可靠性和可用性需求
定量的指定系统的可靠性
4． 出错处理需求
说明系统对环境错误应该怎样处理
5． 接口需求
描述应用系统与它环境通信的格式
6． 约束
描述在设计或实现应用系统时应遵守的限制条件（用户或环境强加给项目的限制条件）
7． 逆向需求
说明系统不应该做什么
8． 将来可能提出的要求
列出那些不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。目的是为了对系统将来可能的扩充和修改预做准备。
数据要求：
数据可以全面准确地定义数据，数据字典的缺点是不够形象直观，为了提高可理解性，常加入图形工具辅助描绘数据结构。
为了减少数据冗余、避免出现插入异常或删除异常，简化修改数据的过程，通常要把数据结构规范化。
导出系统的逻辑模型：
综合以上两个要求，导出系统的详细的逻辑模型，常用数据流图、ER图、状态转换图、数据字典和主要的处理算法描述这个模型。
修正系统开发计划：
获得更深入的了解，比较准确的估计系统的成本和进度，修正以前制定的开发计划。
与用户沟通获得需求的方法：
（1） 访谈（包括调查表）
（2） 情景分析
（3） 从输出回溯输入，利用已有的数据流图、数据字典和IPO图，然后再与用户一步步讨论数据处理流程，进一步了解详细需求
基于团队的需求收集法：
（1） 首先进行初步的访谈（双方都分别写一份产品需求），会前列一份列表，说明系统环境组成部分的对象、系统将产生的对象以前系统为了完成功能将使用的对象。
（2） 会议开始后，讨论的第一个问题是，是否需要这个新的产品，一旦大家都同意确实需要这个新产品，则可以把会前准备好的列表展示出来供大家讨论。
（3） 针对完每个列表之后，合并成一张组合列表，加入展示过程中产生的新想法。
（4） 分组，为每张列表中的项目制定小型规模说明（对列表中包含的单词或短语的准确说明）
（5） 每个小组向全体成员展示他们制定的小型规格说明，供大家，会后做进一步精化工作。
（6） 起草完整的需求说明书。
快速建立软件原型：
最准确、最有效、最强大的需求分析技术
任务：快速地为用户提供一个展示其功能的目标系统的模型（可运行的软件原型，只演示其将有的功能，而不是实现其功能）
E-R图
包含三种信息：数据对象、对象属性和对象关系
符号：矩形代表对象，菱形代表关系，椭圆或圆角矩形代表属性。
数据规范化
第一范式：指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性,否则不是关系数据模型. 简而言之，第一范式就是无重复的列。
第二范式：除了要满足第一范式，还要保证每个非关键字属性值完全依赖于关键字。
第三范式：符合第二范式，同时每个非关键字属性不能传递依赖于其他的非关键字属性。要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
BC范式：符合第一范式，且每个属性不传递依赖于R的任何键。
第四范式：R<U，F>∈1NF，如果对于R的每个非平凡多值依赖X→→Y（Y X），X都含有候选码。
状态转换图
状态：代表任何可以被观察到的系统的一种行为模式。
状态有：初态、终态和中间状态。
初态只有一个，终态可有多个。
事件：引起系统做动作或转换状态的控制信息。
符号：圆解矩形，可以用直线分格
事件表达式：事件说明[守卫条件]/动作表达式
事件说明的语法：事件名（参数表）
动作表达式：是一个过程表达式，当状态转换开始时执行该表达式。
其它图形工具
层次方框图：从顶往下，一层层往下精细化，直到确定数据结构的全部细节为止。
符号：矩形框（数据子集）
Warnier图：在一个花括号内的所有名字都属于同一类信息。有点类似树结构。
IPO图：是输入、处理、输出图的简称。
验证需求
从四个方面验证：
（1） 一致性：任何一条需求不能和其他需求互相矛盾。
（2） 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
（3） 现实性：指定的需求应该用现有的硬件技术和软件技术基本上可以实现的。
（4） 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。