软考-系统分析师-需求工程模块
2024-12-20 14:26:44 0 举报AI智能生成
软考-系统分析师-需求工程模块
作者其他创作
大纲/内容
概念：软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。
需求开发
需求获取
需求分析
编写需求规格说明书(需求定义)
需求验证
需求管理
定义需求基线
处理需求变更
需求跟踪
需求获取
需求获取方式
用户访谈
用户访谈是最基本的一种需求获取手段，为了进行有效的用户访谈，系统分析师需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作。
优点：具有良好的灵活性，有较宽广的应用范围。
缺点：用户忙，信息量大，记录困难，需要沟通技巧。
问卷调查
用户访谈最大的难处在于很多关键人员时间有限，不容易安排过多的时间。而且，如果用户较多，不可能--访谈。问卷调查可以有效地克服用户访谈方法中存在的问题。
优点：短时间内收集数据。
缺点：缺乏灵活性，信息不全面，无法了解细节问题。
采样
指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。
优点
加快了数据收集的过程，提高了效率。利用数理统计原理，减少数据收集的偏差
缺点
主观性强。
情节串联板
情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。
优点
用户友好、交互性强，对用户界面提供了早期的评审。
缺点
主观性强。花费时间，速度慢。
联合需求计划
联合需求计划(Joint Requirement PlanningJRP)是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程。
是联合应用开发(JointApplication Development, JAD)的一部分。
JAD是以小组形式定义和建立系统的，它是由企业主管部门经理、会议主持人、用户、协调人员、I人员、秘书等共同组成的专题讨论组。由这个专题讨论组来定义并详细说明系统的需求和可选的技术方案。
JAD的过程
确定JAD项目，主要指确定系统的范围和规范。
在JAD专题预备会上，会议主持人向参与者介绍项目和JAD专题讨论内容。
准备JAD专题讨论材料。
进行JAD专题讨论会
优点
用户参与，有利于消除矛盾信息。
缺点
会议的组织与相关人员的能力。
需求记录技术
卡片记录等
详细调查的方法也可以作为需求分析的方法如实地观察、收集资料等 也可以作为需求获取的技术。
需求分析
概念：需求分析就是提炼、分析和仔细审查已经获取到的需求，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。
需求分析的工作内容
绘制系统上下文范围关系图
数据流图
创建用户界面原型
分析需求的可行性
确定需求的优先级
为需求建立模型
创建数据字典
使用QFD
质量功能展开
将获取到的需求分成各个开发阶段需要完成的工作
需求分析方法
结构化方法
SA方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解了。
SA方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)
数据模型
ER图
功能模型
数据流图
子主题
数据流图的组成
①数据流：由一组固定成分的数据组成，表示数据的流向。每一个
数据流都有一个定义明确的名字。
数据流都有一个定义明确的名字。
②加工：描述了输入数据流到输出数据流之间的变换，即输入数据
流经过什么处理后变成输出数据流。每个加工都有一个名字和编号。
流经过什么处理后变成输出数据流。每个加工都有一个名字和编号。
③数据存储：用来存储数据。每个数据存储都有一个定义明确的名
字标识
④外部实体：是指存在于软件系统之外的人员或组织，它指出系统
所需数据的发源地和系统所产生的数据的归宿地。每个外部实体都
有一个定义明确的名字标识
所需数据的发源地和系统所产生的数据的归宿地。每个外部实体都
有一个定义明确的名字标识
数据流图的主要作用
① DFD是理解和表达用户需求的工具，是需求分析的手段。系统分析师可以
通过DFD与用户进行交流
② DFD概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也
是系统设计的重要参考资料，是系统设计的起点
③ DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
绘制数据流图的步骤
①画系统的输入和输出：在图的边缘标出系统的输入数据流和输出数据流。
这一步其实是决定研究的内容和系统的范围。在画的时候，可以先将尽可能
多的数据流画出来，然后再删除多余的，增加遗漏的。
②画DFD的内部：将系统的输入、输出用一系列的处理连接起来，可以从输入
数据流画向输出数据流，也可以从中间画出去
③为每一个数据流命名：命名的好坏与DFD的可理解性密切相关，应避免使用
空洞的名字。
④为加工命名：使用动宾短语为每个加工命名。
行为模型
状态转换图（STD图)）
通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为。
子主题
数据字典的内容
数据项
数据流
数据存储
数据加工(处理过程)
面向对象方法
运用面向对象方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系，最终产生一个符合用户需求，并能直接反映问题域和系统功能的面向对象分析模型及其详细说明。
统一建模语言
UML又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。
构造块
UML有三种基本的构造块，分别是事物、关系和图。
公共机制
主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制4种。
公共机制是指每个事物必须遵守的公共规则
规则
是某些事物应该遵守的约束或者规定。包括命名、范围、可见性、完整性和执行。
子主题
4种事务
结构事务
名词、静态部分、物理元素
结构事务
行为事务
动词、动态部分、行为
行为事务
分组事务
包
分组事务
注释事务
注解
注释事务
用例图（需求模型）
用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。
参与者是指存在于系统外部并与系统进行交互的任何事物。参与者可以由人、物、其他系统、时钟组成。
通信关联表示的是参与者和用例之间的关系，或用例与用例之间的关系。发现用例的方法可以采用“动词(短语)+名词(短语)”的形式。
用例是由系统执行的一系列动作，为相关的参与者提供其所期望的服务。
用例关系
包含关系 include
包含关系当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。
扩展关系 extend
扩展关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。
泛化关系 generalize
泛化关系是继承的反关系，用于描述父类与子类之间的关系。
类图（分析模型）
类图展现了一组对象、接口、协作和它们之间的关系。
子主题
类之间的关系
关联关系
是一种拥有的关系,关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。
子主题
子主题
聚合关系
共享聚集关系通常简称为聚合关系，表示类之间的整体与部分的关系。其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。
子主题
组合关系
是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
子主题
依赖关系
是一种使用的关系，即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖。可以简单的理解，就是一个类A使用到了另一个类B。
子主题
泛化关系
是继承关系的反关系，用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。
子主题
实现关系
实现关系将说明和实现联系起来。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。
子主题
对象图
描述一组对象及它们之间的关系。
对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图。
对象图一般包括对象和链。
子主题
顺序图（SequenceDiagram，序列图）
顺序图是一种交互图，交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。
交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
子主题
协作图
协作图又叫通信图(Communication Diagram)。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。
子主题
状态图
状态图(State Diagram)。状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。
子主题
行为的结果
活动图
活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。
活动图专注于系统的动态视图。
它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。
行为的动作
包图
包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
一个包图可以由任何一种UML图组成，通常是UML用例图或是UML类图。包图只是把某些类放在一个包中，因此可以看做是类图的一种。
部署图
部署图(Deployment Diagram)。
部署图描述对运行时的处理节点及在其中生存的构件的配置。
部署图给出了架构的静态部署视图通常一个节点包含一个或多个部署图
面向问题域的分析方法（PDOA）
需求定义
需求定义的过程也就是形成需求规格说明书的过程
需求定义的方法
严格定义方法
①所有需求都能够被预先定义。
②开发人员与用户之间能够准确而清晰地交流。
③采用图形(或文字)可以充分体现最终系统。
原型法
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善。
需求规格说明书SRS
需求规格说明书SRS是需求开发活动的产物。
内容
范围
引用文件
需求
合格性规定
需求可追踪性
尚未解决的问题
注解
附录
需求验证
需求验证也称为需求确认
需求验证/确定内容
(1)SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
(2)SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
(3)需求是完整的和高质量的。
(4)需求的表示在所有地方都是一致的。
(5)需求为继续进行系统设计、实现和测试提供了足够的基础，
验证方法
需求评审
SRS 的评审是一项精益求精的技术，
它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达
成共识的方法。
它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达
成共识的方法。
需求测试
软件测试应该从需求定义开始，如果在开发过程的早期就开始制订测试计划和进行测试用例
的设计，就可以在发生错误时立即检测到并纠正它。这样，就可以防止这些错误进步“放
大”，并且可以减少测试和维护费用。
的设计，就可以在发生错误时立即检测到并纠正它。这样，就可以防止这些错误进步“放
大”，并且可以减少测试和维护费用。
需求管理
在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。
需求管理的主要活动
需求变更管理
定义需求基线
即通过评审的SRS
变更申请
需求风险管理
需求跟踪
0 条评论
下一页
