目录
需求分析的原则
循序渐进
需求收集，需求分析（不同时期占比不同）
采集需求->整理需求->建立需求分析模型->编写需求规约文档->复审
自顶向下，逐层分解
横向分解：多个子功能
纵向分解：一个功能不断细分
与实现分离
着重描述系统必须做什么，而不是如何去做系统
定义需求属性
每个需求都有类型、原因、开发优先级、风险、客户满意度、客户不满意度、依赖关系、冲突关系，以及来源等属性
可验证性
证明所开发的系统符客户和用户的要求的依据
可追踪性
问题存在传递性
分析潜在变更的影响
核实通过实施系统所有的需求被实现
其他原则
使用术语
尊重客户的意见
重视复用需求
对变更进行管理
要求“确认需求”
传统需求分析建模方法
思想：抽象与自顶向下的逐层与自顶向下的逐层分解
数据建模
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）节点
系统中的事件
短粗线，矩形
激发(点火)
数据字典
配合数据流程图，反映具体细节
数据元素：最小数据单元
数据流：有关的数据元素所组成的动态的数据结构
数据存储：数据结构载体，静态的数据结构
处理：具体处理逻辑
判定表和判定树
判定表
左上部：条件或数据元素名称
右上部：所有条件组合
左下部：处理活动名称
右下部：注明条件组合和相应活动对应关系
判定树
根节点：表示问题的名字
内部节点：表示条件
叶子节点：表示活动
2856
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
