产品元素和连接

产品系统由产品要素和两种联系组成：要素之间的联系，以及系统环境中要素与事物之间的联系。 可以受系统影响或可以影响系统的那部分环境称为“上下文”。

元素之间的连接包含交互和关系（Hybertson 2009）。 连接不仅仅是一个接口。

交互发生在系统内部或外部元素之间的 界面 上，可以定义为数据、材料、力或能量的交换。 具有交互性质的连接可以在各种工程工件中表示：原理框图、数据流图、自由体图、接口控制图、端口规范、能量传输图等。 产品系统工程 (PSE) 通常在接口控制文档、接口设计文档、接口需求文档或等效文档中定义交互。

连接还包括元素之间的关系。 这些关系可以是空间的、运动相关的、时间的或社会的。

空间关系：

• 一个元素在另一个元素之下
• 两个元素 相距 x 个单位
• 一个元素在另一个元素之内

运动相关的关系：

• 两个元素的相对速度为 v 个单位
• 两个元素之间的相对加速度是 一个单位

时间关系：

• 一个元素先于另一个元素存在
• 两个元素必须同时存在
• 两个元素必须在时间上相隔 t 个单位

社会关系：

• 人为因素对系统有一种特殊的感觉
• 一个人类元素拥有另一个（非人类）元素
• 人为因素以特定方式理解系统的操作

与时间无关的关系仍然会随着时间而改变。 例如，在一种操作模式期间位于另一个元素内部的元素可以在不同的操作模式期间位于它之外。 因此，不应假设非时间关系在时间上必然是静态的。

关系可以在工程工件中表示，包括时序图、时间线图、任务参考配置文件、能力路线图和项目进度表。

社会关系包括人类因素在系统中所扮演的角色之间的隐含或明确的社会义务或期望。 可以为这些角色分配不同的权限、职责和责任。 请参阅文章Team Dynamics 中有关组织行为的讨论 。 在设计这样的产品系统时，可能需要考虑组织行为理论和人为因素。

人类与系统的非人类元素之间也可能存在社会关系。 这可能涉及人类如何“感受”系统中的事物，甚至可能涉及整个系统。 感兴趣系统内部或外部的人可能对系统如何运行、其局限性和能力以及安全有效地运行它的最佳方式有不同程度的“理解”。 “所有权”关系在确定谁可以操作或更改系统的某些配置或模式等方面可能很重要。

产品系统中有许多这样的社会关系，在执行 PSE 时常常被忽视或误解。 社会关系可以影响产品系统的整体性能或行为，直至决定其成败。

核心产品及其赋能产品和运营服务

各种系统（它们本身就是产品或服务）支持产品的开发、交付、运营和最终处置，如图 1 所示。支持系统的概念在 ISO/IEC 15288 标准 (2015) 中定义。

图 1. 支持系统示例（Lawson 2010）。 经 Harold “Bud” Lawson 许可转载。 所有其他权利均由版权所有者保留。

在图中，感兴趣的系统 (SoI) 在使用阶段作为交付产品或提供的服务投入运行，而在支持阶段同时提供维护和物流（由产品维持系统提供）。 这两个阶段通常是并行执行的，它们提供了观察产品或服务属性或操作和支持方式的任何变化需求的机会。 进行更改会迭代生命周期并产生新的或改进的产品或功能。

交付的产品及其支持系统共同形成了一个更广泛的兴趣系统 (WSOI)。 项目设计使能系统是一种基于企业的系统资产，它建立了组织项目的策略和方法，以便在整个生命周期内执行。 在许多较大的组织中，这种类型的支持系统是制度化的，可以基于项目管理协会 (PMI) 的建议。

产品系统应被视为使能服务系统。 也就是说，一旦部署，产品系统就会提供有助于企业运营的服务。 对 收单方 而言，SoI 为用户提供运营服务。 这在几个层面上都是正确的：

• 硬件和软件产品用于提供服务系统，
• 企业将产品整合为系统资产，并使用它们来实现运营，以及
• 提供的产品集成到系统的系统中。

产品架构、建模和分析

IEEE 标准 1471-2000 将架构定义为“体现在其组件中的系统的基本组织、它们之间的关系以及与环境的关系，以及指导其设计和发展的原则”（IEEE 2000）。 同样，ISO/IEC 42010-2011 将架构定义为“系统在其环境中的基本概念或属性，体现在其元素、关系以及其设计和演进的原则中”（ISO/IEC 2011）。

产品的目的（利益相关者的需求）由产品系统（SoI）实现。 由于产品系统由不同的实体（组件、组件、子系统、信息、设施、流程、组织、人员等）组成，这些实体共同产生任何实体都无法单独实现的结果，因此构建产品是基于整个系统的方法。 使用整个系统方法进行架构意味着定义、记录、设计、开发、制造、分发、维护、改进和证明产品目标的正确实施，包括功能（“什么”）、行为（使用或预期操作）、逻辑（实体之间的交互和关系）和物理构造（Wasson 2006；Maier 2009；Blanchard 和 Fabrycky 2011）。

系统架构师从最高抽象级别开始，在识别组件、组件或子系统之前，专注于需求、功能、系统特征和约束（关注点）。 这是系统视图，用于表示利益相关者的市场服务描述或运营概念（对机会/问题空间的理解）。

随着对需求的更好理解，接下来要记录的是不同抽象级别的架构描述，代表各种利益相关者的利益。 这些是架构模型。 它们以产品系统的详细系统、操作、行为和物理要求的形式为产品目的定义可能的解决方案空间。

然后使用不同的建模技术来分析不同类型的需求。 对于操作场景和不同的操作模式，有层次分解和分配、架构框图（ABD）、功能框图（FBD）、功能流程图（FFBD）和用例图。 对于硬件和/或软件组件之间的交互和关系，有序列图、活动图、状态图和数据流图。 有关模型和建模的介绍，请参见（Maier 2009）第 8 章。

对解决方案空间的分析可以生成详细的技术规范、工程图、蓝图、软件架构、信息流等，这些都描述了产品系统中的实体。 一个实体的需求限制了它的属性和特征、性能水平、操作能力和设计约束。 在设计和集成期间，实体特征可以追溯到需求（需求 可追溯性 是 SE 的一个关键方面）。 在需求阶段创建的验证和确认计划是测试认证产品是否达到预期目的的基础。

总的来说，发生的事情是将一组需求转化为满足利益相关者需要的产品和过程。 该架构由一组模型表示，这些模型传达了产品意图和目的的集成视图，以及所有不同参与实体之间所需的交互和接口。 产品的目的是根据业务目标（市场、成本、功能、性能和交付时间）来阐明的。 这组模型包括足够的多样性，可以将信息适当地传达给利益相关者、设计师/开发人员、专业工程、运营、制造商、管理人员以及营销和销售人员。

已经开发了不同的架构框架来指导产品团队为商业和公共企业定义产品架构。 一般来说，架构框架描述了一个“视图”，意思是“从一组相关的利益相关者关注点的角度代表整个系统的模型集合”。 架构框架的主要例子是 Zachman 框架 (Zachman 1992)、开放组架构框架 (TOGAF) (TOGAF 2011)、增强型电信运营地图 (e-TOM)，仅举几个商业领域的例子。 对于公共企业，一些架构框架包括国防部架构框架 (DODAF 2.0) (DoD 2010)、联邦企业架构框架 (FEAF) (FEA 2001)、

获得的产品和提供的产品之间的差异在定义产品系统需求方面起着重要作用。 被收购产品由收购方直接进行生命周期管理； 例如，获得的防御系统由国防机构定义、开发、测试、拥有、操作、维护和升级。 请参阅此 KA 中 的文章 产品系统工程关键方面。

图 2. 系统架构描述元素（改编自 Wasson 2006）。 经 John Wiley & Sons Inc. 许可转载。版权所有者保留所有其他权利。

专业工程集成

INCOSE SE 手册 将专业工程定义为：

“分析系统的特定功能，需要特殊技能来识别需求并评估它们对系统生命周期的影响。”

属于这一概括性定义的专业领域包括后勤支持、电磁兼容性分析、环境影响、人为因素、安全和健康分析以及培训。 感兴趣系统的独特特征、要求和设计挑战都有助于确定适用的专业领域。

许多专业工程领域对于从事产品系统开发、部署和维护工作的系统工程师来说通常很重要。 例如，后勤支持对于需要维护和维修的现场产品系统至关重要。 支持系统所必需的服务、材料、零件和软件的交付必须在开发活动的早期考虑。 在系统要求和概念定义完成之前，通常应该考虑这些因素。 为了在早期充分整合这些专业学科，系统工程师需要知道哪些专业与正在开发的系统相关，它们如何与系统工程过程相关，以及如何将它们整合到生命周期过程中。

对于具有大量硬件内容并在具有挑战性的环境中运行的产品系统，通常必须考虑以下专业工程领域：

• 可制造性，
• 可靠性和可维护性，
• 认证（在人身安全成为问题的情况下必不可少），
• 后勤支持，
• 电磁兼容性（如果它们辐射），
• 对环境造成的影响，
• 人为因素，
• 安全和健康，以及
• 训练。

必须理解和考虑这些专业领域与系统工程过程的关系。 关系的关键方面是：

• 当需要考虑专业时，
• 它提供了哪些基本数据或信息，
• 在系统工程过程中不包括专业的后果，以及
• 系统工程师应如何与专业工程师互动。

Grady (2006) 提供了包括可靠性工程在内的许多专业工程学科的概述和参考资料； 零件、材料和工艺工程（PMP）； 可维护性工程、可用性、可生产性工程、设计成本/生命周期成本 (DTC/LCC)、人因工程、腐蚀预防和控制 (CPC)、系统安全工程、电磁兼容性 (EMC) 工程、系统安全工程、质量特性工程和环境影响工程。

Eisner (2008) 将专业工程列为系统工程的“三十个要素”之一。 “专业工程是指一组必须在一些但不是全部的系统工程工作上探索的工程主题。 换句话说，有些系统涉及这些特殊学科，有些则不涉及。 专业工程领域的例子包括电磁兼容性和干扰、安全、物理安全、计算机安全、通信安全、需求预测、面向对象设计和价值工程。” 我们在本文中考虑的一些专业工程，艾斯纳包括在他的系统工程的“三十个要素”中，但不作为专业工程要素的一部分。

没有标准的专业工程学科列表。 什么被认为是专业工程取决于系统工程所属的社区，有时还取决于客户的偏好。