## Abstract

System design is commonly thought of as a process of maximizing a design objective subject to constraints, among which are the system requirements. Given system-level requirements, a convenient management approach is to disaggregate the system into subsystems and to “flowdown” the system-level requirements to the subsystem or lower levels. We note, however, that requirements truly are constraints, and they typically impose a penalty on system performance. Furthermore, disaggregation of the system-level requirements into the flowdown requirements creates added sets of constraints, all of which have the potential to impose further penalties on overall system performance. This is a highly undesirable effect of an otherwise beneficial system design management process. This article derives conditions that may be imposed on the flowdown requirements to assure that they do not penalize overall system performance beyond the system-level requirement.

## 1 Introduction

Modern systems engineering often comprises a system design process based on requirements. The common perception is that the requirements are a set of directives that define what the customer wants and what the system has to do to meet the needs and wants of the customer. In fact, however, requirements do not define what the customer wants. They are a set of constraints that define what the customer will not accept, and they do not enable ranking of system alternatives. For example, *the system shall not weigh more than 100 pounds* simply says that the customer will not accept the system if it weighs more than 100 pounds. It does not say how the customer values weights that meet this requirement, for example, whether 70 pounds is better than 80 pounds. Thus, requirements would not serve to define a preference or an objective function for system optimization. In fact, requirements are constraints, and as shown by Hazelrigg and Saari [1], constraints have the potential to significantly reduce system performance as measured by the system design objective. Thus, one would normally prefer to minimize the imposition of constraints.

Current systems practice, however, involves a process of requirements flowdown, wherein a system-level requirement, such as a weight restriction, is flowed down to the subsystem level by assigning weight requirements at that level. The idea in setting the flowdown requirement is that, if the sum of the subsystem weight requirements is not greater than the system weight requirement, the system as a whole will meet its weight requirement. The flowdown requirements then enable the overall system design project to be broken down into a set of well-defined design tasks that empower design teams to preform the necessary subsystem and component level designs.

The problem with this practice is that the flowdown process introduces a large number of new requirements, each of which constitutes another constraint on the system, and each additional constraint has the potential to further degrade the system. Constraints may be classified as either inactive or active. An inactive constraint is one that is satisfied by an unconstrained optimal solution. In other words, the constraint would be satisfied by the solution if it were not stated at all. An active constraint is one that requires modification of the optimal solution to be satisfied. Thus, active constraints always impose penalties on the unconstrained (or less constrained) optimal solution. Clearly, as the requirements flowdown process introduces many new constraints (perhaps thousands in a complex system), it can be expected that many of these will impose penalties on the final system performance. But the flowdown constraints are self-imposed by the systems engineering process as a convenience to enable disaggregation of the system design process. This article addresses this problem for the case of requirements on differentiable variables such as weights, costs, volumes, power demands, and component reliabilities.

## 2 Background

While it is clear that large engineered systems have been designed and constructed for millennia—pyramids, the Roman aqueducts, and the Taj Mahal—the “science” of systems engineering appears to have had its beginnings in the early 1900s in the Bell Laboratories [2]. Hall was tasked with the establishment of a systems engineering course for the lab and eventually compiled extant systems knowledge into an early text on the subject [3]. In this book, he coins the term *objectives*, consisting of quantifiable statements describing what the system is intended to do. These statements would appear to be the first formal use of *requirements* as we know them today. They show further that Hall had grasped the concept of hierarchically structured objectives. Hall describes five phases of systems engineering: system studies, exploratory planning including selecting objectives and system design optimization, development planning, system development and test, and late-stage or operational engineering. Fagen [4] reviews applications of systems engineering during World War II, and in 1946, the RAND Corporation was created to assist what would later become the Air Force in the conduct of systems analysis. Also, in the 1940s systems engineering became an important aspect of missile and missile-defense systems [5].

Since its founding in 1990, the International Council On Systems Engineering (INCOSE) has been a major contributor to the theory and practice of systems engineering and has given considerable attention to the definition, statement, and flowdown of requirements. The INCOSE Systems Engineering Handbook [6] recognizes requirements as a key to the processes of system management, integration, verification, validation, operation, maintenance, and disposal. The Handbook notes, “successful projects depend on meeting the needs and requirements of the stakeholder/customer,” and goes on to say, “a great deal of literature exists on how to write and manage requirements.” The Handbook then enumerates how to “elicit and capture requirements, generate a concept of operations, define system capabilities and performance objectives, and define non-functional requirements.” However, the Handbook does not address the management of requirements flowdown. A later INCOSE document [7] recognizes a “complex relationship between requirements, the design choices made to address each requirement, and the system-level consequences of the sum of design choices across the full set of performance requirements···” Neither does this document address the penalties that requirements can impose on a system.

The National Aeronautics and Space Administration systems engineering handbook [8] recognizes the requirements flowdown process. This document recognizes four “system design processes,” stakeholder expectation definition, technical requirements definition, logical decomposition, and design solution definition. The relevant process here is the logical decomposition process, which NASA describes as “used to improve understanding of the defined technical requirements and the relationships among the requirements ··· and to transform the defined set of technical requirements into a set of logical decomposition models and their associated set of derived technical requirements for lower levels of the system and for input to the design solution definition process.” This document also does not address the potential penalties that requirements can impose on a system.

Collopy, in a number of unpublished presentations, has clearly recognized the penalties that requirements can impose on system performance. He has specifically addressed the problem of flowdown requirements, noting that they are constraints that impose potentially significant penalties. In addition, Collopy and coworkers [9] studied Department of Defense acquisition programs noting that current system procurement processes lead to an estimated loss on the order of $200 million per day. It is partly for this reason that we address the losses that flowdown requirements of continuous variables such as weight, cost, power consumption, thermal load, and reliability can impose on system performance and provide conditions that assure that these penalties are minimized.

## 3 Deterministic Formulation of the Problem

Let a system be described by a set of statements, **x**. The elements of **x** may include continuous and integer values, verbal statements such as colors or textures, descriptions of a system configuration, manufacturing process descriptions, and even probabilistic statements or beliefs. We will consider the elements of **x** to be of two types, **x**^{T} = [**x**_{d}, **x**_{n}], where **x**_{d} are those components of **x** that are differentiable and **x**_{n} are the nondifferentiable components of **x**, which we shall refer to as the *system configuration*. Let *P*(**x**) be a real scalar function that denotes the system performance or objective function such that candidate system designs, **x**, are evaluated and ranked by values of *P*(**x**). Next, let system-level requirements on differentiable variables be denoted by **r**, composed of elements *r*_{j}, *j* = 1, 2, …, *n*, where *n* is the number of system-level requirements on differentiable variables. The *r*_{j} may derive from statements such as, “the system shall not weigh more than 100 pounds.” We then decompose the system-level requirements into subsystem flowdown requirements **q**_{j}, with elements *q*_{jk}, *k* = 1, 2, …, *m*, where *m* is the number of relevant subsystems.

*f*_{j}(

**q**

_{j}) refers to the vector of functions

*f*

_{j}(

**q**

_{j}) with each element of this vector associated with its corresponding element of

**r**

_{j}, and

*g*_{j}(

**x**) refers to the vector of functions

*g*

_{j}(

**x**) corresponding to the vector of flowdown requirements for each subsystem,

*j*.

We will assume that the constraint functions are convex so that the set of feasible solutions is a convex set. We shall also assume that the first partial derivatives of *P*(**x**) with respect to **x**_{n} and *g*_{j} are defined. The solution to the maximization of *P*(**x**) can be obtained via a Lagrangian formulation invoking the Karush–Kuhn–Tucker (KKT) conditions [10]. This optimization is shown in Fig. 1.

A requirement that is satisfied by an optimal design without imposing the requirement does not impose a penalty on the optimal solution, and it is unnecessary. This would be the case if the region of feasible solutions, that is, the solutions that satisfy the inequality constraint on **r**, encompasses the maximum point. In this case, we say that the constraint is *inactive*. The curves circling the maximum point are lines of constant *P*(**x**). For all requirements that are not satisfied by an optimal design as shown in the figure, the requirement imposes a penalty on the optimal solution, and to minimize that penalty, the solution is the point of tangency between boundary of the constraint region and a surface of constant *P*(**x**). We refer to these constraints as *active*.

**x**

_{n}, and flowdown requirements,

**q**

_{j}. Second, for this system configuration and flowdown requirements, values of

**x**

_{d}are determined by the following optimization as written in the Lagrangian form [10,11]:

*J*(

**x**) with respect to

**x**

_{d}are as follows:

*λ*_{r}and

*λ*_{qj}and the optimum values for the design parameters

**x**

_{d}subject to the given values of

**x**

_{n}and

**q**

_{j}. Note that, if for any requirement

*λ*

_{r}= 0, that requirement is inactive.

In this formulation, the *λ*_{qj} represent the marginal penalties, namely, −∂*P*(**x**)/∂**q**_{j}, of the flowdown requirements on the system performance. Thus, a condition that assures that the flowdown requirements do not impose additional constraints on the system that further penalize performance beyond the penalty imposed by the system-level requirements **r** is that the *λ*_{q}'s satisfy a *transversality* condition. That is, the *λ*_{q}'s must be transverse (perpendicular or normal) to the plane of the requirements defined by *f*_{j}(**q**_{j}) at the point of tangency for the optimal solution as shown in Fig. 1. Note that this point defines the optimal values of **q**. Furthermore, the requirement to satisfy the transversality condition makes clear that if the system-level requirement is inactive, it must be the case that all flowdown requirements are also inactive, that is, all *λ*_{q} = 0. Contrariwise, if a particular *λ*_{r} is nonzero positive, then that constraint is active and the corresponding constraints on all components of the associated **q**_{j} must also be active. This is because it is not possible to satisfy the transversality condition otherwise, and in this case, we know immediately that the equality conditions on **r** and **q** must apply.

For a hyperplane defined by an equation of the form *a*_{1}*y*_{1} + *a*_{2}*y*_{2} + · · · + *a*_{m}*y*_{m} = *c*, the basis for vectors that are perpendicular to this plane is simply [*a*_{1}, *a*_{2}, …, *a*_{m}]. Thus, for a flowdown requirement plane of the form (4), a vector normal to the plane is simply [1,1, …, 1], and the magnitude of this vector is $m$. The transversality condition states that the projection of the *λ*_{q}'s for each flowdown requirement onto the requirement plane must have magnitude 0. This means that the vector defined by the components *λ*_{q} must align with the vector [1,1, …, 1]. In other words, for each requirement, *q*, *λ*_{q1} = *λ*_{q2} = · · · = *λ*_{qm} or, in the more general case where all *a*_{i} ≠ 1, *λ*_{q1}/*a*_{1} = *λ*_{q2}/*a*_{2} = · · · = *λ*_{qm}/*a*_{m}. Furthermore, if this condition is not met, this vector sum will have a finite projection onto the requirement plane, and that projection will show the direction in which one must adjust the *q*'s to seek a more optimal allocation of the flowdown requirements. Stated verbally, for a given flowdown requirement, each design team should first obtain a “best” design and then estimate the improvement in performance achievable if the requirement is relaxed by a given small amount. These “sensitivities” are the respective *λ*'s. If the *λ'*s satisfy the aforementioned transversality condition, then the flowdown requirements are allocated optimally, and they will impose no performance penalty in addition to that imposed by the system-level requirement *r*. If the *λ'*s do not satisfy the aforementioned conditions, then their vector sum will have a finite projection onto the requirement plane, and this projection will denote the relative changes to the *q*'s one should make to seek a more optimal allocation of the flowdown requirements. Thus, in practice it is not necessary to find the projection of the vector sum onto the requirements plane as it is only necessary to assure that the magnitude of the projection is 0.

A key advantage of this approach to the optimization of flowdown requirements is that it enables the disaggregation of design tasks in the same manner that the current requirements flowdown process does. At each step in this process, the subsystem design teams will have access to flowdown requirements that enable them to provide candidate designs. Yet, as the design iterates to a final, optimal design, the flowdown requirements will converge to a set that imposes no penalties to the system performance beyond that imposed by the system-level requirements.

It is also worth to note that the *λ*_{r} represent the cost per unit of the system-level requirements, namely, −∂*P*(**x**)/∂**r**. These data could be useful in determining whether the system-level requirements are reasonably determined.

## 4 Example Problem

*r*

_{W}, on the assembled table that is flowed down to weight requirements on the table top and the legs taken as a group, namely,

*f*

_{W}(

*q*

_{W}) =

*q*

_{T}+

*q*

_{L}, and with an objective of minimum cost. The weight of the table is given as the sum of the volumes of the parts of the table times the densities,

*ρ*, of these parts. For simplicity, we will take the outer dimensions of the parts to comprise rectangular cuboids, which will be lightened by material removal resulting in a final volume of

*η*times the original volume of the cuboid, namely,

*V*=

*ηlwt*, where

*l*,

*w*, and

*t*are the length, width, and thickness of the parts, respectively, and (1 −

*η*) is the fraction of the material that is removed to lighten each part, 0 <

*η*< 1.

^{2}To prevent the trivial result that the table has zero surface area, we will take the values of

*l*

_{T}and

*w*

_{T}to be fixed and given. In addition, we will assume that the table is to be of a specified height,

*h*, such that

*h*= (

*l*

_{L}+

*t*

_{T}) is also fixed and given. Thus, the weights of the table parts are given by

*W*

_{T}and

*W*

_{L}are the weights of the top and legs, respectively, noting that the table has four legs and taking their unmachined cuboids to be of equal width and thickness.

*C*, a cost of machining

*M*, and a cost of assembly

*A*. The material cost will be taken to be proportional to the weights of the unmachined parts, namely, $WT*$ =

*ρ*

_{T}

*l*

_{T}

*w*

_{T}

*t*

_{T}and $WL*=4\rho L(h\u2212tT)wL2$. Accordingly, the material cost is

*P*

_{T}and

*P*

_{L}are the prices per unit weight of the table top and table leg materials, respectively. Next, we shall use the following relationships for the cost of machining for the purpose of weight reduction,

^{3}

**x**

_{d}, include the dimensions of the table top and legs, namely,

*l*

_{T},

*w*

_{T},

*t*

_{T}and

*l*

_{L},

*w*

_{L}, and

*η*

_{T}and

*η*

_{L}. Of these, however, only

*t*

_{T},

*w*

_{L},

*W*

_{T}= $WT*$

*η*

_{T}, and

*W*

_{L}= $WL*$

*η*

_{L}are free to be optimized. Furthermore, the relationships between

*t*

_{T}and

*η*

_{T}and between

*w*

_{L}and

*η*

_{L}would normally be constrained by relationships that determine the required strength and stiffness. Thus, to keep this example relatively simple, we shall also take

*t*

_{T}and

*w*

_{L}to be given, leaving only

*W*

_{T}and

*W*

_{L}to be optimized. These design variables are determined by maximizing the function:

*J*(

**x**) with respect to the remaining free variables of

**x**

_{d}, namely,

*W*

_{T}and

*W*

_{L}.

*λ*'s,

*r*

_{W}=

*q*

_{T}+

*q*

_{L}. Hence, the requirement hyperplane is a line with normal vectors defined by the direction {1,1} corresponding to the

*q*

_{T}and

*q*

_{L}axes, and the optimality condition is expressed as follows:

*r*

_{W}, 1 and 1, were different. It is also possible for the flowdown requirements to combine nonlinearly in which case the flowdown requirement surface is not a plane. This typically would be the case if the flowdown requirements are on component reliabilities. The more general case of condition (4) is presented in Appendix A.

To illuminate the example case further, we choose the following data:

Oak table top

Density = 39.33 lbs/cu-ft

Price = $1.0679/lb

$WT*$ = 78.66 lbs

*C*_{T}= $84.001316 stainless steel legs

Density = 496.32 lbs/cu-ft

Price = $0.75/lb

$WL*$ = 142.46 lbs

*C*_{L}= $106.845Assembly cost

*A*_{0}= $15*δ*= $0.05/lbWeight requirement

*r*≤ 50 lbs

With these data, convergence to a solution is obtained easily within ten iterations using a simple gradient search. Figure 3 is a plot of *λ*_{qT} and *λ*_{qL} as a function of *q*_{T}, with an optimal solution of *q*_{T} = 30.2295 lbs. As both *λ*_{qT} and *λ*_{qL} are positive, we are assured that the constraint on **r** is active, and the equality conditions of the constraints on **r** and **q** apply. Figure 4 shows the projection of the vector sum *λ*_{qT} + *λ*_{qL} onto the requirement plane. The zero crossing depicts the optimal solution. Figure 5 plots the total cost of manufacture as a function of *q*_{T}.

## 5 Nondeterministic Formulation of the Problem

The formulation for the determination of optimal flowdown requirements given earlier can be adapted to more complex cases where there is uncertainty, in which case it may be desirable to specify the flowdown requirements with “margins” to provide added confidence that the system-level requirements can be met. In one case, the margins may be used at the design stage to assure that some exceedance of the flowdown requirements will not result in failure of the final design to meet the system-level requirement. Alternatively, the margins may be used to account for manufacturing variance, again to assure that the manufactured product will meet the system-level requirement. It is also possible to accept different interpretations of the flowdown requirements. On the one hand, project management could elect to hold all design teams responsible for meeting their individually assigned flowdown requirements. On the other hand, management could elect only to manage requirements at the system level, accepting exceedances of some flowdown requirements provided they are accommodated by underages in others. Each of these cases fit within the overall framework provided here, however with some modification of the logic by which the payoff function is determined. While it might be reasonable to expect that the deterministic formulation will converge to an optimal solution as uncertainties are reduced through the iterative design process, it may prove more expeditious to begin with the nondeterministic formulation.

Extension to the nondeterministic case relies on reformulation of the problem to maximize expected utility of the selection of the flowdown requirements [12]. For this case, we must consider more than the marginal penalties of the flowdown requirements themselves. We must acknowledge the potential that inadequate provision of margins can lead to cases where the final design fails to meet the system-level requirements and is, therefore, a failure that bears a cost to the project. Thus, the formulation given earlier must be augmented to provide an estimate of the benefit of a successful design (one that meets all system-level requirements) as a function of the flowdown requirements and an estimate of the cost of a design failure. Note that, while increasing the margin on the flowdown requirements may increase the probability of achieving a successful design, doing so penalizes the expected performance of the successful design. Thus, maximization of the expected utility must account for both the utility of successful designs and that of failed designs.

**q**

_{j}=

*g*_{j}(

**x**). Rather the inequality,

**q**

_{j}≤

*g*_{j}(

**x**), will now apply. We must next consider the possibility of design failure, that is, where uncertainty in the outcome of a design choice leads to an exceedance of a requirement, either at the system level or at the flowdown level depending on the project management approach. We shall consider the case of design choices failing to meet the system-level requirement. For the case of the table example presented earlier, this means that the total table weight exceeds a system-level weight requirement. We shall assume that, when this happens, there is a cost imposed such that the design outcome has negative value. We denote the utility of this loss as

*u*

_{f}. Then, the expected utility of a choice of flowdown requirements, in the example case,

*q*

_{T}and

*q*

_{L}, is given by

*p*

_{s}is the probability that the design meets the system-level requirement.

Interestingly, the introduction of uncertainty leads to a requirement for additional data, including both data on the nature of the uncertainty itself and on the context within which the uncertainty lies. We will consider a very simple case of uncertainty here, where the choice of the requirements *q*_{T} and *q*_{L} leads to uncertain component weights *W*_{T} and *W*_{L}, and where it is required that *W*_{T} + *W*_{L} ≤ *r*. This requirement leads to significant added complexity in the solution of (5). For this reason, we resort to Monte Carlo simulation for the evaluation of choices of *q*_{T} and *q*_{L}. We also assume that the decision maker is risk neutral, that is, the utility of money equals money. The additional data we need for this case are the following:

Uncertainty in

*W*_{T}Normal distribution

Mean =

*q*_{T}lbsStandard deviation = 0.5 lbs

Uncertainty in

*W*_{L}Normal distribution

Mean =

*q*_{L}lbsStandard deviation = 0.5 lbs

Economic data

Failure cost = $2000

Sale price = $325

Demand at the sale price = 100 units

Note that, if the decision maker were not risk neutral, for example, if the decision maker’s risk preferences were expressed as the utility of money equals the log of money, then in addition to the aforementioned data we would also require data on the financial status of the decision maker.

A solution to the aforementioned case is shown in Fig. 6. Clearly, there would be a considerable penalty to specifying values of *q*_{T} and *q*_{L} equal to the deterministic solution. The labels on the contours shown in this figure denote the expected utility of the choice of *q*_{T} and *q*_{L}, which in this case equates to the expected profit. The “+” sign shows the approximate location of the maximum point with an expected utility of 5132.

Although we have shown through this example that the problem formulation given is capable of dealing with cases that involve uncertainties, much work remains to fully exploit this capability.

## 6 Optimization of System-Level Requirements

Recognize that the *λ*_{r} represents the penalty, ∂*P*(**x**)/∂**r**, that the system-level requirements impose on the system performance. Thus, these values can prove useful in evaluating the desirability of these requirements. For example, if the penalty of the requirement, *the system shall not weigh more than 100 pounds*, seems excessive, it could encourage the customer to relax the requirement somewhat. These *λ*_{r}'s might also be used to understand tradeoffs among system-level requirements. For example, consider the case of an airplane designed for long-distance routes. System-level requirements might include cruise speed and range, with more of each being desirable. However, point-to-point trip times may be higher because range limitations require refueling stops on long flights, such that the overall trip time could actually be reduced by allowing a lower, more fuel-efficient, cruise speed.

Furthermore, it could be useful to determine the system-level requirements for which the *λ*_{r} = **0** as this condition allows the system performance to be maximized in the absence of the requirements. The process for finding the values of the requirements that satisfy this condition is the same as that for finding the values of the flowdown requirements that do not penalize the system performance.

## 7 Conclusions

System design by requirements and requirements flowdown is a well-established and presumably well-understood process. Unfortunately, it imposes added constraints on system design that have the potential to translate into serious performance penalties. To alleviate these penalties, we have derived a condition that, when imposed on the flowdown requirements, assures that they impose no additional penalty on system performance. The mathematics of the Lagrangian formulation together with the KKT conditions used in this approach leads to a convenient and powerful method that enables consideration of nonlinear cases and has the potential to extend to the case of uncertainty where we seek to optimize the system with respect to the expected utility of a system performance measure. The method also extends easily to multiple levels of flowdown requirements. A significant advantage of this method of setting flowdown requirements is that, at all steps during the design process, system-level and flowdown requirements are available to the design teams, allowing the design process to remain essentially unchanged while reducing the performance penalties adherent to the current requirements flowdown systems engineering approach.

By implementing this approach to the selection of requirements at all levels of system design, it may be possible to significantly reduce penalties associated with requirements on continuous variables, while requirements remain available to the design teams so that their work can proceed as usual. Furthermore, it seems reasonable that the concepts employed here can be extended to cases where the requirements are on variables that are not continuously differentiable. Noting that constraints imposed by requirements might be made inactive through the proper choice of a system performance measure, the approach provided here could pave the way to enable the conversion of system design by requirements into a case of design by preference while leaving the actual design process and its management largely unchanged.

## Footnotes

We use the concept of material removal here to emphasize that we have assured continuous differentiability of **g**(**x**_{n}).

Note that we wish to minimize total cost, which is equivalent to maximizing performance, P(**x**), expressed as the negative of total cost.

## Acknowledgment

This work has been supported by the National Science Foundation under award CMMI-1923164.

## Conflict of Interest

There are no conflicts of interest.

### Appendix A: The Transversality Condition

*λ*_{q}= [

*λ*

_{q1},

*λ*

_{q2}, …,

*λ*

_{qm}] must be normal to the requirement hyperplane defined by

*r*=

*f*(

**q**) at the point

**q**for the optimum design point

**x**. In the case that

*f*(

**q**) takes the form

**a**= [

*a*

_{1},

*a*

_{2}, …,

*a*

_{m}]. Thus, if

*λ*_{q}=

*α*

**a**, where

*α*is a positive scalar, the transversality condition is met.

*r*=

*f*(

**q**) defines a nonplanar surface. Requiring that

**be normal to the requirement surface at point**

*λ**f*(

**q**) is equivalent to requiring that

*λ*_{q}be normal to the hyperplane that is tangent to

*f*(

**q**) at point

**q**. But, from (A1), we can see that the tangent hyperplane is given by

*λ*_{q}onto the tangent hyperplane at point

**q**must have magnitude 0. The projection of

*λ*_{q}onto the requirement hyperplane is simply

*λ*_{q}minus the vector normal to the tangent hyperplane,

**n**, from

*λ*_{q}to the hyperplane. Note that the direction of

**n**is the same as that of

**a**and its magnitude is obtained from the dot product of

*λ*_{q}and

**a**: