Abstract
Designers have historically used existing solutions as a baseline for modifying and improving the next generation solution. However, it is also possible that certain design solutions are pursued by designers irrelevant of previous design history, suggesting that there is some dominant system architecture for a given set of requirements. While the reason for system architecture similarities can never be determined with certainty without consulting designers, it is possible to speculate about why design decisions might have been made, especially when certain system architectures and design elements have dominated a space for so long. The NASA SL Challenge serves as a compelling area for study, given that NASA SL vehicle and recovery performance requirements are similar each year, while payload integration and payload function requirements differ each year. Student design teams are tasked with designing a new launch vehicle and payload each year to meet all of the requirements. Despite yearly changes in payload requirements, some teams’ vehicle architectures remain largely unchanged, prompting a question of whether these design solutions are inherently used because of the nature of the design problem or if it is a reuse of previous design solutions. To investigate this question, we relate system requirements to vehicle elements using a DSM-style requirements mapping process. These relationships are then translated into tree structures that are centered around a single element/requirement. Finally, the tree structures are analyzed to determine why certain design solutions may have been selected based on entanglement between requirements. These mappings are used to identify areas of tension between requirements and independent variables within system architectures for a NASA SL team. Our analysis of the mappings allows us to suggest that certain elements of system architectures or mission profile may be more dominant, that is more favorable, based solely on the design problem definition. In NASA SL for example, teams could target a lower apogee because it aids in meeting entangled recovery requirements. In future work we will explore how requirements mapping can be used to identify dominant architectures during the conceptual phase of design. Finally, based on observations made in this case study, there is evidence that requirements mappings could help guide the strategic placement of excess in a system. Future work is needed to determine how requirements mapping could support the placement of excess and to explore how to conduct requirements mapping in a streamlined and efficient way.
