导图社区 软件工程-需求分析
信息系统管理工程师-软件工程-需求分析
编辑于2019-10-05 02:58:16软件工程-需求分析
概念:将系统的、规范的、可度量的工程化方法应用于软件开发、运行和运行维护的全过程及上述方法的研究
组成
方法
完成软件工程项目的技术手段
工具
人们在开发软件的活动中智力和体力的扩展和延伸
过程
贯穿于软件开发的各环节,对软件开发的质量、进度、成本进行评估
需求分析
用户对新系统功能、行为、性能、设计约束等方面的期望
业务需求:用户对系统高层次的要求
用户需求:用户的具体目标
系统需求:从系统角度来说明的需求
质量功能部署QFD
常规需求:用户认为系统所具有的功能,实现越多越满意
期望需求:用户想当然认为系统所具有的功能,不实现会不满意
意外需求:用户要求范围外的功能和性能,实现用户会更满意便不会引想购买意愿
需求获取:用户访谈、问卷调查、采样、情节串联板、联合需求计划等
需求分析
把杂乱无章的用户要求和期望转换成用户需求
推荐的做法是对问题域进行抽象,将其分解成基本元素,然后对元素的关系时行建模
使用SA进行需求分析
核心是数据字典
数据模型
实体联系图(E-R图)
功能模型
数据流图
行为模型(状态模型)
状态转换图
OOA模型
用例模型
一种描述系统需求的方法
分析模型
描述系统基本逻辑结构
软件需求规格说明书
需求验证
又称为需求确认
一般通过需求评审和测试工作进地验证
UML
构造块
事物
结构事物
类
接口
协作
用例
构件
节点
行为事物
交互
状态机
分组中物
包
注释事物
关系
依赖
关联
泛化
描述一般化与特殊化的关系
实现
图
类图
对象图
构件图
组合结构图
用例图
顺序图
定时图
通信图
状态图
活动图
部署图
制品图
包图
交互概览图
规则
公共机制
面向对象分析
OOA是考虑做什么,OOD考虑的是怎么做
用例模型
识别参与者
合并获得用例
细化用例模型
书写用例规约
调整用例模型
包含
形式: A 《include》>B箭头指向: A基础用例 指向 B包含用例(父类指向子类)A、B区别:当多个用例中用到多个相同的事件流时,把这些事件流抽象出来就形成了抽象用例,称为包含用例(提高复用性,就像提取公因式一样),原始的是基础用例;A的实现必须要借助B的帮助(即没有B,A不能实现功能;没有A,B能实现功能);A知道B的存在,而B不知道A的存在要实现编辑用户用例,就是借助增加、删除、更改等子用例,没有这些包含用例则不能实现基础用例 编辑用户;而增加用户等子用例自己就能实现该功能,不用借助基础用例编辑用户)
扩展
形 式: A<《extend》 B箭头指向:B扩展用例 指向 A 基础用例(子类指向父类)A、B区别:如果一个用例混合了多个场景,那么这个用例可以分为一个基础用例和多个扩展用例(就像发送); 扩展用例是基础用例在某些条件下触发的,扩展用例可单独存在,基础用例的实现不一定用依赖扩展用 例; 扩展用例知道基础用例的存在,而基础用例不知道扩展用例的存在;图 解: (日结账单可以自己实现该功能,可能有时结完账要打印出来,这时就是基础用例触发扩展用例,而打印 用例不用借助日结账单用例就可以实现)
泛化
形 式: A-> B箭头指向: 父类指向子类A、B区别:B子类继承A父类所有(自己可能理解时会和包含能混,自我理解是包含没有继承父类的任何属性和方法)的属性和方法,而B子类可以有自己新的属性和方法; 父类是子类的泛化,子类是父类的继承图 解:(椭圆、三角形具有形状类的所有属性(边长,角)和方法)
分析模型
定义概念类
确定类之间的关系
为类添加职责
建立交互图
类之间的关系
关联
体现实例之间的关系
依赖
如果类B的变化会引起类A的变化,则类A依赖类B,如类B可以是类A的参数、数据成员、操作类等
泛化
反映父类和子类的关系,继承关系是泛化的反关系
共享聚合
简称聚合关系,反映类之间整体和部分之间的关系
组合聚合
与聚合关系的区别是,整合与部分会共存亡
实现