⚡ electrical engineering

Functional requirements decomposition in set-based design

本文针对基于集合的设计中缺乏正式指导的问题，提出了一种四步分层方法来分解功能需求，从而为复杂系统设计实现并行抽象和系统性不确定性降低。

原作者： Minghui Sun, Zhaoyang Chen, Georgios Bakirtzis, Hassan Jafarzadeh, Cody Fleming

发布于 2026-05-19

📖 1 分钟阅读☕ 轻松阅读

原作者： Minghui Sun, Zhaoyang Chen, Georgios Bakirtzis, Hassan Jafarzadeh, Cody Fleming

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你是这座庞大而复杂城市的建筑师。你有一个宏伟的愿景：“这座城市必须容纳 100 万人，在夏季保持凉爽，并且永不发生洪水。”这就是你的顶层需求。

问题在于，你尚不清楚具体该如何建造它。你拥有一支由专业承包商（水管工、电工、道路建设者）组成的大型团队，他们在城市的不同区域工作。如果你过早地告诉他们太多细节，可能会将他们锁定在一个糟糕的设计中；如果你告诉他们的太少，他们可能会建造出无法相互匹配的部分。

本文介绍了一种新的、形式化的方法，用于向这些团队分发指令，使它们能够独立（并行）工作而互不干扰，同时保证当它们完成工作时，整座城市能够完美运行。

以下是该方法基于简单类比的分解说明：

1. 问题：“猜测与检查”的陷阱

通常，在设计复杂事物（如飞机或软件）时，团队会过早地选定一种具体设计。如果后来发现它太重或太昂贵，他们就必须推倒重来。这既昂贵又缓慢。

基于集合的设计（Set-Based Design, SBD） 是一种替代方案。与其立即选定一种设计，不如保持一整套可能的设计方案开放。你同时探索多种选项，并随着了解的深入，逐步剔除那些行不通的方案。这就像保留一份包含 50 道菜的菜单，直到确切知道顾客想要什么，而不是看到第一道菜就立刻点单。

2. 核心挑战：将大任务分解

本文提出的问题是：如何将一个巨大而模糊的需求，分解为针对不同团队的具体指令，同时避免引发混乱？

作者提出了一种四步配方，以数学和形式化的方式来实现这一目标。

步骤 1：绘制地图（功能架构）

首先，你绘制城市各系统如何连接的地图。谁与谁对话？

类比：想象城市的水系统。管道（输入）进入处理厂，处理厂将水送出（输出）。你绘制出水源、管道、水泵和水龙头之间的所有连接。
本文的做法：他们精确定义了系统不同部分之间共享的变量（如速度、重量或温度）。

步骤 2：探索“活动空间”（初始可行空间）

接下来，你询问每个团队：“你们可能建造的范围最宽是多少？”

类比：你问道路建设者：“你们能建造承受时速 20 英里、100 英里还是 200 英里的道路吗？”他们回答：“我们可以处理 20 到 200 英里之间的任何速度。”
本文的做法：他们根据当前物理上可能的情况，为系统的每个部分定义一个“可行空间”（即数值范围）。

步骤 3：收缩范围（缩小空间）

现在，你查看各部分如何连接。如果道路建设者说他们能处理 200 英里/小时，但汽车引擎只能达到 150 英里/小时，那么“道路”的要求就过于宽松了。你必须缩小道路允许的速度范围，以匹配引擎。

类比：你取所有团队可能性的交集。如果团队 A 说“我需要 100 加仑水”，而团队 B 说“我只能提供 80 加仑”，你就产生了冲突。你必须缩小需求，直到它们完美契合。
本文的做法：他们利用数学来求这些范围的交集。他们还区分了可控制的因素（如管道尺寸）和不可控制的因素（如天气）。他们确保设计即使在最恶劣的天气下也能正常工作。

步骤 4：“安全缓冲”（确定子需求）

这是最巧妙的部分。你不仅仅给团队你计算出的精确数值，而是给他们一个稍宽的范围，以应对意外。

类比：想象你需要将沙发搬过一扇门。你计算出门宽 30 英寸。但你不会告诉搬运工“沙发必须正好是 29.9 英寸”。你会告诉他们：“沙发必须在 28 到 30 英寸之间。”
- “缓冲”：这额外的空间是为了保护你免受初始测量可能存在的轻微误差（不确定性）的影响。
- “余量”：这是你给予他们的额外空间，使他们不必为了达到一个完美的数字而过度劳累。
本文的做法：他们使用数学上的“权衡”（如天平）来决定给予多少额外空间。空间太少，团队可能会在情况变化时失败；空间太多，最终产品可能会脆弱或昂贵。他们寻找的是“金发姑娘”式的最佳区间。

3. 神奇保证：为何团队可以独立工作

本文证明了一个非常重要的数学事实：如果每个团队都遵循这些规则，它们就可以在完全隔离的情况下工作。

规则 1（可组合性）：团队 A 的输出必须完美契合团队 B 的输入。
规则 2（细化）：给予团队的具体规则必须是宏大规则的“更严格”版本。（例如，如果大规则说“速度 < 100"，团队规则可能会说“速度 < 90"）。

结果：如果每个团队都在其分配的“范围”内构建其部分，且这些范围能够相互契合，那么最终的城市必将正常运行，即使这些团队从未互相交谈过。这解决了大型项目中“孤岛”效应的问题。

“秘诀”总结

本文引入了两个关键概念来处理不确定性：

缓冲（Buffer）：在设计中预留的额外空间，用于吸收已知的未知因素（例如“也许风比我们想象的更强”）。
余量（Excess）：用于吸收未知的未知因素（例如“我们没意识到土壤很松软”）的额外空间。

通过形式化地定义这些概念，作者构建了一个系统，你可以将一个巨大而可怕的问题分解为小的、可管理的部分，分发给不同的团队，并从数学上确保当你将这些拼图碎片重新组合时，画面是完整的。

简而言之：本文提供了一份形式化的“操作手册”，用于分解复杂的工程问题，使不同团队能够在不相互冲突的情况下独立工作，从而确保最终产品完全按照预期运行。

技术摘要：基于集的设计中的功能需求分解

问题陈述

在早期阶段设计复杂的工程系统（例如商用飞机）具有固有的不确定性和模糊性。虽然基于集的设计（SBD）提供了一个稳健的框架，用于通过并行开发探索替代方案并减少不确定性，但现有文献缺乏关于如何在此范式内分解功能需求的正式指导。具体而言，现有的 SBD 方法通常将需求视为简单的性能范围，这对于涉及软件和机械交互的复杂系统而言是不够的，因为在这些系统中，功能被定义为输入与输出之间的映射。此外，关于 SBD 能够通过底层团队实现自主并行开发的说法缺乏严格的正式证明。迫切需要一种正式的方法来分解功能需求，以确保生成的系统满足顶层需求，同时支持团队自主性。

方法论

本文提出了一种四步正式方法，利用基于集的推理来分层分解功能需求。该方法将系统功能视为数学输入 - 输出变换（ $f: (x, u, c) \to y$ ），其中 $x$ 是输入， $y$ 是输出， $u$ 是不可控的不确定参数， $c$ 是可控的不确定参数。

方法论结构如下：

定义和分析功能架构：
- 功能架构被定义为一组相互连接的子功能。
- 该方法聚合来自子功能的变量，以识别共享变量以及独立的设计/性能空间。
- 根据定义上下文（例如，仅在顶层定义的输入与仅在子功能中定义的输入、子功能之间共享的输出等），将变量分类为六个互斥组。
- 此步骤确立了系统的初始设计空间和性能空间。
探索初始可行空间：
- 对于每个子功能，基于可行的实现方案来表征初始可行空间。
- 这些空间代表了在应用系统级约束之前，输入、输出和参数的最广泛可能范围。
缩小可行空间：
- 交集： 对跨多个子功能定义的变量范围进行交集运算，以创建统一的初始可行设计空间（ $FDS_1$ ）和性能空间（ $FPS_1$ ）。
- 约束满足： 该方法应用量化约束满足问题以进一步缩小空间。具体而言，缩小可控参数（ $c$ ）的范围（ $R^\downarrow_c$ ），使得对于不可控参数（ $u$ ）和输入（ $x$ ）的所有值，系统输出都保持在可行的性能空间内。
- 可达性分析： 利用可达性分析，根据缩小后的设计空间（ $FDS_2$ ）计算可达性能空间（ $FPS_2$ ）的过近似。这确保了在缩小后的约束下捕获所有可能的系统行为。
确定子需求：
- 不确定性扩展： 为了适应对初始不确定性的潜在低估，将期望的性能空间（ $FPS^*$ ）从 $FPS_2$ 向 $FPS_1$ 扩展。这种扩展不是任意的；它由权衡研究控制。
- 优化： 构建一个基于障碍函数的优化问题，以确定 $FPS^*$ 的最佳边界。目标是最小化与 $FPS_1$ 边界（以允许不确定性缓冲）和 $FPS_2$ 边界（以避免实施困难）的“距离”，并根据设计者偏好进行加权。
- 最终分配： 将由此产生的缩小后的设计空间（ $FDS_2$ ）和扩展后的性能空间（ $FPS^*$ ）分配为每个子功能的正式子需求（ $R^*_x, R^*_c, R^*_u, R^*_y$ ）。

主要贡献

本文对 SBD 文献做出了两项主要贡献：

复杂系统的正式分解方法：
- 与将需求定义为性能空间范围（适用于机械部件）的现有 SBD 方法不同，该方法将需求定义为输入和输出范围之间的映射。这种公式是专门为涉及多种组件（机械、软件等）的复杂系统设计的。
- 该方法提供了一种严格、可重复的程序，用于将这些映射分解为子需求。
并行开发（自主性）的正式证明：
- 本文引入并证明了两个关键属性：细化（从高层到低层的不确定性减少）和可组合性（子需求之间接口的兼容性）。
- 定理： 如果各层的子需求是可组合的，并且它们的组合细化了高层功能需求，那么通过独立实施这些子需求而形成的组合系统将满足顶层功能需求。
- 这为 SBD 能够实现分布式设计团队之间自主并行开发的说法提供了首个正式依据。
缓冲与冗余的区别：
- 该方法明确区分了“缓冲”（补偿可控不确定性的参数值）和“冗余”（容纳被低估的初始不确定性的盈余）。这种区别被整合到方法论的缩小和扩展步骤中。

结果

提出的方法通过一个涉及巡航控制系统设计的案例研究进行了演示。

顶层需求： 系统必须将初始速度（ $v_0$ ）和参考速度（ $v_r$ ）映射到实际速度轨迹（ $v(t)$ ），该轨迹必须在特定时间内保持有界并收敛到目标范围。
分解： 顶层功能被分解为八个子功能，分别代表物理动力学（力、摩擦力、空气动力学）和控制逻辑（PID 控制器）。
过程执行：
- 该方法成功识别了设计空间（输入和可控参数，如发动机最大转速 $\omega_m$ ）和性能空间（中间力、扭矩和速度）。
- 通过交集和可达性分析（使用 CORA 工具），可行设计空间被缩小，特别是将可控参数 $\omega_m$ 从 $[350, 480]$ 约束到 $[365, 450]$ rad/s，以确保稳定性。
- 优化步骤确定了最终的子需求，确保子功能是可组合的（共享变量具有一致的范围），并且组合系统细化了顶层需求。
结果： 生成的子需求允许子系统的独立实施（例如发动机、轮胎、控制器），同时在数学上保证集成系统将满足顶层稳定性和收敛标准。

意义与主张

本文声称在弥合基于集设计的理论优势与需求工程中对正式、可操作指导的实际需求之间的差距方面具有重要意义。

形式化优于定性方法： 作者认为，虽然 SBD 被广泛使用（特别是在丰田的流程中），但它通常依赖于定性方法。本文提供了一个正式数学框架，消除了分解中的模糊性。
实现自主性： 通过证明可组合性和细化是满足顶层需求的充分条件，该方法验证了 SBD 关于团队自主性的承诺，允许分布式团队并行工作，而无需不断的返工或集成失败。
处理不确定性： 该方法提供了一种通过“缓冲”和“冗余”来管理不确定性的结构化方式，超越了简单的安全系数，转向对认知不确定性和偶然不确定性的更细致处理。

作者对研究范围保持谦逊，承认该方法并未解决所有需求工程挑战（例如需求获取或验证），并且依赖工程师的判断来确定优化步骤中的特定系数。他们将这项工作定位为关于需要解决什么（约束和属性）的框架，而不是规定如何解决底层优化问题的具体计算工具。