Difference between revisions of "System Definition"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 13 November 2023" to "SEBoK v. 2.9, released 20 November 2023")
 
(354 intermediate revisions by 15 users not shown)
Line 1: Line 1:
−
'''Introductory Paragraphs'''
 
−
==Topics==
 
−
The topics contained within this knowledge area include:
 
−
*[[Fundamentals of System Definition]]
 
−
*[[Mission Analysis and Stakeholders Requirements]]
 
−
*[[System Requirements]]
 
−
*[[Architectural Design]]
 
−
*[[System Analysis]]
 
−
 
−
 
 
----
 
----
 +
'''''Lead Authors:''''' ''Alan Faisandier, Garry Roedler'', '''''Contributing Author:''''' ''Rick Adcock''
 +
----
 +
{{Term|System Definition (glossary)|System definition}} activities are conducted to create and describe in detail a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) to satisfy an identified need. The activities are grouped and described as generic processes, which consist of system requirements definition, system architecture definition, system design definition and system analysis. The architecture definition of the system may include the development of related logical architecture models and physical architecture models. During and/or at the end of any iteration, gap analysis is performed to ensure that all system requirements have been mapped to the architecture and design.
  
−
==Introduction to System Definition Knowledge Area==
+
System definition activities build on the artifacts and decisions from {{Term|Concept Definition (glossary)|concept definition}}, primarily the articulation of the {{Term|Mission (glossary)|mission}} of the (SoI), the {{Term|Stakeholder Requirement (glossary)|needs and requirements of stakeholders}}, and preliminary operational concepts.  See [[Life Cycle Processes and Enterprise Need]] for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in concept definition to the system and system element level of abstraction addressed in system definition.
  
−
===System Definition activities===
+
The products of system definition activities (system requirements, architecture and design) are inputs to {{Term|System Realization (glossary)|system realization}}.  
−
 
 
−
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)]]. 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]]. 
 
−
 
 
−
====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.
 
−
 
 
−
*'''Mission Analysis and [[Stakeholder Requirement (glossary)|Stakeholder Requirements (glossary)]]''' 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.
 
−
*These elements then are used for the development of '''System Requirements (glossary)''' 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)]], dynamic behavior, and [[Physical Architecture (glossary)]]in addition to temporal and decision levels.
 
−
*'''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).
 
−
 
 
−
 
 
−
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====
 
−
 
 
−
During the [[Product (glossary)]] and [[Service (glossary)]] Life Management, and because of evolution of the [[context (glossary)]] 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, a [[Reverse Engineering (glossary)]] 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)]]. On the contrary, a top-down approach in generally used to define a 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, (sub) systems, etc.
 
−
 
 
−
====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").
 
−
 
 
−
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.
 
−
 
 
−
The distinction between the two areas shall be effective on each level of the system breakdown structure – see Figure 2 above.
 
−
 
 
−
Most of the time, the systems are not created from scratch and generally integrate existing [[System Element (glossary)|System Elements (glossary)]]. 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).
 
  
 +
The specific activities and sequence of system definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with concept definition and system realization activities, will be dependent upon the type of {{Term|Life Cycle Model (glossary)|life cycle model}} being utilized. See [[Applying Life Cycle Processes]] for further discussion of the concurrent, iterative and recursive nature of these relationships.
 +
==Topics==
 +
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The Kas, in turn, are divided into topics. This KA contains the following topics:
 +
*[[System Requirements]]
 +
* [[System Architecture]]
 +
*[[Logical Architecture Model Development]]
 +
*[[Physical Architecture Model Development]]
 +
* [[System Design]]
 +
*[[System Analysis]]
 +
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.
  
−
----
+
==System Views and System Elements ==
 +
An {{Term|Engineered System (glossary)}} solution to a defined concept includes a set of engineering elements, characteristics, and  properties. These elements are grouped in two ways:
 +
* Needs and requirements views
 +
* Architecture and design views
  
−
===Ontology for System Development===
+
Architecture views include the identification of the boundary and interfaces of a {{Term|System-of-Interest (glossary)|system-of-interest (SoI)}}, which may then be further refined as a collection of {{Term|System Element (glossary)|system elements}} and their relationships.
  
 +
===Needs and Requirements Views===
  
−
An engineering ontology can be represented using Entity-Relationship Diagrams or Classes Diagrams. The Figure 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:  
+
Requirements provide an overall view of the {{Term|Purpose (glossary)|purpose}} and {{Term|Mission (glossary)|mission}} which the system as a whole is intended to satisfy, as well as a technology-independent view of what the system solutions(s) should do. They are conventionally organized into two types:
  
−
*the system "'''as required'''", represented by [[System Requirement (glossary)|System Requirements]] that are obtained by refinement of the [[Stakeholder Requirement (glossary)|Stakeholder Requirements]];
+
*Business or mission requirements and {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}} are defined and discussed in the [[Concept Definition]] KA.
−
*the system "'''as designed'''", represented by [[Functional Architecture (glossary)|Functional Architecture]] and behavioral models or [[Scenario (glossary)|Scenarios (glossary)]] (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.]]
+
*{{Term|System Requirement (glossary)|System requirements}}, which describe the functions which the system as a whole should fulfill in order to satisfy the stakeholder requirements and are expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability, etc., which are called for. These collectively form the basis for {{Term|Verification (glossary)|verification}} later in the life cycle.
  
−
Figure 5. A simplified view of a meta-data model for system development (Faisandier. 2011)
+
System requirements and stakeholder requirements are closely related. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.
  
 +
The process activities that are used to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA.
  
−
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.
+
===Architecture and Design Views===
 +
A given engineered system is one solution that could address/answer a problem or an opportunity (represented through requirements views); the solution may be more or less {{Term|Complexity (glossary)|complex}}. A complex solution cannot be comprehended with a single view or model, because of the characteristics or properties of the problem/solution (see system [[complexity]]). The characteristics are structured as types or entities; types are related to each other. An instantiation of the set of types can be understood as THE architecture of the system. The majority of interpretations of system architecture are based on the fairly intangible notion of structure. Therefore, the system architecture and design is formally represented with sets of types or entities such as functions, interfaces, resource flow items, information elements, physical elements, nodes, links, etc. These entities may possess attributes/characteristics such as dimensions, environmental resilience, availability, reliability, learnability, execution efficiency, etc. The entities are interrelated by the means of relationships and are generally grouped into sets to represent views/models of the system architecture and design.  
  
−
====Approaches supported by the ontology====
+
{{Term|Viewpoint (glossary)|Viewpoints}} and {{Term|View (glossary)|views}} are sometimes specified in {{Term|Architecture Framework (glossary)|architecture frameworks}}. Views are usually generated from models. Many systems engineering practices use logical and physical views for modeling the system architecture and design.
 +
* The '''{{Term|Logical Architecture (glossary)|logical view of the architecture}}''' supports the logical operation of the system all along its life cycle, and may include functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of {{Term|Function (glossary)|functions}} and dynamic structures that describe how the mission is performed (behavior).
  
−
Such ontology supports easily different approaches for life cycle purposes such as top-down, bottom-up or mixed approaches.
+
* The '''{{Term|Physical Architecture (glossary)|physical view of the architecture}}''' is a set of {{Term|System Element (glossary)|system elements}} performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipment made of hardware, software and/or human roles).
  
−
*A top-down approach can be used starting from the left of the diagram such as:
+
The boundary of the system architecture depends on what engineers include within the scope of the SoI and outside of it.  This decision marks the transition from the characterization of the problem context to the beginnings of solution definition.
−
**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 (glossary)]] 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 (glossary)]] 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.
+
Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include the decomposition of several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements. The relationship between each layer is {{Term|Recursion (glossary)|recursive}}; as a system element is also an engineered system, it can be characterized in its turn using the previous views in its own context.  
  
−
*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.  
+
The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture and design is defined. The relationships between the outputs of concept definition and the system solution, as well as the range of other views of a system that are available to describe a more complete set of characteristics between the system elements are discussed further in the [[Logical Architecture Model Development]] and [[Physical Architecture Model Development]] sections of system definition.
−
**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.
 
  
 +
==System Synthesis and Decomposition==
  
−
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.
+
System definition is managed through methodical {{Term|Synthesis (glossary)|synthesis}} of the SoI into systems and system elements.  Solution synthesis may be top-down or bottom-up, as discussed in [[Synthesizing Possible Solutions]].  However it is done, as the system architecture definition advances, a decomposition of systems and system elements emerges; this forms a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a ''building block'', a notion introduced in (ANSI/EIA 1998), also called ''system blocks''.
  
 +
{{Term|Stakeholder Requirement (glossary)|Stakeholder requirements}} and {{Term|System Requirement (glossary)|system requirements}} exist at all layers of the SBS. In ISO/IEC/IEEE 29148 ''Systems and Software Engineering - Requirements Engineering ''(ISO 2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of the [[System Requirements|system requirements]] through levels of abstraction.  Figure 1 illustrates this approach.
  
−
----
+
[[File:SEBoKv05_KA-SystDef_Top-down_development_of_design_and_requirements.png|thumb|center|500px|center|'''Figure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
−
===Overview of ontology elements related to System Definition activities===
+
As shown in Figure 1:
−
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.
+
* The white ovals represent requirements at decreasing levels of abstraction, and the arrows represent the transformation of those requirements through the levels using the architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements.
 +
* The next transformation crosses the boundary between the problem and solution areas by converting stakeholder requirements into system requirements, reflecting the bounded solution space.
 +
* At the SoI level, the system architecture is developed, which serves to identify systems and system elements and establishes how they operate together to address the SoI requirements.  
  
−
[[File:SEBoKv05_KA-SystDef_A_simplified_ontology_for_System_Definition.png|700px|center|A simplified ontology for System Definition.]]
+
This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. At any level of this decomposition, one or more solution options may be presented as system architectures.  The process by which the solution which best fits the system requirements, associated stakeholder needs and wider life cycle concerns is selected and justified is discussed in the [[System Analysis]] process.
  
−
Figure 6. A simplified ontology for System Definition (Faisandier. 2011)
+
Figure 2 below portrays the engineering that occurs in each system block. As necessary, system elements are defined through sets of system element requirements, which become inputs to other system blocks (''level n+1''). The approach is then recursively applied using the system definition processes.
  
 +
[[File:Recursive_Instantiation_of_Def_Process_AF_071112.png|thumb|center|700px|center|'''Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
−
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.
+
At the ''n+1'' level, the systems or system elements may also collect other stakeholder requirements that are directly pertinent to this level of architecture and design. Processes within each system are generic but unique in local purpose, scope and context.
  
 +
See [[Applying Life Cycle Processes]] for a discussion of the iterative and recursive application of system requirements and architecture processes, and [[Life Cycle Processes and Enterprise Need]] for further detail on the transformation of needs and requirements to system and system element levels of abstraction.
  
−
----
+
The different aspects of how {{Term|Systems Thinking (glossary)|systems thinking}} is applicable to system definition are discussed in SEBoK Part 2. In particular, see discussion of the recursive nature of systems and engineered system contexts in [[Engineered System Context]]; the contrast between top-down and bottom-up approaches in [[Synthesizing Possible Solutions]] and the role of solution architecture options and selection in [[Analysis and Selection between Alternative Solutions]].
  
 
==References==  
 
==References==  
−
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
 
−
 
−
===Citations===
 
−
List all references cited in the article.  Note:  SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the [http://www.bkcase.org/fileadmin/bkcase/files/Wiki_Files__for_linking_/BKCASE_Reference_Guidance.pdf BKCASE Reference Guidance] for additional information.
 
−
 
−
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. 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).
 
−
 
−
 
−
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY: McGraw-Hill.
 
−
 
−
 
−
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.
+
===Works Cited===
  
 +
ANSI/EIA. 1998. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998.
  
−
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.
+
Faisandier, A. 2012. ''Systems Architecture and Design.'' Belberaud, France: Sinergy'Com.
  
 +
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Requirements Engineering''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148.
  
−
Faisandier. 2011. Engineering and architecting multidisciplinary systems. (expected--not yet published).
+
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Architecture Description.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.
  
 
===Primary References===
 
===Primary References===
−
All primary references should be listed in alphabetical order.  Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ ([[title]]).  Please do not include version numbers in the links.
 
  
−
ANSI/EIA. 1998. Processes for engineering a system. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998.  
+
ANSI/EIA. 1998. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), [[ANSI/EIA 632]]-1998.  
  
 +
Blanchard, B.S., and W.J. Fabrycky. 2005. ''[[Systems Engineering and Analysis]].'' 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
  
−
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.  
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
  
 +
ISO/IEC. 2007. ''[[ISO/IEC 26702|Systems Engineering – Application and Management of The Systems Engineering Process]]''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), [[ISO/IEC 26702]]:2007.
  
−
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/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). [[ISO/IEC/IEEE 15288]]:2015.
  
 +
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/ Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 29148]].
  
−
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/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].
  
 +
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.
  
−
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. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C., USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
−
 
 
−
 
 
−
NASA. 2007. Systems engineering handbook. Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
 
  
 
===Additional References===
 
===Additional References===
−
All additional references should be listed in alphabetical order.
+
Baldwin, C.Y. and K.B. Clark. 2000. ''Design Rules''. Cambridge, MA, USA: MIT Press.
−
 
 
−
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.
+
Buede, D.M. 2009. ''The Engineering Design of Systems: Models and Methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.  
  
 +
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
  
−
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY: McGraw-Hill.
+
Hatley, D.J., and I.A. Pirbhai. 1987. ''Strategies for Real-Time System Specification''. New York, NY, USA: Dorset House Pub.
  
 +
MOD. 2010. ''MOD Architecture Framework,'' Version 1.2.004. London, UK: UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.
  
 
----
 
----
−
====Article Discussion====
+
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center>
  
−
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
−
<center>[[Integration of Process and Product Models|<- Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Fundamentals of System Definition|Next Article ->]]</center>
 
  
−
==Signatures==
+
[[Category:Part 3]][[Category:Knowledge Area]][[Category:System Definition]]
−
[[Category: Part 3]][[Category:Knowledge Area]]
 

Latest revision as of 22:05, 18 November 2023

Lead Authors: Alan Faisandier, Garry Roedler, Contributing Author: Rick Adcock

System definitionSystem definition activities are conducted to create and describe in detail a system-of-interestsystem-of-interest (SoI) to satisfy an identified need. The activities are grouped and described as generic processes, which consist of system requirements definition, system architecture definition, system design definition and system analysis. The architecture definition of the system may include the development of related logical architecture models and physical architecture models. During and/or at the end of any iteration, gap analysis is performed to ensure that all system requirements have been mapped to the architecture and design.

System definition activities build on the artifacts and decisions from concept definitionconcept definition, primarily the articulation of the missionmission of the (SoI), the needs and requirements of stakeholdersneeds and requirements of stakeholders, and preliminary operational concepts. See Life Cycle Processes and Enterprise Need for further detail on the transformation of needs and requirements from the business or enterprise and stakeholder levels of abstraction addressed in concept definition to the system and system element level of abstraction addressed in system definition.

The products of system definition activities (system requirements, architecture and design) are inputs to system realizationsystem realization.

The specific activities and sequence of system definition activities and their involvement with the life cycle activities of any system, and in particular the close integration with concept definition and system realization activities, will be dependent upon the type of life cycle modellife cycle model being utilized. See Applying Life Cycle Processes for further discussion of the concurrent, iterative and recursive nature of these relationships.

Topics

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The Kas, in turn, are divided into topics. This KA contains the following topics:

See the article Matrix of Implementation Examples for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.

System Views and System Elements

An engineered systemengineered system solution to a defined concept includes a set of engineering elements, characteristics, and properties. These elements are grouped in two ways:

  • Needs and requirements views
  • Architecture and design views

Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI)system-of-interest (SoI), which may then be further refined as a collection of system elementssystem elements and their relationships.

Needs and Requirements Views

Requirements provide an overall view of the purposepurpose and missionmission which the system as a whole is intended to satisfy, as well as a technology-independent view of what the system solutions(s) should do. They are conventionally organized into two types:

  • System requirementsSystem requirements, which describe the functions which the system as a whole should fulfill in order to satisfy the stakeholder requirements and are expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability, etc., which are called for. These collectively form the basis for verificationverification later in the life cycle.

System requirements and stakeholder requirements are closely related. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.

The process activities that are used to identify, engineer and manage system requirements are described further in the System Requirements article in the KA.

Architecture and Design Views

A given engineered system is one solution that could address/answer a problem or an opportunity (represented through requirements views); the solution may be more or less complexcomplex. A complex solution cannot be comprehended with a single view or model, because of the characteristics or properties of the problem/solution (see system complexity). The characteristics are structured as types or entities; types are related to each other. An instantiation of the set of types can be understood as THE architecture of the system. The majority of interpretations of system architecture are based on the fairly intangible notion of structure. Therefore, the system architecture and design is formally represented with sets of types or entities such as functions, interfaces, resource flow items, information elements, physical elements, nodes, links, etc. These entities may possess attributes/characteristics such as dimensions, environmental resilience, availability, reliability, learnability, execution efficiency, etc. The entities are interrelated by the means of relationships and are generally grouped into sets to represent views/models of the system architecture and design.

ViewpointsViewpoints and viewsviews are sometimes specified in architecture frameworksarchitecture frameworks. Views are usually generated from models. Many systems engineering practices use logical and physical views for modeling the system architecture and design.

  • The logical view of the architecturelogical view of the architecture supports the logical operation of the system all along its life cycle, and may include functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of functionsfunctions and dynamic structures that describe how the mission is performed (behavior).
  • The physical view of the architecturephysical view of the architecture is a set of system elementssystem elements performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipment made of hardware, software and/or human roles).

The boundary of the system architecture depends on what engineers include within the scope of the SoI and outside of it. This decision marks the transition from the characterization of the problem context to the beginnings of solution definition.

Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include the decomposition of several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements. The relationship between each layer is recursiverecursive; as a system element is also an engineered system, it can be characterized in its turn using the previous views in its own context.

The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture and design is defined. The relationships between the outputs of concept definition and the system solution, as well as the range of other views of a system that are available to describe a more complete set of characteristics between the system elements are discussed further in the Logical Architecture Model Development and Physical Architecture Model Development sections of system definition.

System Synthesis and Decomposition

System definition is managed through methodical synthesissynthesis of the SoI into systems and system elements. Solution synthesis may be top-down or bottom-up, as discussed in Synthesizing Possible Solutions. However it is done, as the system architecture definition advances, a decomposition of systems and system elements emerges; this forms a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a building block, a notion introduced in (ANSI/EIA 1998), also called system blocks.

Stakeholder requirementsStakeholder requirements and system requirementssystem requirements exist at all layers of the SBS. In ISO/IEC/IEEE 29148 Systems and Software Engineering - Requirements Engineering (ISO 2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of the system requirements through levels of abstraction. Figure 1 illustrates this approach.

Figure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

As shown in Figure 1:

  • The white ovals represent requirements at decreasing levels of abstraction, and the arrows represent the transformation of those requirements through the levels using the architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements.
  • The next transformation crosses the boundary between the problem and solution areas by converting stakeholder requirements into system requirements, reflecting the bounded solution space.
  • At the SoI level, the system architecture is developed, which serves to identify systems and system elements and establishes how they operate together to address the SoI requirements.

This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. At any level of this decomposition, one or more solution options may be presented as system architectures. The process by which the solution which best fits the system requirements, associated stakeholder needs and wider life cycle concerns is selected and justified is discussed in the System Analysis process.

Figure 2 below portrays the engineering that occurs in each system block. As necessary, system elements are defined through sets of system element requirements, which become inputs to other system blocks (level n+1). The approach is then recursively applied using the system definition processes.

Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012). Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.

At the n+1 level, the systems or system elements may also collect other stakeholder requirements that are directly pertinent to this level of architecture and design. Processes within each system are generic but unique in local purpose, scope and context.

See Applying Life Cycle Processes for a discussion of the iterative and recursive application of system requirements and architecture processes, and Life Cycle Processes and Enterprise Need for further detail on the transformation of needs and requirements to system and system element levels of abstraction.

The different aspects of how systems thinkingsystems thinking is applicable to system definition are discussed in SEBoK Part 2. In particular, see discussion of the recursive nature of systems and engineered system contexts in Engineered System Context; the contrast between top-down and bottom-up approaches in Synthesizing Possible Solutions and the role of solution architecture options and selection in Analysis and Selection between Alternative Solutions.

References

Works Cited

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

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

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.

Blanchard, B.S., and W.J. Fabrycky. 2005. Systems Engineering and Analysis. 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

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

ISO/IEC/IEEE. 2015. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/ Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 29148.

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Martin, J.N. 1997. Systems Engineering Guidebook: A Process for Developing Systems and Products, 1st ed. Boca Raton, FL, USA: CRC Press.

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

Additional References

Baldwin, C.Y. and K.B. Clark. 2000. Design Rules. Cambridge, MA, USA: MIT Press.

Buede, D.M. 2009. The Engineering Design of Systems: Models and Methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

Hatley, D.J., and I.A. Pirbhai. 1987. Strategies for Real-Time System Specification. New York, NY, USA: Dorset House Pub.

MOD. 2010. MOD Architecture Framework, Version 1.2.004. London, UK: UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.9, released 20 November 2023
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=System_Definition&oldid=69449"