Difference between revisions of "System Definition"
| Line 41: | Line 41: | ||
For more details about Systems Approaches, read (Jackson, Hitchins, and Eisner, 2010), and (Hitchins, 2007). | For more details about Systems Approaches, read (Jackson, Hitchins, and Eisner, 2010), and (Hitchins, 2007). | ||
| − | + | ===Ontologies=== | |
| + | System definition depends on good ontological structure. See the discussion in [[Systems Engineering and Management]]. | ||
---- | ---- | ||
Revision as of 18:57, 31 August 2011
Systems Definition encompasses the activities in the systems engineering process that precede Systems Realization.
Topics
The topics contained within this knowledge area include:
- Fundamentals of System Definition
- Mission Analysis and Stakeholders Requirements
- System Requirements
- Architectural Design
- 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 life cycle. The processes of System Definition include mission analysis and stakeholder requirements, system requirements, architectural 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 the problem to the solution
In a top-down approach, the System Definition activities are focused primarily on understanding the problem, the conditions that constrain the system, and the design of solutions. The outcomes of the System Definition are used for the System Realization, System Deployment and Use, and Product and Service Life Management. In this approach, System Definition includes the activities that are completed primarily in the front-end portion of the system design and the design itself. These consist of mission analysis and stakeholders’ requirements, system requirements, architectural design, and system analysis. Top-down activities can be sequential, iterative, or evolutionary.
- Mission Analysis and Stakeholder Requirements focus on the identification and definition of stakeholders' needs, the development of operational and environmental conditions, of operational concepts, and the definition of applicable constraints.
- These elements then are used for the development of system requirements that consists of the refinement and translation of the stakeholders’ requirements into System (technical) Requirements.
- These System Requirements are then utilized as inputs to the Architectural Design, which includes functional architecture, dynamic behavior, and physical architecture.
- System Analysis studies are performed to evaluate and select potential System Elements that compose the system and to select the most suitable. System Analysis provides a “best value,” balanced solution involving all the relevant engineering elements (Stakeholder Requirements, System Requirements, and architectural Design Properties).
Bottom up approach and evolution of the solution
During the product and service Life Management, and because of evolution of the context of use, or for improvement purpose of the existing solution, engineers are led to reconsider the System Definition in order to modify or adapt some structural, functional, or temporal properties. Before attempting to any modification, and because of the existence of the System-of-Interest (SOI), a reverse engineering is often necessary to (re)characterize its own properties or those of its systems or system elements.
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements into design architecture. Changes in the context of use or a need for improvement can prompt this. By contrast, a top-down approach in 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 often 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 by what is feasible in the solution space. System Analysis activities are used to perform the link between the two areas.
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 and 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 (Jackson, Hitchins, and Eisner, 2010), and (Hitchins, 2007).
Ontologies
System definition depends on good ontological structure. See the discussion in Systems Engineering and Management.
References
Citations
Faisandier. 2011. Engineering and architecting multidisciplinary systems. (expected--not yet published).
Hitchins, Derek. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ,USA: John Wiley & Sons.
Jackson, Scott, Derek Hitchins, and Howard Eisner. 2010. "What is the Systems Approach?" INCOSE Insight, April, 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. INCOSE systems engineering handbook, version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.
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 Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 15288:2008 (E).
NASA. 2007. Systems engineering handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
Additional References
Faisandier. 2011. Engineering and architecting multidisciplinary systems. (expected--not yet published).
Hitchins, Derek. 2007. Systems Engineering: A 21st Century Systems Methodology. Edited by A. P. Sage, Wiley Series in Systems Engineering and Management. Hoboken, NJ: John Wiley & Sons.
ISO. 2007. Systems engineering and design. Geneva, Switzerland: International Organization for Standardization (ISO), ISO 10303-AP233.
Jackson, Scott, Derek Hitchins, and Howard Eisner. 2010. What is the Systems Approach? INCOSE Insight, April, 41-43.
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY: McGraw-Hill.