The Cost on System Performance of Requirements on Differentiable Variables

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.

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.

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.

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.

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₁y₁ + a₂y₂ + · · · + a_my_m = c, the basis for vectors that are perpendicular to this plane is simply [a₁, a₂, …, 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₁ = λ_q2/a₂ = · · · = λ_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.

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.001

• 316 stainless steel legs

   Density = 496.32 lbs/cu-ft

   Price = $0.75/lb

   $WL*$ = 142.46 lbs

   C_L = $106.845

• Assembly cost

   A₀ = $15

   δ = $0.05/lb

• Weight 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.

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.

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 lbs

   Standard deviation = 0.5 lbs

• Uncertainty in W_L

   Normal distribution

   Mean = q_L lbs

   Standard 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.

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.

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.

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

There are no conflicts of interest.