Chapter 4: System Design

The system design processes are four interdependent, highly iterative and recursive processes, resulting in a validated set of requirements and a validated design solution that satisfies a set of stakeholder expectations. The four system design processes are to develop stakeholder expectations, technical requirements, logical decompositions, and design solutions.

These processes start with a study team collecting and clarifying the stakeholder expectations, including the mission objectives, constraints, design drivers, operational objectives, and criteria for defining mission success. This set of stakeholder expectations and high-level requirements is used to drive an iterative design loop where a strawman architecture/design, the concept of operations, and derived requirements are developed. These three products must be consistent with each other and will require iterations and design decisions to achieve this consistency. Once consistency is achieved, analyses allow the project team to validate the design against the stakeholder expectations. A simplified validation asks the questions: Does the system work? Is the system safe and reliable? Is the system achievable within budget and schedule constraints? If the answer to any of these questions is no, then changes to the design or stakeholder expectations will be required, and the process started again. This process continues until the system—architecture, ConOps, and requirements—meets the stakeholder expectations. Once the system meets the stakeholder expectations, the study team baselines the products and prepares for the next phase.

Stakeholders can be classified as customers and other interested parties. Customers are those who will receive the goods or services and are the direct beneficiaries of the work. Other interested parties are those who affect the project by providing broad, overarching constraints within which the customers’ needs must be achieved. These parties may be affected by the resulting product, the manner in which the product is used, or have a responsibility for providing life-cycle support services.

Defining stakeholder expectations begins with the mission authority and strategic objectives that the mission is meant to achieve. Mission authority changes depending on the category of the mission. An early task in defining stakeholder expectations is understanding the objectives of the mission. Defining the objectives is done by eliciting the needs, wants, desires, capabilities, external interfaces, assumptions, and constraints from the stakeholders. Arriving at an agreed-to set of objectives can be a long and arduous task. The proactive iteration with the stakeholders throughout the systems engineering process is the way that all parties can come to a true understanding of what should be done and what it takes to do the job. The project team should also identify the constraints that may apply. A constraint is a condition that must be met.

Operational objectives also need to be included in defining the stakeholder expectations. The mission and operational success criteria define what
the mission must accomplish to be successful. The design drivers will be strongly dependent upon the ConOps [Concept of Operations]. The end result of this step is the discovery and delineation of the system’s goals, which generally express the agreements, desires, and requirements of the eventual users of the system.

The Technical Requirements Definition Process transforms the stakeholder expectations into a definition of the problem and then into a complete set of validated technical requirements expressed as “shall” statements that can be used for defining a design solution for the Product Breakdown Structure (PBS) model and related enabling products. Technical requirements definition activities apply to the definition of all technical requirements from the program, project, and system levels down to the lowest level product/component requirements document. Typical inputs needed for the requirements process would be the agreed-to top-level requirements and expectations and the Concept of Operations which describes how the system will be operated during the life-cycle phases to meet stakeholder expectations. The top-level requirements and expectations are initially assessed to understand the technical problem to be solved and establish the design boundary. Typical outputs for the Technical Requirements Definition Process would include Technical Requirements and Technical Measures.

Logical Decomposition is the process for creating the detailed functional requirements that enable NASA programs and projects to meet the stakeholder expectations. Logical decomposition utilizes functional analysis to create a system architecture and to decompose top-level (or parent) requirements and allocate them down to the lowest desired levels of the project. Once the top-level (or parent) functional requirements and constraints have been established, the system designer uses functional analysis to begin to formulate a conceptual system architecture. Functional analysis is the primary method used in system architecture development and functional requirement decomposition. It is the systematic process of identifying, describing, and relating the functions a system must perform to fulfill its goals and objectives.

The Design Solution Definition Process is used to trans­late the high-level requirements derived from the stake­ holder expectations and the outputs of the Logical De­composition Process into a design solution. This involves transforming the defined logical decomposition models and their associated sets of derived technical require­ ments into alternative solutions. These alternative solu­tions are then analyzed through detailed trade studies that result in the selection of a preferred alternative. This preferred alternative is then fully defined into a final de­sign solution that will satisfy the technical requirements.