⚡ electrical engineering

Functional requirements decomposition in set-based design

This paper addresses the lack of formal guidance in set-based design by introducing a four-step hierarchical method to decompose functional requirements, enabling parallel abstraction and systematic uncertainty reduction for complex system design.

Original authors: Minghui Sun, Zhaoyang Chen, Georgios Bakirtzis, Hassan Jafarzadeh, Cody Fleming

Published 2026-05-19

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Minghui Sun, Zhaoyang Chen, Georgios Bakirtzis, Hassan Jafarzadeh, Cody Fleming

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the architect of a massive, complex city. You have a grand vision: "The city must handle 1 million people, stay cool in summer, and never flood." This is your Top-Level Requirement.

The problem? You don't know exactly how to build it yet. You have a huge team of specialized contractors (plumbers, electricians, road builders) working in different parts of the city. If you tell them too much too soon, you might lock them into a bad design. If you tell them too little, they might build things that don't fit together.

This paper is about a new, formal way to hand out instructions to these teams so they can work independently (in parallel) without stepping on each other's toes, while guaranteeing that when they finish, the whole city works perfectly.

Here is the breakdown of their method, using simple analogies:

1. The Problem: The "Guess and Check" Trap

Usually, when designing complex things (like airplanes or software), teams pick one specific design early on. If they realize later that it's too heavy or too expensive, they have to tear it down and start over. This is expensive and slow.

Set-Based Design (SBD) is the alternative. Instead of picking one design immediately, you keep a whole set of possible designs open. You explore many options at once and slowly cross out the ones that don't work as you learn more. It's like keeping a menu open with 50 dishes until you know exactly what the customer wants, rather than ordering the first thing you see.

2. The Core Challenge: Breaking the Big Task Down

The paper asks: How do you take a giant, vague requirement and break it down into smaller, specific instructions for different teams without causing chaos?

The authors propose a 4-Step Recipe to do this mathematically and formally.

Step 1: Draw the Map (Functional Architecture)

First, you draw a map of how the city's systems connect. Who talks to whom?

Analogy: Imagine the city's water system. The pipes (inputs) go into the treatment plant, which sends water out (outputs). You map out all the connections between the water source, the pipes, the pumps, and the taps.
The Paper's Move: They define exactly which variables (like speed, weight, or temperature) are shared between different parts of the system.

Step 2: Explore the "Wiggle Room" (Initial Feasible Spaces)

Next, you ask every team: "What is the widest range of things you could possibly build?"

Analogy: You ask the road builders: "Can you build a road that handles cars going 20 mph? 100 mph? 200 mph?" They say, "We can handle anything between 20 and 200."
The Paper's Move: They define a "feasible space" (a range of numbers) for every part of the system based on what is physically possible right now.

Step 3: Shrink the Box (Narrowing the Spaces)

Now, you look at how the parts connect. If the road builders say they can handle 200 mph, but the car engine can only go 150 mph, the "road" requirement is too loose. You have to shrink the road's allowed speed to match the engine.

Analogy: You take the intersection of all the teams' possibilities. If Team A says "I need 100 gallons of water" and Team B says "I can only provide 80," you have a conflict. You must narrow the requirements until they fit together perfectly.
The Paper's Move: They use math to intersect these ranges. They also distinguish between things you can control (like the size of a pipe) and things you can't (like the weather). They ensure the design works even in the worst-case weather.

Step 4: The "Safety Buffer" (Determining Sub-Requirements)

This is the cleverest part. You don't just give the teams the exact numbers you calculated. You give them a slightly wider range to allow for surprises.

Analogy: Imagine you need to fit a sofa through a doorway. You calculate the doorway is 30 inches wide. But you don't tell the movers "The sofa must be exactly 29.9 inches." You tell them, "The sofa must be between 28 and 30 inches."
- The "Buffer": This extra space protects you if your initial measurements were slightly wrong (uncertainty).
- The "Excess": This is the extra room you give them so they don't have to work too hard to hit a perfect number.
The Paper's Move: They use a mathematical "trade-off" (like a balancing scale) to decide how much extra room to give. Too little room, and the teams might fail if things change. Too much room, and the final product might be weak or expensive. They find the "Goldilocks" zone.

3. The Magic Guarantee: Why Teams Can Work Alone

The paper proves a very important mathematical fact: If every team follows these rules, they can work in total isolation.

Rule 1 (Composability): The output of Team A must fit perfectly into the input of Team B.
Rule 2 (Refinement): The specific rules given to the teams must be a "tighter" version of the big rule. (e.g., If the big rule says "Speed < 100," the team rule might say "Speed < 90").

The Result: If every team builds their part within their assigned "box," and those boxes fit together, the final city will work, even if the teams never talked to each other. This solves the problem of "silos" in large projects.

Summary of the "Secret Sauce"

The paper introduces two key concepts to handle uncertainty:

Buffer: Extra room built into the design to absorb known unknowns (like "maybe the wind is stronger than we think").
Excess: Extra room to absorb unknown unknowns (like "we didn't realize the soil was soft").

By formally defining these, the authors create a system where you can break a massive, scary problem into small, manageable chunks, hand them to different teams, and be mathematically sure that when you put the puzzle pieces back together, the picture is complete.

In a nutshell: This paper provides a formal "instruction manual" for breaking down complex engineering problems so that different teams can work independently without crashing into each other, ensuring the final product works exactly as intended.

Technical Summary: Functional Requirements Decomposition in Set-Based Design

Problem Statement

Designing complex engineered systems (e.g., commercial aircraft) at early stages is characterized by inherent uncertainty and ambiguity. While Set-Based Design (SBD) offers a robust framework for exploring alternatives and reducing uncertainty through parallel development, current literature lacks formal guidance on how to decompose functional requirements within this paradigm. Specifically, existing SBD approaches often treat requirements as simple performance ranges, which is insufficient for complex systems involving software and mechanical interactions where functions are defined as mappings between inputs and outputs. Furthermore, the claim that SBD enables autonomous, parallel development by lower-level teams lacks rigorous formal proof. There is a critical need for a formal method to decompose functional requirements that ensures the resulting system satisfies top-level requirements while supporting team autonomy.

Methodology

The paper proposes a four-step formal method to decompose functional requirements hierarchically using set-based reasoning. The approach treats system functions as mathematical input-output transformations ( $f: (x, u, c) \to y$ ), where $x$ are inputs, $y$ are outputs, $u$ are uncontrollable uncertain parameters, and $c$ are controllable uncertain parameters.

The methodology is structured as follows:

Define and Analyze Functional Architecture:
- A functional architecture is defined as a set of connected sub-functions.
- The method aggregates variables from sub-functions to identify shared variables and distinct design/performance spaces.
- Variables are classified into six exclusive groups based on their definition context (e.g., inputs defined only in the top-level vs. sub-functions, outputs shared between sub-functions, etc.).
- This step establishes the initial design space and performance space for the system.
Explore Initial Feasible Spaces:
- For each sub-function, an initial feasible space is characterized based on feasible implementations.
- These spaces represent the broadest possible ranges for inputs, outputs, and parameters before system-level constraints are applied.
Narrow Feasible Spaces:
- Intersection: The ranges of variables defined across multiple sub-functions are intersected to create a unified initial feasible design space ( $FDS_1$ ) and performance space ( $FPS_1$ ).
- Constraint Satisfaction: The method applies a quantified constraint satisfaction problem to further narrow the space. Specifically, controllable parameters ( $c$ ) are narrowed ( $R^\downarrow_c$ ) such that for all values of uncontrollable parameters ( $u$ ) and inputs ( $x$ ), the system output remains within the feasible performance space.
- Reachability Analysis: Reachability analysis is used to compute an over-approximation of the reachable performance space ( $FPS_2$ ) given the narrowed design space ( $FDS_2$ ). This ensures that all possible system behaviors under the narrowed constraints are captured.
Determine Sub-Requirements:
- Uncertainty Expansion: To accommodate potential underestimation of initial uncertainties, the desired performance space ( $FPS^*$ ) is expanded from $FPS_2$ towards $FPS_1$ . This expansion is not arbitrary; it is governed by a trade-off study.
- Optimization: A barrier function-based optimization problem is formulated to determine the optimal boundaries of $FPS^*$ . The objective minimizes the "distance" to the boundaries of $FPS_1$ (to allow uncertainty buffer) and $FPS_2$ (to avoid implementation difficulty), weighted by designer preferences.
- Final Assignment: The resulting narrowed design space ( $FDS_2$ ) and expanded performance space ( $FPS^*$ ) are assigned as the formal sub-requirements ( $R^*_x, R^*_c, R^*_u, R^*_y$ ) for each sub-function.

Key Contributions

The paper makes two primary contributions to the SBD literature:

Formal Decomposition Method for Complex Systems:
- Unlike existing SBD approaches that define requirements as performance space ranges (suitable for mechanical components), this method defines requirements as mappings between input and output ranges. This formulation is specifically designed for complex systems involving diverse components (mechanical, software, etc.).
- The method provides a rigorous, repeatable procedure for decomposing these mappings into sub-requirements.
Formal Proof of Parallel Development (Autonomy):
- The paper introduces and proves two critical properties: Refinement (reduction of uncertainty from higher to lower levels) and Composability (compatibility of interfaces between sub-requirements).
- Theorem: If sub-requirements at each level are composable and their composition refines the higher-level functional requirements, then the composite system formed by independently implementing these sub-requirements will satisfy the top-level functional requirements.
- This provides the first formal justification for the claim that SBD enables autonomous, parallel development among distributed design teams.
Distinction Between Buffer and Excess:
- The method explicitly distinguishes between "buffer" (parameter values compensating for controllable uncertainties) and "excess" (surplus accommodating underestimated initial uncertainties). This distinction is integrated into the narrowing and expansion steps of the methodology.

Results

The proposed method was demonstrated through a case study involving the design of a cruise control system.

Top-Level Requirement: The system must map initial speed ( $v_0$ ) and reference speed ( $v_r$ ) to a real speed trajectory ( $v(t)$ ) that remains bounded and converges to a target range within a specific time.
Decomposition: The top-level function was decomposed into eight sub-functions representing physical dynamics (forces, friction, aerodynamics) and control logic (PID controller).
Process Execution:
- The method successfully identified the design space (inputs and controllable parameters like engine max speed $\omega_m$ ) and performance space (intermediate forces, torques, and speeds).
- Through intersection and reachability analysis (using the CORA tool), the feasible design space was narrowed, specifically constraining the controllable parameter $\omega_m$ from $[350, 480]$ to $[365, 450]$ rad/s to ensure stability.
- The optimization step determined the final sub-requirements, ensuring that the sub-functions were composable (shared variables had consistent ranges) and that the composite system refined the top-level requirements.
Outcome: The resulting sub-requirements allowed for independent implementation of subsystems (e.g., engine, tires, controller) while mathematically guaranteeing that the integrated system would meet the top-level stability and convergence criteria.

Significance and Claims

The paper claims significance in bridging the gap between the theoretical benefits of Set-Based Design and the practical need for formal, actionable guidance in requirements engineering.

Formalism over Qualitative Approaches: The authors argue that while SBD is widely used (notably in Toyota's processes), it often relies on qualitative methods. This paper provides a formal mathematical framework that eliminates ambiguity in decomposition.
Enabling Autonomy: By proving that composability and refinement are sufficient conditions for top-level satisfaction, the method validates the SBD promise of team autonomy, allowing distributed teams to work in parallel without constant rework or integration failures.
Handling Uncertainty: The approach offers a structured way to manage uncertainty through "buffer" and "excess," moving beyond simple safety factors to a more nuanced handling of epistemic and aleatoric uncertainties.

The authors remain modest regarding the scope, acknowledging that the method does not solve all requirements engineering challenges (such as elicitation or validation) and relies on engineer judgment for specific coefficients in the optimization step. They position the work as a framework for what needs to be solved (the constraints and properties) rather than prescribing specific computational tools for how to solve the underlying optimization problems.