目录
论文写作相关知识点:
需求分析工作内容:
需求分析的方法:
数据流图的组成:
绘制数据流的步骤
面向对象的分析方法:
需求定义:
需求验证
结构化方法:
论文写作相关知识点:需求分析:需求分析就是提炼、分析和仔细审查已经获取到的需求,以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方
需求分析工作内容:- 绘制系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求的优先级
- 创建数据字典
- 使用QFD
- 结构化分析方法:SA方法的基本思想是自顶向下,逐层分解,把一个大问题分解成若干个小问题,每个小问题再分解成若干个更小的问题。经过逐层分解,每个最低层的问题都是足够简单、容易解决的,于是复杂的问题也就迎刃而解了。
- 数据流图从数据传递和加工的角度,利用图形符号通过逐层细分描述系统内各个部件的功能和数据在他们之间传递的情况,来说明系统所完成的功能。
- 数据流图的主要作用如下:
-
- DFD是理解和表达用户需求的工具,是需求分析的手段。系统分析师可以通过DFD与用户进行交流
- DFD概况地描述了系统的内部逻辑过程,是需求分析结果的表达工具,也是系统设计的重要参考资料,是系统设计的起点
- DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据
- 数据流:由一组固定成分的数据组成,表示数据的流向。每一个数据流都有一个定义明确的名字
- 加工:描述了输入数据流到输出数据流之间的变换,即输入数据流经过什么处理后变成输出数据流,每个加工都有一个名字和编号
- 数据存储:用来存储数据,每个数据存储都有一个定义明确的名字标识
- 外部实体:是指存在与软件系统之外的人员或者组织,它指出系统所需数据的发源地和系统所产生的数据的归属地。每个外部实体都有一个明确的名字标识
- 画系统的输入和输出
- 画DFD的内部
- 为每一个数据流命名
- 为加工命名
运用面向对象的分析方法,对问题域进行分析和理解,正确认识其中事物以及他们之间的关系,找出描述问题域和系统功能所需的类和对象,定义他们的属性和职责,以及他们之间所形成的各种关系,最终产生一个符合用户需求,并能直接反应问题与和系统功能的面向对象的分析模型及其详细说明
面向对象分析工作的两大成果:需求模型和分析模型
- 需求模型用例图建立,属于需求工作成果,为分析工作提供依据。构建用例模型的4个阶段:
-
- 识别参与者
- 合并需求获取用例
- 细化用例描述和调整用例模型
- 分析模型分析工作成果:用类图建立,建立分析模型的过程
-
- 定义概念类
-
-
- 阅读和理解需求文档或用例描述
- 筛选出名词短语,建立初始类清单
- 候选类:显而易见类、明显无意义类和不确定类
- 舍弃明显无意义的类
- 小组讨论不确定类别的类,直到将他们都合并或调整到其他两个类别,并进行相应的操作
-
-
- 确定类之间的关系
-
-
- 当完成了类的寻找工作之后,就需要理清这些类之间的关系,类之间的主要关系有关联、依赖、泛化、聚合、组合和实现
-
-
- 为类添加职责
-
-
- 类的职责包括两个方面内容:一个是类所维护的知识,即成员变量或属性;另一个是类能够执行的行为,即成员方法或责任
-
-
- 建立交互图
-
-
- 多个对象的行为通常采用对象交互来表示,可以使用uml的顺序图、活动图、通信图等
-
- 严格定义法
-
- 所有需求都能够被预先定义
- 开发人员与用户之间能够准确而清晰地的交流
- 采用图形或文字可以充分体现最终系统
- 原型法:原型法的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始,允许用户在开发过程中提出更好的要求,根据用户的要求不断地对系统进行完善
- 需求规格说明书SRS是需求开发活动的产物
-
- 范围
- 引用文件
- 需求
- 合格性规定
- 需求可追踪性
- 尚未解决的问题
- 注解
- 附录
需求验证的方法的有两种
- 需求评审,需求评审就是需求开发阶段结束前进行技术评审,评审的对象就是SRS。对SRS进行评审可以发现那些二义性的或不确定性的需求,为项目干系人提供在需求问题上达成共识的方法,技术评审可以分为以下三种类型
-
- 评审:评审是指一次正式的会议,在会议上向用户或其他项目干系人介绍一个或一组工作产品,以征求对方的意见和批准
- 检查:检查是一种 正式的评估方法,将由非制作者本人的个人或小组详细检查工作产品,以验证是否有错误、是否违反开发标准、是否存在其他问题
- 走查:是一个评审过程,由某个开发人员领导一个或多个开发团队成员对它的工作产品进行检查,由其他成员对技术、风格、可能的错误、是否违反开发标准和其他问题提出意见
- 正式评审,是一种结构化的评审技术,一般通过会议的形式来进行评审,需要经过以下过程:
-
- 计划,首先要对评审定制计划,以确定评审的重点和范围,并确保所有参与者理解自己的角色和评审的目标
- 准备:评审之前,应该收集要评审的工作产品和所有背景资料,并分发给评审参与者
- 进行评审,要进行成功的评审,首先,评审小组人员应理解评审流程,理解自己的角色,一般来说,评审流程是一个重复进行的循环过程,包括评审员提出问题,讨论问题,同时对问题进行确认,确定缺陷(需要解决的地方),直到没有确定的问题时再继续下一步;其次,会议主持人(协调员)要确保评审按议程进行,并以当前的主题为重点。主持人应该确保对枝节问题的讨论不会使评审脱离正轨,而且所有评审人员都以平等的身份参加讨论;最后,在评审的过程中,要注意确认问题而不是试图解决问题,要对所有问题和讨论做好记录
- 对评审结果采取行动,评审结束时,要确定问题列表的优先顺序,并跟踪问题以及解决办法
- 需求管理,主要的活动有:变更控制、版本控制、需求跟踪和需求状态跟踪
-
- 需求变更管理过程
-
-
- 问题分析和变更描述,需要识别和分析需求问题,形成明确的变更协议,以检查他的有效性,从而产生一个更明确的需求变更提议
- 变更分析和成本计算,使用可追溯性信息和系统需求的一般知识,对需求变更提议进行影响分析和评估,变更成本计算应包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认,应该进行是否执行这一变更的决策
- 变更实现,这要求需求文档和系统设计以及实现都要同时修改
-
-
- 版本控制,主要包括需求文档的版本
- 需求跟踪:可以使用需求跟踪能力链进行客户需求与下一级工作产品的双向跟踪
- 需求状态跟踪:定义需求状态,要求的每一个状态,需求的状态可以分为已变更,未变更等;变更控制委员会负责对变更进行决策,变更控制委员会的成员来自:产品或计划管理部门、技术支持部门、开发部门、测试或质量保证部门、市场部门或客户代表、制作用户文档的部门;
结构化方法也称为生命周期法,由结构化分析、结构化设计和结构化程序设计三部分组成,结构化方法基本思想是将系统的生命周期划分系统规划、系统分析、系统设计、系统实施、系统维护阶段。结构化方法遵循系统工程原理,按照事先设计好的程序和步骤,使用一定的开发工具,完成规定的文档,在结构化和模块化的基础上进行信息系统的开发工作
结构化方法的优点:开发目标清晰化、开发工作阶段化、开发文档规范化、设计方法结构化。缺点:开发周期长、难以适应需求变化、很少考虑数据结构
结构化开发对应的开发模型是瀑布模型,在结构化开发中会使用数据流图、ER图、状态转换图、模块结构图、流程图等工具