# Quantitative Set-Based Design to Inform Design Teams
## 4 Insights from Quantitative Set-Based Design
### Informing Requirement Analysis  
Requirement analysis is an important part of systems engineering. Sometimes, the requirements result in no feasible alternatives. This is why it is important for analysts to have an understanding of how requirements affect the tradespace. SBD with an integrated model using MBE techniques enables analysts to assess the impact of a requirement's change on the feasible tradespace in near real-time. [PERSON] et al. [43] provide an example. This section expands upon that example. Figure 8 shows these feasible alternatives in yellow and provides a starting point to help analyze requirements to inform requirement developers. The alternatives in orange display all of the explored 100,000 designs. The blue points represent the alternatives that are feasible based solely upon the UAV case study's physics-based parametric models (27,750). When requirements are added, the UAV model has only 2526 feasible design alternatives. The number of feasible solutions increased to 4366 (black) from the UAV model's original number of feasible solutions when the requirements were relaxed. Constraining the requirements reduced the feasible space to 924 designs (red). Table 2 contains  
Figure 7: Integrated Trade-off Analysis Framework [40]. constrained, original, and relaxed requirements for the UAV case study. We also examine the number of feasible designs produced when each requirement is changed one by one. For this analysis, we only change the requirement of interest, while maintaining all other requirements at their original UAV case study values. Using an integrated model with MBE makes this an easy analysis to perform. The model updates in near-real time when we change each requirement. We then can record the number of feasible designs. Figure 9 shows the results of a one-by-one analysis for the UAV case study that used the constrained, original, and relaxed values in Table 2. We display the results by using a tornado graph, which places the requirements with the greatest change in feasible designs at the top and the requirements with the fewest changes or no change in feasible design at the bottom. Figure 9 shows that the \"Detect Human Activity at Night\" and \"Detect Human Activity in Daylight\" requirements have the greatest effect on the feasible tradespace, while \"Detect Vehicular Activity at Night\", \"Detect Vehicular Activity \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Performance Measure** & **Constrained** & **UAV Case Study** & **Relaxed** \\ \hline UAS weight (lbs) & 40 & 50 & 60 \\ \hline Time required to fly 10 km (minutes) & 10 & 15 & 20 \\ \hline Time required to scan a 5 km \(\times\) 5 km box during & 180 & 200 & 220 \\ \hline Time required to scan a 5 km \(\times\) 5 km box during & 180 & 200 & 220 \\ \hline Dwell time (minutes) & 90 & 60 & 30 \\ \hline Perceived area of UAV at operating altitude (ft\({}^{2}\)) & 14 & 16 & 18 \\ \hline Difference between operating altitude and attack & & & \\ helicopter operating altitude of 1000 m & 250 & 0 & 0 \\ \hline Detect human activity in daylight & 0.7 & 0.6 & 0.5 \\ \hline Detect vehicular activity in daylight & 0.7 & 0.6 & 0.5 \\ \hline Detect human activity at night & 0.7 & 0.6 & 0.5 \\ \hline Detect vehicular activity at night & 0.7 & 0.6 & 0.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: UAV Case Study with Relaxed, Original, and Constrained Requirements. Figure 8: Effects of Requirements on the UAV’s Feasible Tradespace [43]. in Daylight\", and \"UAS weight\" did not affect the feasible tradespace at all, given the relaxed, original, and constrained values. It is important to note that analysts should not focus only on the number of feasible designs. Instead, they should evaluate the model's entire output. Knowing the change in the number of feasible designs provides useful information, but we find additional insights by analyzing the entire set of results. These results can provide insights into the quality of the feasible designs produced by the requirement changes.