System Definition
Systems Definition encompasses the activities in the systems engineering process that precede system realization.
Topics
The topics contained within this knowledge area include:
- Fundamentals of System Definition;
- Mission Analysis and Marketing Analysis;
- Stakeholders Requirements;
- system requirements;
- Logical Architecture Design;
- Physical Architecture Design; and
- system analysis.
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 Mission Analysis and Marketing Analysis, Stakeholder Requirements, System Requirements, Logical Architecture Design, Physical Architecture Design and System Analysis topics. 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: Systems Engineering and Management.
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 consist of the followings.
- Mission Analysis and Marketing Analysis initiate the life cycle of a potential System of Interest that could answer a problem to be solved or an opportunity for developing a new Product, Service or Enterprise. These studies conduct to identification of stakeholders and their needs, development of operational concepts, identification of environmental conditions, and constraints.
- stakeholder requirements consolidate the initial engineering elements related a System of Interest, or those related to a system or a System Element defined in the context of the physical architecture of a parent system; from a set of needs, expectations, goals or objectives are defined clear, concise, and verifiable Stakeholder Requirements.
- These elements are then used for 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 architecture , Behavioral Architecture, Temporal Architecture, and for physical architecture .
- System Analysis studies are performed to evaluate and select the potential System Elements that compose the system and are the most suitable. System Analysis provides a best value, balanced solution involving all relevant engineering elements (Stakeholder Requirements, System Requirements, and Design Properties).
Bottom-Up Approach and 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 and service life cycle because the context of use evolves 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 Area and Solution Area
Problem definition and solution design depend on each other. Solutions should respond to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. 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 is used 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, read “What Is the Systems Approach?” (Jackson, Hitchins, Eisner 2010, 41-43) and A 21st Century Systems Methodology (Hitchins 2007).
Ontologies
System definition depends on good ontological structure. See the discussion in Systems Engineering and Management.
TEXT TO BE ADDED
References
Citations
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.
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.
ISO. 2007. Systems Engineering and Design. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight (April 2010): 41-43.
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.