Difference between revisions of "System Definition"

Revision as of 18:56, 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:

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).

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.

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

@@ Line 1: / Line 1: @@
-'''Introductory Paragraphs'''
+Systems Definition encompasses the activities in the systems engineering process that precede Systems Realization.
 ==Topics==
 The topics contained within this knowledge area include:
@@ Line 11: / Line 11: @@
 ----
-==Introduction to System Definition Knowledge Area==
-===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 concurrently depending of the selected development cycle or [[Life Cycle (glossary)|life cycle]]. The activities of a process are not performed only on a sequential mode but they may interact between themselves and also with activities of other related processes. The processes of System Definition include mission analysis and stakeholder requirements, system requirements, architectural design, and system analysis topics. Execution of processes requires several iterations and feedbacks between each others. The system definition processes and activities are also applied recursively at each successive levelof the system hierarchy.  See the discussion of iteration and recursion in the Part 3 Introduction: [[Systems Engineering and Management]].
+==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 (glossary)|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.
+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 Requirement (glossary)|Stakeholder Requirements]]''' focus on the identification and definitions of stakeholders' needs, the development of operational and environmental conditions, of operational concepts, and the definition of applicable constraints.
+*'''Mission Analysis and [[Stakeholder Requirement (glossary)|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 Requirement (glossary)|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 (glossary)|functional architecture]], dynamic behavior, and [[Physical Architecture (glossary)|physical architecture]]in addition to temporal and decision levels.
+*These System Requirements are then utilized as inputs to the '''Architectural Design''', which includes [[Functional Architecture (glossary)|functional architecture]], dynamic behavior, and [[Physical Architecture (glossary)|physical architecture]].
-*'''System Analysis''' studies are performed to evaluate and select potential System Elements that compose the system and to compare potential architectures and to select the most suitable one. Finally, System Analysis provides a “best value” balanced solution involving all the relevant engineering elements (Stakeholder Requirements, System Requirements, and architectural Design Properties).
+*'''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).
-Note: "Top-down" does not mean that activities are made sequentially; a lot of feedbacks are necessary between activities. As example, because of complexity and emergence, design can identify an essential property that is needed to include as a System Requirement. Other examples come from interaction between design and system analysis studies.
 ====Bottom up approach and evolution of the solution====
@@ Line 33: / Line 30: @@
 During the [[Product (glossary)|product]] and [[Service (glossary)|service]] Life Management, and because of evolution of the [[context (glossary)|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 (glossary)|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 (glossary)|architecture]]. On the contrary, a top-down approach in generally used to define a design solution corresponding to a problem or a set of needs.
+A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements into design [[architecture (glossary)|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.
-So, in the real life of a System-of-Interest, bottom-up and top-down approaches are often mixed in order to engineer new solutions and/or to re-engineer or re-use existing [[Product (glossary)|products]], [[Service (glossary)|services]], [[Enterprise (glossary)|enterprises]], physical or functional models, requirements, systems, system elements, etc.
+Bottom-up and top-down approaches can be and often are often mixed.
 ====Separation and iteration between Problem Area and Solution Area====
-Inside the System Definition activities, the Systems Engineering discipline makes a significant distinction between the definition of the problem and the design of the solution. Too often, the design team will develop solutions elements ("how the system must be done") without sufficiently defining the problem to be solved and the constraints to respect ("what the system must do").
+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.
-To correctly engineer a system, it is recommended to use in a first step a top-down approach differentiating the activities that treat the problem area in terms of needs, expectations, constraints, and requirements from those that treat the solution area in terms of functional, behavioral, physical design. Nevertheless, the two must work together and iteratively. The design of the solution is made of decisions and trade-offs according to requirements, constraints and enterprises capabilities (know-how, technological control, financial capability, etc.). This work requires several iterations and feedbacks tuning the couple "problem-solution". System Analysis activities are used to perform the link between the two areas.
+As systems generally integrate existing and new [[System Element (glossary)|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.
-The distinction between the two areas shall be effective on each level of the system breakdown structure – see Figure 2 in [[Systems Engineering and Management]] introduction.
+For more details about Systems Approaches, read (Jackson, Hitchins, and  Eisner, 2010), and (Hitchins, 2007).
-Most of the time, the systems are not created from scratch and generally integrate existing [[System Element (glossary)|System Elements]]. A bottom-up approach is used in parallel of the top-down approach to take into account such elements (as legacy systems or products and services for example), and consists to identify the services and capabilities they provide in order to define applicable interface requirements and constraints.
-For more details about Systems Approaches, read (Jackson, Scott, Derek Hitchins, and Howard Eisner. 2010), and (Hitchins, Derek. 2007).
-----
-===Ontology for System Development===
-An engineering ontology can be represented using Entity-Relationship Diagrams or Classes Diagrams. Figure 1 below shows a simplified and truncated view of a meta-data model for system development. The entities are logically grouped according to the activities. One can distinguish three views of the system that correspond also to three states of the system during development:
-*the system "'''as required'''", represented by [[System Requirement (glossary)|System Requirements]] that are obtained by refinement of the [[Stakeholder Requirement (glossary)|Stakeholder Requirements]];
-*the system "'''as designed'''", represented by [[Functional Architecture (glossary)|Functional Architecture]] and behavioral models or [[Scenario (glossary)|Scenarios]] (generally composed of [[Function (glossary)|Functions]], [[Input-Output Flow (glossary)|Input-Output Flows]], and/or [[Operational Mode (glossary)|Operational Modes]] and [[Transition of Modes (glossary)|Transition of Modes]] and by [[Physical Architecture (glossary)|Physical Architecture]] models (composed of [[System Element (glossary)|System Elements]], [[Physical Interface (glossary)|Physical Interfaces]], [[Port (glossary)|Port]] and their associated [[Design Property (glossary)|Design Properties]];
-*the system "'''as realized'''", represented by a [[Product (glossary)|product]], a [[Service (glossary)|service]] or an [[Enterprise (glossary)|enterprise]]; those last integrate [[Implemented Element (glossary)|Implemented Elements]] characterized by a set of [[Measured Property (glossary)|Measured Properties]].
-[[File:SEBoKv05_KA-SystDef_A_simplified_meta-data_model_for_system_development.png|700px|center|A simplified view of a meta-data model for system development.]]
-Figure 1. A simplified view of a meta-data model for system development (Faisandier. 2011)
-As they are progressively instantiated, the entities and their relationships represent also the maturity of the progress of the development of the system. Rather than providing a fixed work flow of activities, the relationships between the entities allow to select several threads of activities and tasks depending of the project type, and of the availability or maturity of the engineering data at a given time.
-====Approaches supported by the ontology====
-Such ontology supports easily different approaches for life cycle purposes such as top-down, bottom-up or mixed approaches.
-*A top-down approach can be used starting from the left of the diagram such as:
-**Stakeholders write Stakeholder Requirements that are then translated by System Requirements;
-**those last are then satisfied by design elements, in particular Functions that are then performed by System Elements, and Input-Output Flows that are carried by Physical Interfaces;
-**the System Elements and Physical Interfaces are implemented by Implemented Elements depending of the selected technologies;
-**finally these last elements are integrated into intermediate [[Aggregate (glossary)|aggregates]] till obtaining the final realized System of Interest (Product, Service or Enterprise).
-All along the design activity, the Design Properties of the system architecture can be assessed and compared to [[Assessment Criterion (glossary)|assessment criteria]] extracted from the System Requirements. This allows to identify discrepancies, and then to tune the design or to decide modifications of the requirements (System Analysis). When the system is realized and in operation, the Measured Properties can be compared to the Design Properties and to the System Requirements. These comparisons allow to identify the correct performance of the system.
-*But a bottom-up approach associated to reverse engineering can also be used in order to re-structure / architect existing systems to fit with the evolution of the context of use.
-**First the Implemented Elements are identified, and then the System Elements and Physical Interfaces that correspond are identified in their turn.
-**The second step of reverse engineering consists to identify the Functions performed by the System Elements and the Input-Output Flows carried by the Physical Interfaces. This makes possible to establish physical and functional architecture models of the existing system.
-**Finally, it is possible to characterize the existing system by a set of Design Properties and System Requirements extracted from Physical and Functional Architecture models.
-**Any modification of what exists (re-engineering) is then possible reconsidering new System Requirements or evolutions in a top-down approach.
-Because of evolution of the context of use of a system during its life cycle, it is essential that the set of its engineering data and models are permanently consistent, updated and accessible.
-----
-===Overview of ontology elements related to System Definition activities===
-The Figure below shows a synthetic view of the same meta-data model as above but restricted to System Definition and extended with the main relationships used during System Definition.
-[[File:SEBoKv05_KA-SystDef_A_simplified_ontology_for_System_Definition.png|700px|center|A simplified ontology for System Definition.]]
-Figure 2. A simplified ontology for System Definition (Faisandier. 2011)
-Based on the overview of the figure above, a set of major ''entities'', ''attributes'', and ''relationships'' are suggested and detailed in the topics of the System Definition knowledge area.
@@ Line 136: / Line 75: @@
 ===Additional References===
-All additional references should be listed in alphabetical order.
 Faisandier. 2011. Engineering and architecting multidisciplinary systems. (expected--not yet published).