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