(一)需求分析的目标和任务他的基本任务是准确回答“系统需要做什么”这一问题，即对目标系统提出完整、准确、清晰、明确、具体的要求
1、确定对系统的综合要求。 功能需求、性能需求、可靠性和可用性需求、错误处理需求、接口需求、约束(设计约束或实现约束描述设计或实现应用系统时应遵守的约束条件)、逆向需求)说明软件系统不应该做什么)，将来可能提出的
2、分析系统数据需求
3 .导出系统的逻辑模型
4、修改系统开发计划
(二)软件系统可行性分析；(三)需求获取访谈
正式访谈：系统分析员会问一些事先准备好的具体问题
非正式访谈：分析师会提出开放式问题，用户可以自由回答。
问卷调查：需要调查很多人的意见。
面向数据流，自上而下竭尽全力
推荐的应用规格说明技术
快速建立软件模型
(四)需求规格书是需求分析阶段获得的最主要文件。
结构化分析模型
(五)数据流建模；(数据流图)绘制系统逻辑模型。 图中没有具体的物理要素，只描绘了信息在系统中流动处理的情况。 是非常好的通信工具和软件设计的出发点。
1、数据流图符
正方形(立方体) :表数据的原点或终点
圆角矩形(或圆形)表示数据的处理
开口矩形(或两条平行线)可以是可表示数据存储(临时或永久)的文件、文件的一部分、表或记录的一部分。 不管怎么保存。 ）
箭头：表中的数据流，即特定数据流的方向(具有流的数据项或数据集合) ) )。
在数据流图表中添加符号
2、解法：
从问题描述中提取数据流图的4个成分
原点、终点、处理、数据流、数据存储
着手建立数据流图的基本系统模型
也就是说，一个原点处理一个个终点，确定边界
细化基本系统模型，描绘系统的主要功能
主要功能进一步细分
结束或进一步分解，涉及如何具体实现功能时，不再分解。
3、分层数据流图：需要采用分层结构数据流图来表达数据加工情况
上、中、下
分层数据流图的几个问题
号码设置父母2则子为2.1、2.2。
亲子图平衡
无需平衡本地数据存储
4、数据流图命名约定
数据流(用名词表示数据流(数据存储)的全部内容，不使用对特定成分有反应的“数据”“信息”等没有具体意义的名字
处理命名：为了避免使用“加工”“处理”等笼统词汇，使用动宾词组的整个反应处理功能不是部分功能； 通常只包含一个动词，否则分解
数据原点/终点：习惯在提问域使用生命，如“采购员”“学生”
5、数据流图的用途
作为交流信息工具
作为分析和设计工具：自动化边界划分
(六)实体-关系建模(E-R图)描述数据对象之间的关系
图中数据对象属性用"数据对象描述"表示
1、组成：数据对象：符合软件必须理解的信息表达，复合信息是一系列具有不同性质或属性的事务
2、数据对象之间的关系：一对一、一对多、多对多
3、属性：定义数据对象的性质
4、实体关系图
(七)系统行为建模1、软件行为模型：状态、事件、行为
状态：观察到的系统行为模式
事件：引起状态转移的外部事件的抽象
行为：达到某种状态时进行的动作
2、状态转移
图符号状态：
初始状态（只能有一个）
最终状态（可能多个）
中间状态
事件：
箭头：箭头上事件名。保安条件 [ ] 这种标志条件为真时导致改变
行为：
状态框内加 "do:行为名"
3、贼经典的例子
（八） 用例建模（用例图）
用例图描述外部执法者与系统的交互，表达系统功能，即系统提供服务
1、主要元素用例和执行者
用例：执行者与计算机一次典型交互，代表系统某一完整功能
执行者：描述与系统交互的人或物，代表外部实体（如用户，硬件、设备等）
直线表示关系
2、建立用户模型
①发现执行者
谁使用该系统；谁改变系统的数据；谁从系统取信息；谁需要系统的支持以完成日常任务；谁负责维护管理并保持系统正常运行；系统需要应付那些硬件设备；系统需要和哪些外部系统交互；谁对系统运行产生的结果感兴趣；
②获取用例
向执行者提出问题（从用户观点）
执行者需要获取何种功能，需要做什么；执行者需要读取产生、删除、修改或存储；系统发生时间和执行者间是否要通信；
用户观点非系统观点
③执行者间关联：
泛化关系：一般特殊关系（特殊者指向一般执行者）
④用例间关系
泛化关系
包含关系：一个基本用例包含另一个用例行为（要实现基本用例必须满足另一个用例行为）
扩展关系：允许一个用例扩展另一个用例提供的功能，与泛化类似，但有更多限制：基本用例必须声明“扩展点”，扩展用例只能在扩展点上增加新行为
3、我自己画的一个用例图---不对请留言指正，正在研究，有更好的画法，风格更好更正规的画法，请留言指正。
（九） 面向对象建模