Inputs and Outputs for Defining a System

The tools and processes used to define the system via the steps of requirements analysis, functional analysis, design synthesis and verification can be divided into those that treat the system as a single element, i.e. treat the relationships and interfaces between the system and its environment and other entities; and those that decompose the system into subsystems and treat the relationships and interfaces between the subsystems.  (Verification is treated in a subsequent chapter as a systems engineering task called Verifying the Technical Performance.) Think of Figure 6-4 in the previous post being the process for a system as a single entity and then think of this process being repeatedly applied to each decomposed element of the system hierarchy.

The INCOSE Handbook defines a system hierarchy as:

• System
• Element
• Subsystem
• Assembly
• Subassembly
• Component
• Part

In this material the INCOSE hierarchy is followed with one exception; the term element is left out of the hierarchy and is used for which ever level of the hierarchy is being considered. That is the term design element refers to the system, subsystem, assembly, subassembly, component or part being analyzed or designed.

As elements become less complex the systems engineering work for each loop becomes less and less but does not vanish. For example, the functional analysis needed for a fastener is rudimentary but it is necessary to think through, if not document,  whether the fastener is required to maintain stability of the parts it is holding in three dimensions, allow translation in one or two dimensions or rotation around its axis. This is one of the reasons it is troublesome to distinguish between systems engineers and design engineers. The design engineers must execute the processes defined in Figure 6-4 to some degree depending on the complexity of the element they are designing.

Although a key methodology for requirements analysis, Use Case analysis is treated only lightly in this chapter. It is covered in more detail in a separate chapter because it is particularly important for supporting model based approaches. Assessment and management of risk is such an important technical management process that it is also treated in a subsequent chapter, as is the trade study task of selecting the preferred design.

It is hoped that the complexity of treating systems engineering processes via a different set of tasks rather than the obvious choice defined by the DoD diagram shown in Figure 6-4 is offset by the benefits to the reader of having to think about systems engineering in more than one way and that this will encourage thinking that may lead to new and better methods that will be needed in the future as systems continue to become more and more complex.

6.2 Inputs and Outputs of the Systems Engineering Process

Before beginning to describe the methods and tools used to execute each block and loop in the systems engineering process as defined in Figure 6-4 it is helpful to define the inputs to the overall process and the desired outputs.  A partial list of inputs is provided in Figures 3-1 and 4.2 of the DoD SEF. These inputs are partitioned into the three categories: Inputs to be converted to Outputs, Controls and Enablers. A more complete list of inputs in these three categories plus a fourth category of Constraints Imposed by Internal Resources includes:

• Inputs to be Converted to Outputs:
• Customer Needs/Objectives/Requirements (Part of The Voice of the Customer)
• Missions
• Measures of Effectiveness (MOE)
• Sys. Eng. Output Documentation (Patterns and Templates), Models, Simulations from Prior Development Efforts and from Internal Investments
• Controls:
• Technology Base available from Strategic Partners, Teammates, Suppliers and from Internal Investments
• Requirements Applied Through Specifications and Standards
• Laws and Organizational Policies and Procedures
• Customer Imposed Constraints (Budgets, Schedules, Documentation & Reporting Requirements, Other)
• Integration & Test and Utilization Environments
• Product/Competitive Strategies
• Program Decision Requirements (How the customer will make decisions; including which requirements are most important to the customer.)
• Enablers:
• Decision and Requirements Data Bases from Prior Development Efforts
• Multi-disciplinary Product Development Teams
• Development Organization’s Domain Knowledge
• Constraints Imposed by Internal Resources
• Engineering and Production Skills Availability
• Production Process Availability and Maturity
• Integration,  Test and Production Facilities and Capital Budget

This list does not include two items from Figure 4-2 of the DoD SEF. Maintenance Concept and Other Life-Cycle Function Planning is assumed here to be included in Customer Needs/Objectives/Requirements. System Analysis and Control is viewed here as part of the Systems Engineering Process rather than an enabler.

The list includes items contained in documentation supplied by the customer and items that are related to the organization’s capabilities. The inputs are usually incomplete in that there are requirements that are necessary but not initially known. These requirements must be derived during the systems engineering work. It is not unusual for the customer’s statement of needs, objectives and requirements to be incomplete, ambiguous or even contradictory when examined in detail.

As discussed in chapter 1 sometimes customers expect the development organization to complete the development of the input requirements, working closely with the customer, as part of the system development. Also, sometimes customers specify mission level requirements so that considerable systems analysis is needed to define system requirements that will satisfy the mission needs. Any constraints imposed by the enterprise’s product/competitive strategies and internal resources that impact the product design should be identified and documented in the IMP during the project planning. Finally, note that some of the items on the list are easily defined, e.g. specifications and the internal constraints listed, and some are not, e.g. the organization’s domain knowledge (Domain knowledge is the detailed knowledge of the customer’s mission and of the systems used to satisfy this mission).

The outputs of the systems engineering process are dependent on the level of the system hierarchy and include:

·         Baseline Design (System Specification, ICD, Functional Diagrams, & Physical Diagrams)

·         System Design Database

o   Requirements database

o   System Design Document (SDD) that captures Baseline Design Diagrams and:

§  Updated Information Architecture and Document Tree

§  Various diagrams, tables and matrices used to analyze, derive and verify requirements (e.g. context diagrams, Concept of Operation/Use Case diagrams and QFD tables)

§  TPMs, KPPs, MOEs for Baseline Design

§  Design Verification Plans

§  Failure Analysis Database

o   Configuration Management Database

o   Decision Database

o   Data Dictionary

·         Updated Pattern &Template Database

·         Expanded/Refined Models & Simulations

·         Updated Risk Register

·         Refined Technology Base Knowledge, including Updates to Qualified Supplier Capabilities

·         Updates to Manufacturing, System Integration and Test Process/Facility Plans

Some of the outputs are new documentation, some are updates to existing documentation/databases, some are updates or new data for organizations supporting the engineering team and some is captured only in the skills and domain knowledge of the development team. Comparing the list of inputs and outputs for the systems engineering process begins to reveal the breadth and depth of work and the thousands upon thousands of decisions being made in the systems engineering work. Without the use of modern methods and tools this work can be time consuming, expensive and error prone. Shortchanging this work often causes product design problems that are far more costly than thorough systems engineering and does not build the capabilities of the enterprise for future product developments.

The system design process is fundamentally a requirements analysis process even though it is divided into the tasks shown in Figure 6-4. The output requirements are expressed in three different ways or from three different perspectives as defined in the DoD SEF. These different perspectives are called the Operational, Functional and Physical views:

·         The Operational view describes the operational behavior of the system; how it does its job, how well and under what conditions.

·         The Functional view describes what the system must do to achieve the required operational behavior.

·         The Physical view describes how the system is constructed and how it interfaces with other systems and system operators.

The collection of documentation, diagrams, etc. developed under the Requirements Analysis task constitutes the Operational view. Similarly the products resulting from the Functional Analysis and Allocation task are the Functional view and the products resulting from the Design Synthesis task are the Physical view. Readers are referred to Chapter 4 of the DoD SEF for a listing of information that might typically be included in each view. Our emphasis here is on the rational for the systems engineering tasks and describing methods and tools useful in these tasks rather than trying to exhaustively list every task and every output.