System Definition

System definition is a set of core technical activities of systems engineering , including the activities that are completed primarily in the front-end portion of the system design . These consist of the definition of system requirements, design of the physical and logical system architecture, and system analysis.

System definition activities build on the artifacts and decisions conducted during Concept Definition, primarily the articulation of the mission of the system of interest and the needs and requirements of stakeholders. The products of system definition activities (system requirements, architecture, etc.) are inputs to System Realization. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.

Topics

The topics contained within this knowledge area include:

System Definition Activities

System definition is the set of technical creative activities of systems engineering (SE). The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected development cycle model . The processes involved with system definition include the development of system requirements, design of the physical and logical system architecture, and system analysis. The system definition processes and activities are also applied recursively at each successive level of the system hierarchy. (See the discussion of "iteration" and "recursion" in the Part 3 Introduction.

Top-Down Approach: from Problem to Solution

In a top-down approach, system definition activities are focused primarily on understanding the problem, the conditions that constrain the system, and the design of solutions. Outcomes of system definition are used for system realization, system deployment and use, and product and service life management. In this approach, system definition includes activities that are completed primarily in the front-end portion of system design and the design itself. Top-down activities can be sequential, iterative, or evolutionary. These activities are based on the results of Mission Analysis and the definition of Stakeholder Needs and Requirements and generally consist of the development of system requirements that consist of the refinement and translation of the stakeholder requirements into system (technical) requirements. These system requirements are then used as inputs for the logical architecture design, which includes functional, behavioral, temporal, and physical architectural aspects. System Analysis studies are performed to evaluate and select the potential system elements that compose the system and are the most suitable. System analysis is intended to provide a best value, balanced solution involving all relevant engineering elements (stakeholder requirements, system requirements, and design properties).

Bottom-Up Approach: Evolution of the Solution

Engineers are led to reconsider system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the product or service life cycle to adapt to a changing context of use or for the purpose of improving existing solutions. reverse engineering is often necessary to enable system engineers to (re)characterize the properties of the system of interest (SoI) or its elements; this is an important step to ensure that system engineers understand the SoI before beginning modification.

A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design architecture . Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.

Bottom-up and top-down approaches can be, and often are, mixed.

Separation and Iteration between Problem and Solution

Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. (For more information on problem definition, please see Concept Definition.) System analysis activities are used to perform the link between problems and solutions.

As systems generally integrate existing and new system elements , a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities they provide in order to define applicable interface requirements and constraints. As discussed in System Life Cycle Process Models: Iterative, this is iterative for these evolutionary systems.

For more details about systems approaches, please see the Systems Approach topic. In addition, the references “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and A 21st Century Systems Methodology (Hitchins 2007) are recommended.

Ontologies

System definition depends on good ontological structure. See the discussion in Systems Engineering and Management.

Overview of ontology elements related to System Definition activities

An engineering ontology can be represented using Entity-Relationship Diagrams or Classes Diagrams. Figure 1 shows a simplified meta-data model for System Definition. The entities are logically grouped according to activities. As they are progressively instantiated, the entities and their relationships represent the maturity of the progress of the system definition. Rather than providing a fixed work flow of activities, the relationships between the entities allow to select several threads of activities depending of project type, and of availability or maturity of engineering data at a given time.

Figure 1. A simplified ontology for System Definition(Faisandier 2012) Reprinted with permission of © Alain Faisandier

References

Works Cited

Faisandier, A. 2011 (unpublished). Engineering and Architecting Multidisciplinary Systems.

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.

Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight (April 2010): 41-43.

Primary References

ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.

INCOSE. 2010. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1

ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 19760:2003 (E).

ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008.

NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.

Additional References

Faisandier. 2011 (unpublished). Engineering and Architecting Multidisciplinary Systems.