业务分析师词汇和术语

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

活动图

A 模型 通过显示每个流程来说明流程和/或复杂用例的流程 活动 以及信息流和并发活动。台阶可以叠加在水平线上 泳道 执行这些步骤的角色。

活动

作为工作的一部分而执行的工作单元 倡议 要么 处理.

演员

与人类互动的人类和非人类角色 系统.

分配

看到 需求分配.

分析员

具有开发和管理职责的角色的通用名称 要求。其他名称包括 业务分析师,业务集成商,需求分析师,需求工程师和系统分析师。

协会

图表中两个元素或对象之间的链接。

假设条件

假设是影响因素,这些因素被认为是正确的,但尚未被证实是准确的。

属性

具有指定数据类型的数据元素,用于描述与概念或实体相关的信息。

基准线

的时间点视图 要求 经过审查并达成协议,可以作为进一步发展的基础。

标杆管理

一个比较 处理 要么 系统的成本,时间, 质量或其他领先同行的指标 组织机构 找出改进的机会。

黑匣子测试

编写测试时无需考虑软件的实现方式。这些测试仅显示预期的输入和输出。

集思广益

头脑风暴是一种团队活动,其目的是通过快速,非批判性地产生想法来产生广泛或多样的选择。

商业分析

业务分析是一组任务, 技术 曾经作为联络员 利益相关者 为了了解组织的结构,政策和运作 组织,并推荐 解决方案 使组织能够实现其目标 目标.

业务分析方法

一套 流程,模板和 活动 将用于执行 商业分析 在特定情况下。

业务分析沟通计划

通信类型的描述 业务分析师 将在 商业分析,这些通讯的收件人以及应进行通讯的形式。

业务分析计划

对计划活动的描述 业务分析师 将执行以执行特定于业务的分析工作 倡议.

业务分析师

从业者 商业分析.

商业架构

的子集 企业架构 定义了 组织当前和未来的状态,包括其策略, 目标目标,通过流程或功能视图的内部环境,业务运营所在的外部环境以及 利益相关者 受组织活动的影响。

商业案例

对与提议相关的成本和收益的评估 倡议.

业务约束

商业 约束 是对 由设计 组织 需要解决方案。业务约束描述了对可用解决方案的限制,或无法通过新解决方案的部署更改的当前状态方面的限制。也可以看看 技术约束.

业务领域

看到 .

业务领域模型

全部或部分内容的概念视图 企业 专注于 产品展示, 可交付成果大事记 对执行任务很重要 组织。域模型可用于通过业务和技术验证解决方案范围 利益相关者。也可以看看 模型.

商业活动

由人类启动的系统触发器。

经营目标

企业必须满足的状态或条件 视力.

业务需求

一种高级 业务需求 那是企业的声明 目的,或影响 应该有它的环境。

经营方针

业务策略是一种不可操作的指令,它支持 商业目标.

业务流程

一组已定义的临时或顺序协作 活动 由一个人以可重复的方式表演 组织。流程由以下人员触发 大事记 并可能有多种可能的结果。一个过程的成功结果将为一个或多个提供价值 利益相关者.

业务需求

提出更高层次的业务原理后, 组织 增加收入,避免成本,改善服务或满足监管要求。

业务需求文件

业务需求文档是 需求包 描述 业务需求利益相关者要求 (它记录业务感兴趣的需求,而不是记录业务需求)。

商业规则)

业务规则是受业务控制的特定,可操作,可测试的指令,并支持 商业政策.

能力

一个功能 组织 使它能够实现 商业目标 要么 目的.

基数

一个实体中一个实体的出现次数 数据模型 链接到第二个实体。基数在数据模型上显示,带有特殊的符号,数字(例如1)或字母(例如M表示许多)。

因果图

看到 鱼骨图.

变更控制委员会(CCB)

一小群 利益相关者 谁将就变更的处置和处理方式做出决定 要求.

变革驱动的方法论

A 方法 专注于快速交付 逐步增加能力并直接参与 利益相关者 收集有关解决方案性能的反馈。

检查清单

A 质量控制 技术。它们可能包括一组标准的质量要素,供审阅者用于 需求验证 需求验证 或专门开发以捕获项目关注的问题。

一组共享相同属性,操作,关系和行为的系统对象的描述符。类代表正在设计的系统中的概念。当用作分析时 模型,类通常也将对应于真实世界的实体。

类模型

一种 数据模型 将信息组描述为类。

一种用于表示计算机指令的编程语句,符号和规则的系统。

商用现货软件(COTS)

为特定市场开发和销售的软件。

竞争分析

结构化 处理 它抓住了行业的关键特征,以预测长期盈利前景并确定最重要竞争对手的做法。

约束

约束条件描述了对 不能满足业务或利益相关者的需求。

上下文图

一个分析 模型 说明 产品范围 通过显示环境中的系统以及给予和接收系统的外部实体(人员和系统)。

成本效益分析

进行分析以比较和量化进行更改或实施项目的财务和非财务成本 与获得的收益相比。

顾客

A 利益相关者 谁使用由某人提供的产品或服务 组织.

数据字典

一个分析 模型 描述系统所需的数据结构和属性。

数据实体

系统要存储的一组相关信息。实体可以是人,角色,位置,事物,组织,时间的出现,概念或文档。

数据流程图(DFD)

一个分析 模型 该图说明了发生的过程以及进出这些过程的数据流。

资料模型

一个分析 模型 描绘了数据的逻辑结构,与数据设计或数据存储机制无关。

决策分析

一种决策方法,用于检查和建模不同决策的可能结果。决策分析有助于在不确定条件下做出最佳决策。

决策表

一个分析 模型 它以易于理解的表格格式简洁地指定了复杂的业务规则或逻辑,并指定了业务规则中需要考虑的所有可能的条件和操作。

决策树

一种分析模型,可提供图形化替代 决策表 通过依次说明条件和动作。

分解

一种将问题细分为各个组成部分的技术,以便于分析和理解这些组成部分。

缺陷

一个缺陷 产品 要么 服务 会降低其质量或与所需的属性,状态或功能有所不同。也可以看看 需求缺陷.

可交付成果

任何独特且可验证的工作 产品 要么 服务 一方已同意交付。

设计约束

限制系统设计人员可用选项的软件要求。

期望的结果

满足以下要求将带来的商业利益 业务需求 和所需的最终状态 利益相关者.

开发者

开发人员负责构建软件应用程序。专业领域包括开发语言,开发实践和应用程序组件。

对话层级

一个分析 模型 该图显示了按层次结构排列的用户界面对话框。

对话图

一个分析 模型 说明了系统用户界面的体系结构。

发现会议

看到 需求研讨会.

文件分析

文件分析是 引出 需求s 通过研究可用的文档并识别相关信息来确定现有系统。

正在分析的问题区域。

领域主题专家(SME)

在调查的领域或领域具有特定专业知识的人。

启发

需求开发中的一项活动,该活动为 要求 然后使用 启发 从这些来源收集需求的技术(例如访谈,原型,便利的研讨会,文档研究)。

启发研讨会

看到 需求研讨会.

最终用户

直接与他人互动的人或系统 。最终用户可以是与系统交互的人员,也可以是向系统发送数据文件或从系统接收数据文件的系统。

企业

一个 组织单元, 组织,或拥有一组共同点的组织的集合 目标 并合作提供具体 产品展示 或服务 顾客.

企业架构

企业架构是对 组织的业务流程,IT软件和硬件,人员,运营和项目,以及它们之间的关系。

实体关系图

实体关系图是与所选问题域相关的实体的图形表示, 关系 他们之间,以及他们之间 属性.

评价

系统和客观的评估 确定其在实现目标方面的地位和有效性,并确定改进解决方案以更好地实现目标的方法。也可以看看 公制, 指示符监控.

事件

事件是发生的事 组织单元, 系统, 要么 处理 必须回应。

事件响应表

一个分析 模型 以表格格式定义 大事记 (即触发系统执行某些功能的输入刺激)及其响应。

进化原型

A 原型 根据用户的反馈不断进行修改和更新。

探索性原型

A 原型 开发以探索或验证 要求.

外部介面

与提议的其他系统(硬件,软件和人)的接口 系统 将与之互动。

可行性分析

看到 可行性研究.

可行性研究

对提议的替代方案的评估,以确定它们在技术上是否在限制范围之内。 组织 以及它们是否将为组织带来期望的收益。

特征

外部可见功能的紧密结合,应与 商业目标目标。每个功能都是逻辑上相关的分组 功能要求 要么 非功能性要求 粗略地描述。

鱼骨图

根本原因分析 识别观察到的问题的根本原因,以及 关系 在这些原因之间存在。

焦点小组

焦点小组是 引出 关于特定的想法和态度 产品, 服务 或互动小组环境中的机会。参加者在主持人的指导下分享他们的印象,喜好和需求。

力场分析

一种用于描述支持和反对变更的力的图形方法。涉及识别力,将其描绘在一条线的相对两侧(支撑力和相反力),然后估算每组力的强度。

功能要求)

产品 功能或产品必须为其用户执行的操作。

缺口分析

比较当前状态和期望的将来状态 组织 为了确定需要解决的差异。

词汇表

与业务相关的业务术语和概念的列表和定义 正在构建或增强。

目标

看到 商业目标.

水平原型

A 原型 该图显示了系统功能的较浅且可能较宽的视图,但通常不支持任何实际使用或交互。

影响分析

影响分析评估拟议变更将对企业产生的影响。 利益相关者 或利益相关者团体, 项目, 要么 系统.

实施主题专家(SME)

A 利益相关者 他将负责设计,开发和实施需求中描述的变更,并具有有关一个或多个解决方案组件的构建的专门知识。

包含的用例

用例由多个用例使用的一组通用步骤组成。

增量交付

在多个版本中创建可运行的软件,以便随着时间的推移分批交付整个产品。

指示符

指示器标识特定的数字度量,该度量指示实现影响,输出,活动或输入的进度。也可以看看 公制.

倡议

尽力而为 目标 要么 目的.

检查

正式类型的 同行评审 利用预定义和记录的流程,特定的参与者角色以及缺陷和流程的捕获 指标。也可以看看 结构化演练.

接口

在任何两个人和/或系统之间共享信息的共享边界。

互通性

系统通过交换数据或服务进行通信的能力。

面试

一种系统的方法 引出 通过询问相关问题并记录答复,在非正式或正式环境中来自一个人或一群人的信息。

迭代

A 处理 其中一个 可交付的 (或者 总体上)。每次迭代都是一个独立的“小型项目”,在其中进行了一系列活动,从而开发了一部分项目 可交付成果。对于每次迭代,团队计划其工作,进行工作并检查其质量和完整性。 (迭代也可以在其他迭代中进行。例如,需求开发的迭代将包括 启发,分析,规范和验证活动。)

知识领域

一组支持以下功能的相关任务: 商业分析.

经验教训过程

一种用于了解和改进流程的过程改进技术 处理 要么 项目。经验教训会议涉及一个特殊的会议,在该会议中,团队将探讨什么有效,什么无效,可以从刚刚完成的迭代中学到什么,以及在继续或重新开始之前如何适应流程和技术。

元数据

元数据是用于理解记录在网络中的信息的上下文和有效性的信息。 系统.

方法

一组流程,规则,模板和工作方法,规定了如何 商业分析解决方案的开发和实施是在特定的上下文中进行的。

公制

指标是指 指示符 组织想要在特定时间点完成的任务。

楷模)

开发了对现实的表示和简化,以将信息传达给特定的受众,以支持分析,交流和理解。

监控方式

监控是一个连续的收集数据过程,以确定 与预期结果相比已实施。也可以看看 公制指示符.

需求

看到 业务需求.

非功能性要求

质量属性,设计和实施约束以及外部接口 产品 一定有。

目的

目标或 公制 一个人或组织寻求见面以便朝着 目标.

面向对象的建模

一种软件工程方法,其中软件由封装成数据和功能组的组件组成,这些组件可以继承其他组件的行为和属性;并且它们的组件通过消息相互通信。在某些组织中,业务工程使用相同的方法来描述和打包业务的逻辑组件。

观察

观察是一种手段 引出 要求 通过对 利益相关者的工作环境。

运营支持

A 利益相关者 谁帮助保持 通过向以下人员提供支持来发挥作用 终端用户 (培训师,服务台)或通过使解决方案每天运行(网络和其他技术支持)来解决。

操作规则

商业规则 一个 组织 选择执行作为政策问题。它们旨在指导企业内部人员的行为。他们可能迫使人们采取某些行动,阻止人们采取行动,或者规定采取行动的条件。

机会分析

检查新业务机会以提高组织绩效的过程。

可选性

定义一个实体中实体之间的关系 数据模型 是强制性的。可选性以特殊符号显示在数据模型上。

组织

一个内部的自治单位 企业 在单个个人或董事会的管理下,具有明确的界限,可朝着共同的目标进行工作。组织是连续运作的,而不是 组织单元 或项目小组,一旦其解散, 目标 实现。

组织建模

用于描述企业内部存在的角色,职责和报告结构的分析技术 组织.

组织过程资产

小组内小组使用的所有材料 组织 定义,定制,实施和维护他们的 流程.

组织准备评估

一种评估,描述是否 利益相关者 准备接受与 并能够有效地使用它。

组织单元

在以下情况下的任何公认的人际交往 组织 要么 企业.

同行评审

一种验证技术,其中一小部分 利益相关者 评估工作产品的一部分以发现错误以提高其质量。

计划驱动的方法论

任何 方法 强调计划和正式文件用于完成的过程 项目 以及项目结果。计划驱动的方法论强调了在快速交付解决方案中降低风险和控制结果。

优先次序

确定一组项目的相对重要性以便确定其处理顺序的过程。

问题陈述

简短的陈述或段落,描述当前状态下的问题并阐明成功的方法 会看起来像。

处理

看到 业务流程.

工艺图

商业模式显示 业务流程 在跨职能,组织或职位角色的步骤和输入输出流方面。

工艺模型

视觉 模型 或一组相关活动或动作的顺序流程和控制逻辑的表示。

产品

A 或解决方案的组成部分 项目.

产品积压

一套 用户故事, 要求 要么 特征 已被确定为潜在实施方案的候选者,确定了优先级并进行了估算。

产品范围

特征 和功能 产品, 服务 或结果。

项目

为创造独特而付出的暂时努力 产品, 服务 或结果。

项目章程

项目发起人签发的文件或 赞助 正式授权项目的存在,并提供 专案经理 有权将组织资源应用于项目活动。

专案经理

利益相关者 由执行组织分配以管理完成项目所需的工作 目标.

项目范围

交付产品必须执行的工作 产品, 服务,或具有指定特征和功能的结果。也可以看看 范围.

原型

系统的部分或初步版本。

质量

一组固有特性满足要求的程度。

质量保证

为确保流程将交付满足适当质量水平的产品而执行的活动。

质量属性

的子集 非功能性要求 描述软件操作,开发和部署的属性(例如,性能,安全性,可用性,可移植性和可测试性)。

问卷调查

看到 调查.

调节器

A 利益相关者 具有解决方案或开发过程的法律或治理权限。

关系

一个定义 协会 在概念,类或实体之间。关系通常被命名并包括 基数 协会的。

关系图

业务 模型 可以从 关系 组织,外部客户和提供商之间存在的关系。

资料库

一种实际的或虚拟的设施,用于存储有关特定主题的所有信息,并且可供检索。

要求信息(RFI)

发出需求文件以征求供应商对拟议过程或产品的意见。当发行组织寻求比较不同的替代方案或对可用选项不确定时,使用RFI

征求建议书(RFP)

需求文件发布时, 组织 正在寻求供应商的正式建议。 RFP通常要求提案应在特定的 处理 并使用将根据正式评估方法进行评估的密封出价。

报价请求(RFQ)

非正式征集供应商的建议。

需求

  1. 一个人需要的条件或能力 利益相关者 解决问题或达成目标。
  2. 条件或 能力 必须由一个人拥有 要么 解决方案组件 以满足合同,标准,规范或其他正式施加的文件。
  3. 1)或2)中条件或能力的书面证明。

需求属性

元数据 与用于协助需求开发和管理的需求有关。

要求缺陷

由不正确,不完整,丢失或冲突的需求引起的需求错误。

需求分配

将需求分配给子系统和组件(即人员,硬件和软件)的过程。

需求发现会议

看到 需求研讨会.

需求文件

看到 需求包.

需求迭代

定义解决方案范围子集需求的迭代。例如,需求的迭代将包括:确定要关注的整个产品范围的一部分;为该部分产品确定需求来源;进行分析 利益相关者 并计划如何 引出 他们的要求,进行 启发 技术,记录需求并验证需求。

需求管理

控制需求开发的活动,包括需求变更控制,需求属性定义和需求可追溯性。

需求管理计划

的说明 需求管理 处理。

需求管理工具

一种将需求信息存储在数据库中,捕获需求属性和关联并促进需求报告的软件工具。

需求模型

使用文本和图表表示需求。需求模型也可以称为用户需求模型或分析模型,并且可以补充文本需求规范。

需求包

需求包是在文档或演示文稿中组合在一起的一组需求集,用于与 利益相关者.

需求质量

看到 需求验证 和需求验证。

需求风险缓解策略

对与需求相关的风险的分析,对风险进行排名并确定避免或最小化这些风险的措施。

需求签核

发起人或其他决策者对一组要求的正式批准。

需求跟踪矩阵

用于跟踪需求关系的矩阵。矩阵中的每一列都提供需求信息以及相关的项目或软件开发组件。

需求可追溯性

识别并记录每个需求沿袭的能力,包括其派生(向后追溯),分配(向后追溯)及其与其他需求的关系。

需求验证

所做的工作确保了 规定的要求 支持并与 目标目标 业务。

需求验证

为评估需求而进行的工作,以确保正确定义需求并达到可接受的质量水平。它确保对需求进行了充分的定义和结构化,以便解决方案开发团队可以在设计,开发和实施过程中使用它们 .

需求研讨会

需求研讨会是一个结构化的会议,由精心挑选的一组 利益相关者 协作定义和/或完善 要求 在熟练的中立调解人的指导下。

回顾性

看到 经验教训过程.

投资回报

对项目或投资的获利能力的度量。

风险

不确定事件或条件(如果发生)将影响提议的变更的目标。

风险缓解策略

看到 需求风险缓解策略.

根本原因分析

根本原因分析是对已识别问题的结构化检查,以了解潜在原因。

情境

一个分析 模型 描述了一系列响应事件的动作或任务。每个方案都是一个实例 用例.

范围

特定活动或感兴趣的主题所覆盖的区域。也可以看看 项目范围解决方案范围.

范围模型

A 模型 定义业务域或解决方案的边界。

次要演员

一个 演员 谁参加但不发起 用例.

顺序图

一种图表类型,显示参与交互的对象以及它们之间交换的消息。

服务

工作或代表他人进行的工作。

软件工程师

看到 开发商.

软件/系统需求规范

主要为以下目的编写的需求文档 实施中小企业 描述 功能性 非功能性要求.

解决方案满足 业务需求 通过解决问题或允许 组织 抓住机会。

解决方案要求

一个的特征 满足业务和利益相关者的要求。可以细分为功能需求和非功能需求。

解决方案范围

一整套功能 必须交付才能满足 业务需求。也可以看看 范围.

控制范围

控制范围是经理直接(或间接)负责的员工人数。

赞助

A 利益相关者 通过签约或付款来授权或使产品开发工作合法化的人。

利益相关者

利益可能受到 倡议 或对其影响。

利益相关者分析

识别工作 利益相关者 谁可能受到提议的影响 倡议 并评估他们的兴趣和可能的参与。

利益相关者列表,角色和职责指定

受业务需求或提议的解决方案影响的利益相关者列表,以及他们参与项目或其他计划的描述。

利益相关者要求

利益相关者要求是特定利益相关者或利益相关者类别的需求陈述。它们描述了给定利益相关者的需求以及该利益相关者如何与解决方案交互。利益相关者的要求是之间的桥梁 业务需求 以及各种 解决方案要求.

状态图

一个分析 模型 显示数据实体或类的生命周期。

状态机图

看到 状态图.

状态转换图

看到 状态图..

陈述的要求

利益相关者表达的一项需求,未经分析,验证或确认。陈述的要求通常反映了利益相关者的需求,而不是实际需求。

结构规则

结构规则确定什么时候是正确的或不正确的,或者什么时候该事物属于某个类别。它们描述了随时间变化的分类。

故事板

看到 对话层次对话图.

结构化演练

结构化演练是有组织的 同行评审 目的是发现错误和遗漏。它被认为是 质量保证.

主题专家(SME)

A 利益相关者 在问题领域或潜在的解决方案替代方案或组件方面具有特定的专业知识。

供应商

A 利益相关者 向组织提供产品或服务的人。

调查

一项调查执行了一系列书面问题,以 利益相关者 为了在相对较短的时间内从一大群人收集响应。

斯威姆兰

的水平或垂直截面 过程模型 显示哪些活动是由特定演员或角色执行的。

SWOT分析

SWOT是优势,劣势,机会和威胁的首字母缩写。它是用于了解影响因素以及它们如何影响主动性的模型。

系统

相互关联以实现目标的相互关联的元素的集合。系统元素可以包括硬件,软件和人员。一个系统可以是另一个系统的子元素(或子系统)。

技术约束

技术 约束 解决方案的设计存在一些局限性,这些局限性源于其实施中使用的技术。也可以看看 业务约束.

技术

技术改变了业务分析任务的执行方式或描述了任务输出可能采用的特定形式。

时间事件

时间触发的系统触发器。

测试仪

A 利益相关者 负责评估软件应用程序的质量并确定其缺陷。

一次性原型

A 原型 用于使用简单的工具(有时只是纸和笔)快速发现和阐明界面要求。通常在开发最终系统时将其丢弃。

时间盒

固定的时间来完成 期望的结果.

可追溯性

看到 需求可追溯性.

过渡要求

的分类 要求 描述了 为了促进从企业当前状态到期望的未来状态的过渡而必须具备的条件,但是一旦过渡完成就不需要了。

统一建模语言(UML)

一种非专有的建模和规范化语言,用于为面向对象的软件密集型系统指定,可视化和记录可交付成果。

用例

一个分析 模型 描述系统将要执行的任务 演员目标 该系统可以在一路上为那些参与者实现。

用例图

由UML定义的一种图表类型,可捕获所有 演员用例 参与 系统 要么 产品.

用户

A 利益相关者直接或间接访问系统的人员,人员,设备或系统。

用户验收测试

用户用来判断交付的系统是否可接受的测试用例。每个验收测试都描述了一组系统输入和预期结果。

用户需求

看到 利益相关者要求.

用户需求文件

A 需求文件 为用户受众编写的内容,描述了用户需求以及预期更改对用户的影响。

用户故事

为解决方案功能提供价值的高级,非正式,简短描述 利益相关者。用户故事的长度通常为一两个句子,并且提供了使开发人员能够估计实现它所需的工作所需的最少信息。

验证要求

已经证明可以提供业务价值和支持业务的需求 目标目标.

验证方式

检查产品以确保其符合预期用途并符合要求的过程。验证可确保您构建正确的解决方案。另见 需求验证.

方差分析

分析计划绩效与实际绩效之间的差异,以确定这些差异的严重程度,并根据需要建议采取纠正和预防措施。

验证

检查在给定的开发阶段生产的可交付成果是否满足前一阶段的条件或规格的过程。验证可确保您正确构建了解决方案。另见 需求验证 .

验证要求

已显示的需求证明了需求质量的特征,这些需求具有凝聚力,完整性,一致性,正确性,可行性,可修改性,明确性和可测试性。

垂直原型

A 原型 深入探讨界面,功能或两者的细节。

愿景声明(产品愿景声明)

简短的陈述或段落,从业务角度描述了所需软件产品的原因,内容和对象。

演练

同行评审的一种,参与者可以提出,讨论并逐步完成工作产品以发现错误。需求文档的演练用于验证需求的正确性。也可以看看 结构化演练.
 

工作分解结构(WBS)

项目团队要完成的工作的面向交付的层次分解,以实现项目目标并创建所需的交付。它组织并定义了项目的总范围。

工作产品

业务分析师在需求开发过程中使用的文档或注释或图表的集合。

©BA Times.com 2020

麦格雷戈徽标白色网站