介绍

参与PLM互操作性多年来，我一直处于不同学科和知识社区的交汇处，如果愿意应对与数字化相关的新挑战，这些学科和知识社区将越来越需要有效合作。

更准确地说，可以考虑 2 个群体：从事产品工作的工程师和从事企业信息系统领域工作的工程师。我们将描述它们中的每一个，然后看看当它们在敏捷环境中一起工作时会发生什么。Sparks 的 Enterprise Architect 将用于我们研究,当他们必须使用异构模型库方法、工具和语言进行协作时，研究气潜在的问题。

产品工程师

工程师群体一直在采用计算机辅助设计、制造和支持，越来越依赖商业软件产品上架 (COTS)，从电子文档中纸质文档的转换发展到允许用数字模型取代物理模型的行为模型，现在可以用来减少依赖高级模拟的测试。他们越来越依赖基于模型的系统工程，这意味着多种建模语言和解决方案，用于机械设计、电子、热力学和许多其他工程领域，这些领域都需要针对其特定目的对产品进行特定表示。所有这些表示构成了产品的整体模型（或超模型，即 一组一致的多个表示），这些表示应该是一致的：：产品本身是各种版本化项目的集合，这些项目本身可以是标准部件（例如船员）、由某一层（如发动机）提供的设备或最终为产品专门设计和制造的零件（制造或购买策略），必须仔细管理这些部件的模型，以确保整个产品的模型正确组装这些部件的模型，并在配置中进行适当的版本控制和管理。如果不是，则存在因使用不适当版本的模型而导致的高风险，这对于关键系统（即危害人员）和企业的竞争力（即由于错误要做几次工作）。一个特定的工程师群体是处理系统建模的人，它依赖于 SysML（系统建模语言），旨在为产品系统定义组织为功能分解的预期功能，以及为确保这些功能而使用的技术解决方案适当的方式（通过验证和确认），要制造或购买的解决方案组件的规格，然后在生产它们时进行组装（例如制造过程）。然后将对生产的系统进行测试并交付给客户，其中包含确保其正常运行所需的所有内容（培训、使用和维护指南等）。此外，当必须更换磨损或损坏的零件时，应确保有关备件可用性的后勤支持。然后，系统工程师会考虑不同的产品故障以及相关的安装/卸载过程，这些故障对于生产和维修来说是完全不同的。越来越多地，由于产品的某些部件（例如使用寿命多年的大型游轮的电子/通信装置）已经过时，因此在所售产品的使用寿命期间提供升级这些部件的方法以避免快速过时变得越来越重要。。这是一项新的挑战，这是一个新的挑战，它将意味着系统工程流程的创新和新业务模式的创建，有时由于数字化的影响而具有破坏性的商业模式。由于产品的某些部件（例如使用寿命多年的大型游轮的电子/通信装置）已过时，因此在所售产品的使用寿命期间提供升级这些部件以避免快速过时的方法变得很重要。这是一项新的挑战，将意味着系统工程流程的创新和创建新的，有时由于数字化的影响而具有破坏性的商业模式。

企业信息系统工程师

企业信息系统领域的工程师人数。他们必须为企业的每一个与产品或支持直接相关的功能提供准确的支持，以确保构成信息系统的应用组件的开发、实现和操作支持，模型工厂，例如所有支持生产不同所需模型的东西，用于企业的产品、企业的流程或企业的资源。这些人群也一直采用基于模型的方法，依赖于统一建模语言等标准。UML 的演进一直遵循社区的实践，开始首先支持软件产品的设计、生产和支持。考虑到企业信息部对 COTS 的使用，我们可以认为它们是类似的企业产品设备：它们将被购买、部署、集成和配置，以确保感兴趣的系统（企业和模型工厂的信息系统）是在适当的支持、一致和高效的情况下正确设计、开发、部署、制定和运行。当然，它伴随着成本降低目标的压力，产品开发周期的缩短，尽管COTS和COTS市场日益复杂，尽管信息和通信技术的变化总是在加快步伐，尽管当今经济的全球不确定性（我们处于一个VUCA世界——波动性、不确定性、复杂性和模糊性）。在这种情况下，该群体处于持续学习模式，其流程应该可以轻松且频繁地重新配置，以便能够适应不断变化的环境。这可能是“大规模敏捷”和“数字化”趋势成功的原因，有时很难区分真正的需求或趋势。许多企业都知道他们必须转变自己才能面对新出现的挑战。但是这条路是艰难的，当需求没有很好地沟通和理解时，可能会导致戏剧性的局面。对于转型，他们必须依赖外部顾问和服务提供商，他们销售他们可以支持企业进行此类转型，但他们必须了解他们所支持的企业的特定市场需求和实践。它们自己也在跟随领域的趋势和不断发展，采用相互竞争的做法和框架。如果管理不当，可能会导致企业信息系统环境更加复杂，带来更多的问题而不是解决方案。在这种情况下，企业建模和相关实践以及标准化流程和语言可以帮助处理复杂性，并促进不同利益相关者之间的沟通，尤其是不同类型的架构师（企业、领域、业务流程、解决方案、基础设施） )，采用基于模型的方法来确保全局一致性和与业务目标的一致性。

轻松协作？

一个经常发生的问题是：当使用企业建模 和 ArchiMate 的企业信息系统群体遇到采用 MBSE 和 SysML 的产品工程师群体时，为了协作而使用的语言和方法框架可能会发生一些冲突，每个社区都考虑自己的方法框架和使用的语言，以满足这两个群体的所有需要。不幸的是，情况并非如此，因为他们考虑的利益体系并不相同，而且他们的组织和职责边界不同，尤其是在当今的矩阵或网络组织中。当这两个群体相遇并必须协作时，，首先要解决的一个具体问题是如何处理需求工程。我们应该用什么？第一代还是第二代的应用和语言？如何捕捉需求？如何描述它们各自感兴趣的系统、它们的功能和物理分解、每个社区的相关过程等？当每个群体的语言在描述需求、用例、用户故事或需求时有一些重叠时，应该使用哪种通用语言进行协作？应该使用哪种公共语言来进行协作？本文的这一部分是关于一项研究，旨在比较每个社区的标准化语言，以及来自规模敏捷或精益趋势的新兴语言如何相互匹配。

采用的方法

为了比较每个社区的标准化语言以及来自大规模敏捷或精益趋势的新兴语言如何匹配在一起，采用的方法如下。软件产品 EA 被选中，作为属于依赖对象管理组的模型驱动架构框架和相关标准化规范的建模平台系列的 COTS 之一。除了支持软件工程 (UML) 和系统工程 (SysML) 语言之外，它们还支持使用其他几种领域特定语言，无论是否标准化。特别是，它包括 ArchiMate，用于企业建模，这是一个开放组的规范，并构成企业架构师的事实上的标准。它附带了一个ArchiMate模型交换规范，企业架构师也支持该规范。

当企业信息系统部门的企业架构师必须与程序的系统工程师协作时，所使用的工具/语言分别在我们的场景 Sparx Enterprise Architect (EA)/ArchiMate 和 EA-CAMEO 工具链/SysML 中。使用的标准流程不同。在两者之间，一些“敏捷”工具为用户故事提供看板。

ArchiMate

EA 支持使用 ArchiMate 语言进行建模。提出了两种结构来处理需求：ArchiMate:Requirement 和 ArchiMate:Constraint。

ArchiMate 需求规范：

定义：" 需求" 表示架构必须满足的需求声明。需求对这些元素的属性进行建模，这些元素是实现由目标建模的“目的”所需要的。在这方面，需求代表了实现目标的.

类别：动机

示例：“指派个人助理”、“提供在线作品集服务”、“提供在线信息服务”、“使用开源软件”

ArchiMate 约束规范：

定义：“约束被定义为对系统实现方式的限制。这可能是对系统实现的限制（例如，要使用的特定技术），也可能是对实现过程的限制（例如，时间或预算限制）。”

类别：动机

示例：“应用程序应在Java中实现”、“成本应低于预算”、“仅限 iPad 版本”、“必须使用 MIT 许可证”

如果前面列表中的任何模型元素可以与需求或约束相关，那么来自另一个模型元素的两个更专业的关系是影响和实现关系。

对于其他 Motivation 建模元素，不存在实现，我们只有影响关系。利益相关者和差距建模元素（仅无类型关系）和需求/约束本身除外，它们支持组合、聚合和专业化关系。

相反，需求和约束可以影响目标、结果和原则。它们可以影响驱动因素、价值、评估和意义。它们可以由其他要求或约束组成或聚合。最后，它们可以与模型的任何其他元素相关。

没有什么可以阻止通过构构造型（ArchiMate 规范的最后一个版本 - 即 3）专门化这些关系，即使不是所有工具都支持（特别是 Archi）。但是，也可以使用捕获关系类型的属性来标记关系，然后使用来自其他语言或其他流程/方法/框架的分类来专门化关系。特别是，对于非功能性需求，存在来自许多需求分析框架的许多分类。它们都可以在模型中捕获。在这种情况下扩展可视化建模符号非常有用吗？不太确定，因为它会带来一种风险，即需要知道和记住许多符号。可以建立一些约定，包括在名称中指示关系的类型（但也包括需求），使用定型表示法或使用实例化表示法。另一种方法可以包括创建专用于仅捕获某种需求的视图。另一种方法可以包括使用“分组”，表示在可视化表示上分组的需求类型。如果通过允许基于属性查询的工具提供模型，并在查询的基础上创建一些报告，那么用户将很容易管理许多分类的需求、约束及其与模型其余部分的关系。

所有这一切（除了构造型）都是使用 Archi 和 EA 实现和交换的。出于这个原因，我不建议使用构造型。如果大多数 UML 建模环境（包括 EA 以及大多数 UML 建模环境，如 CAMEO、Modelio、Mega 等）都支持，则其他企业建模或管理工具不一定支持它们。此外，扩展可视化语言可能不利于简单性和互操作性，而使用准确属性的标记可以响应需要，而不需要额外的开发。

以下快照显示了具有属性 RequirementType 和值“Functional”的特殊需求和约束。让我们注意 Archi 允许在模型窗格中过滤它们。

下一个快照显示了它在 EA 中的样子，知道这是根据 Open Group 提供的 ArchiMate 模型交换的开放规范进行导入/导出的保留。

EA 和捕获需求和要求的另一种方式

EA 支持允许捕获需求的其他标准化语言（SysML、UAF 等）。它还提出了默认的领域特定语言，这些语言不是标准化的，但支持需求分析和项目支持，传统的或基于敏捷实践（即使用看板、用户故事或Epic）。

以下是来自系统工程社区的统一架构框架的建议。您可以看到需求、约束、业务需求和业务约束建模构造。

上图显示了用于捕获需求的 EA 特定配置文件。它提供了许多其他专门的建模需求构造，例如功能、非功能、业务、用户、架构、实现、监管和安全需求。它添加了一个检查表特性，允许捕获需求是否是原子的、可实现的、内聚的、完整的、当前的、独立的、可修改的、可跟踪的、明确的或可验证的，因此执行良好的需求分析所需的大部分内容。它看起来像 SysML，具有更多类型的专用需求建模构造，知道作为 UML 的 SysML 是可扩展的，并且可以支持扩展。它还支持标记，如 UML。

存在其他方法来捕获功能需求。在 UML 中，可以依赖用例，并使用要支持的业务流程的参与者，通过基于使用 UML 的活动建模的这些流程的表示来将它们上下文化。

使用敏捷方法，可以通过用户故事和epics收集需求收集。不存在用于此的标准化语言。在 EA 中，提出了两种配置文件，一种用于项目管理，作为建模构造特征、用例、用户故事、Epic、Sprint、任务和变更。它们是捕获利益相关者想要对项目生成的系统做什么或要做什么的方法。另一个与看板相关的配置文件仅限于变更、缺陷、功能和用户故事建模构造，以支持敏捷和精益方法。

请注意，在使用 Epic、用户故事、用例和功能时，应该存在一些层次结构和粒度级别。从不同的实践来看，它应该反映我在提供的列表中采用的顺序，从更粗的颗粒到更细的颗粒。

最后一种方法是捕获需求，它包括捕获场景，即使用文本描述或结构化规范以及一组步骤。

如前两个图所示，EA 也支持它。

请注意，捕获用于描述任务定义的步骤也是 SPEM 语言的一个特性，SPEM 语言是 OMG 用于建模实践的标准化语言。我们还要注意，EA 也支持 SPEM。

SPEM 非常适合“方法和工具”团队，必须定义工具应该如何用于支持常见实践。

如果必须互连所有这些语言，我的建议应该大致如下所述。

无论用于捕获需求的语言是什么，ArchiMate 都支持通过标记捕获所有专业化，因为知道不同采用的过程和实践可能会导致使用许多不同的过程和分类进行组合。因此，当必须聚合所有这些而不对每个人强加相同的选择时，让我们使用最简单的结构集，并在需要和有用的时候反映具有多个属性的不同类型的需求分类（让我们精益求精）。

在查看Epics、用户故事或用例时，大多数情况下它们都是文本的。此外，ArchiMate 根据生成的视图和考虑的视图的粒度级别，可以将所有这些都反映在一个模型中，该模型非常适合反映业务、信息系统和技术架构师的视图，处于企业、程序、规程、流程所有者、用户或操作员级别。它还可以根据产生的视图，与架构或实现相关。

因此，在不愿意替换所有隐含的利益相关者和架构师类型的特定语言的情况下，它表明 ArchiMate 非常准确地反映所有观点，并最终聚合每个人使用的不同需求分类，确保以简单的方式捕捉它们（注释）而不会重载要使用的视觉语言。

在EA这样的环境中，还可以很容易地跟踪每个社区产生的需求，即使用SysML的系统工程师、使用UML或敏捷社区产生用户故事和Epics的软件工程师，并将它们与将从中派生的ArchiMate需求相关联。

非常重要的是明确地将所采用的实践形式化，而不愿意将其统一起来，因为要知道，在当前的现实世界中，一切都可以统一和整合，这只是一种乌托邦思维。

结论

在本文中，我们描述了两个使用不同语言和实践来捕捉需求和定义需求的社区：产品工程师/架构师和信息系统工程师/架构师。当不得不一起工作时，可能会导致一些冲突：使用哪个工具？哪种通用语言？如何处理需求工程？

然后，我们描述了如何使用ArchiMate和其他语言（标准化与否）、支持系统工程师、软件工程师或敏捷/精益项目经理捕获需求。ArchiMate似乎是一个很好的方法，可以将需求和需求集合在一起，然后将它们附加到所有涉众的不同视图和观点，以及任何规模的架构模型的任何元素。

在任何支持不同语言（EA 只是其中一种）的建模平台上，应该可以正确地关联模型，而且还可以聚合和关联不同类型的需求和需求，无论它们的来源是什么，以检查其与相关组织动机的一致性和准确性：不仅是企业，还包括项目和供应链的所有成员。