需求分析的原则
循序渐进
需求收集，需求分析（不同时期占比不同）
采集需求->整理需求->建立需求分析模型->编写需求规约文档->复审
自顶向下，逐层分解
横向分解：多个子功能
纵向分解：一个功能不断细分
与实现分离
着重描述系统必须做什么，而不是如何去做系统
定义需求属性
每个需求都有类型、原因、开发优先级、风险、客户满意度、客户不满意度、依赖关系、冲突关系，以及来源等属性
可验证性
证明所开发的系统符客户和用户的要求的依据
可追踪性
问题存在传递性
分析潜在变更的影响
核实通过实施系统所有的需求被实现
其他原则
使用术语
尊重客户的意见
重视复用需求
对变更进行管理
要求“确认需求”
传统需求分析建模方法
思想：抽象与自顶向下的逐层与自顶向下的逐层分解
数据建模
E-R图
功能建模
数据流程图（DFD，Data Flow Diagram）
3种图型：
总体图：系统和周围环境的关系
零级图：系统的主要功能/主要组成子系统
细节图：复杂处理的内部表示
4种符号：
外部实体（方）：系统之外的人员或组织，表示系统输入来源和输出去向
数据处理（圆）：输入流到输出流的变换
数据存储（开口矩）:文件，保存数据信息
数据流（箭头）：有定义明确的名字标识
逐层分解的数据流程图
绘制规定
- 外部实体只出现在总体图和零级图中。
- 数据存储只出现在零级图和细节图中。
- 同一个数据存储不能在不同的层次上出现。
- 图中的每个数据流必须与某个数据处理相关联。
- 数据流的源点和目标不能是同一个数据处理。
- 0计算机系统的输入/输出命令不能作为数据处理，数据处理仅标识数据的变换。
- 图中每个表达相同含义的元素都应使用唯一的名称，没有两个表达不同含义的元素的名称是相同的。
- 分层的数据流程图各层之间应保持平衡
- 数据处理或数据存储都不应该存在不必要的输入、输入缺失、不可能的输出。
- 编号
数据处理编号：
一般总体图中的为0
细节图和零级图的编号是相互关联的，处理2.2包含在处理2.0内，而处理2.2.1包含在处理2.2内
数据存储编号：D+序号
行为建模
状态变迁图(STD，State-Transition Diagram)
状态（圆：中间标明状态名字）
变迁（箭头）
Petri网（未掌握）
位置（Place）节点
系统的状态
圆形表示
跃迁（Transition）节点
系统中的事件
短粗线，矩形
激发(点火)
数据字典
配合数据流程图，反映具体细节
数据元素：最小数据单元
数据流：有关的数据元素所组成的动态的数据结构
数据存储：数据结构载体，静态的数据结构
处理：具体处理逻辑
判定表和判定树
判定表
左上部：条件或数据元素名称
右上部：所有条件组合
左下部：处理活动名称
右下部：注明条件组合和相应活动对应关系
判定树
根节点：表示问题的名字
内部节点：表示条件
叶子节点：表示活动
