On February 4, 2008, Admiral Paul Sullivan, Commander of the Naval Sea Systems Command, sent out a letter entitled: Ship Design and Analysis Tool Goals. The purpose of the widely distributed memorandum was to state the requirements and high‐level capability goals for NAVSEA design synthesis and analysis tools. In this memo, Admiral Sullivan expressed the need for evolving models and analysis tools to be compatible with, among other things, set‐based design (SBD). Admiral Sullivan's memo was a major step toward improving ship design programs with new, more powerful analytical support tools but many have asked, “What is Set‐Based Design and how does it relate to Naval Ship Design?” SBD is a complex design method that requires a shift in how one thinks about and manages design. The SBD paradigm can replace point‐based design construction with design discovery; it allows more of the design effort to proceed concurrently and defers detailed specifications until trade‐offs are more fully understood. This paper describes the principles of SBD citing improvements SBD in design practice that have set the stage for SBD, and relating these principles to current Navy ship design issues.

The Ship to Shore Connector (SSC), a replacement for the Landing Craft, Air Cushion (LCAC), is the first government‐led design of a ship in over 15 years. This paper will discuss the changes that a government‐led design presents to the design approach, including schedule, organization structure, and design methodology. While presenting challenges, a government‐led design also afforded the opportunity to implement a new technique for assessing various systems and ship alternatives, set‐based design (SBD). The necessity for implementing SBD was the desire to design SSC from a blank sheet of paper and the need for a replacement craft in a short time frame. That is, the LCACs need to be replaced and consequently the preliminary design phase of the SSC program will only be 12 months. This paper will describe SBD and how it was applied to the SSC, the challenges that the program faced, and an assessment of the new methodology, along with recommendations that future design programs should consider when adopting this approach.

Perhaps the most important reason Systems Engineering exists as a discipline lies in the observation that complex systems cannot be treated merely as an assemblage of so many building blocks. Systems Engineering employs techniques and practices that attempt to consider the whole throughout the design process. Systems Engineering offers quite an assortment of processes, and tools devices to capture, describe, derive, and otherwise characterize various aspects of systems under design or analysis. There are many evolving Systems Engineering processes and practices, including processes in which the object‐oriented paradigm dominates. Unfortunately, the set of available processes, models, and tools remains weakest where they are needed the most: where decision tradeoffs are most negotiable, where “requirements” are not yet firmly established, where the use of legacy systems can have the greatest impact, and where the (projected) life cycle impacts of such decisions are greatest. This paper describes a new system development practice named Decision Oriented Systems Engineering (DOSE). If consistently and diligently applied in tandem with other more conventional practices, DOSE provides a solid Systems Engineering “hook” to the application of Human Systems Integration principles and offers considerable promise in simplifying the design of even the most complex systems involving teams working with mixes of new, evolving, and legacy systems.