Difference between revisions of "System Definition"
| Line 12: | Line 12: | ||
<meta name="citation_volume" content="version 1.0.1"> | <meta name="citation_volume" content="version 1.0.1"> | ||
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html> | <meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html> | ||
| − | [[System Definition (glossary)|System | + | [[System Definition (glossary)|System definition]] activities are conducted to describe in detail a system to satisfy an identified need. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Model (glossary)|life cycle model.]] These consist of the definition of [[System Requirement (glossary)|system requirements]], the definition of the [[Logical Architecture (glossary)| logical architecture]] and [[Physical Architecture (glossary) | physical architecture]], and [[System Analysis (glossary) | system analysis]]. 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 Definition (glossary)]], primarily the articulation of the [[Mission (glossary)]] of the [[System-of-Interest (glossary)|system-of-interest]] (SoI), the [[Stakeholder Requirement (glossary)|needs and requirements of stakeholders]], and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to [[System Realization (glossary)]]. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized. | + | System definition activities build on the artifacts and decisions from [[Concept Definition (glossary) | concept definition]], primarily the articulation of the [[Mission (glossary) | mission]] of the [[System-of-Interest (glossary)|system-of-interest]] (SoI), the [[Stakeholder Requirement (glossary)|needs and requirements of stakeholders]], and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to [[System Realization (glossary) |system realization]]. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized. |
==Topics== | ==Topics== | ||
| Line 25: | Line 25: | ||
==System Views and System Elements == | ==System Views and System Elements == | ||
| − | An [[Engineered System (glossary)]] solution to a defined concept includes a defined set of engineering elements, | + | An [[Engineered System (glossary)]] solution to a defined concept includes a defined set of engineering elements, characteristics, and properties. These elements are grouped in two ways: |
| − | *Needs and requirements views | + | * Needs and requirements views |
| − | *Architecture views | + | * Architecture views |
Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of [[System Element (glossary)|system elements]] and their relationships. | Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of [[System Element (glossary)|system elements]] and their relationships. | ||
| Line 33: | Line 33: | ||
===Requirements Views=== | ===Requirements Views=== | ||
| − | Requirements provide an overall view of the [[Purpose (glossary)|purpose]] and [[Mission (glossary)|mission]] which the system as a whole is intended to satisfy, | + | Requirements provide an overall view of the [[Purpose (glossary)|purpose]] and [[Mission (glossary)|mission]] which the system as a whole is intended to satisfy, as well as a technology-independent view of that the system solutions(s) should do. They are conventionally organized into two types: |
*[[Stakeholder Requirement (glossary)|Stakeholder requirements]] are defined and discussed in the [[Concept Definition]] KA. | *[[Stakeholder Requirement (glossary)|Stakeholder requirements]] are defined and discussed in the [[Concept Definition]] KA. | ||
| − | *[[System Requirement (glossary)|System requirements]] | + | *[[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 [[Verification (glossary)|verification]] 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 | + | 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 to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA. | + | 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 Views=== | ===Architecture Views=== | ||
There are several architectural representations or views/models of the system: | There are several architectural representations or views/models of the system: | ||
| − | *The '''[[Logical Architecture (glossary)|logical 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 [[Function (glossary)|functions]] and dynamic structures that describe how the mission is performed (behavior). | + | * The '''[[Logical Architecture (glossary)|logical 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 [[Function (glossary)|functions]] and dynamic structures that describe how the mission is performed (behavior). |
| − | *The '''[[Physical Architecture (glossary)|physical architecture]]''' is a set of [[System Element (glossary)|system elements]] performing functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles). | + | * The '''[[Physical Architecture (glossary)|physical architecture]]''' is a set of [[System Element (glossary)|system elements]] performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles). |
| − | The boundary of the system architectures 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 | + | The boundary of the system architectures 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 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. | + | 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. |
Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in [[What is a System?]] article. | Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in [[What is a System?]] article. | ||
| − | 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 is defined. The relationships between the outputs of concept definition and the system solution, | + | 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 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 Design|logical architecture]] and [[Physical Architecture Design|physical architecture]] sections of the KA. |
| − | ==Top- | + | ==Top-Down and Recursive Approach to System Decomposition== |
System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form 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 block''. | System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form 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 block''. | ||
| − | [[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] exist at all layers of the SBS. In ISO/IEC/IEEE (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 [[System Requirements|system requirements]] through levels of abstraction. Figure 1 | + | [[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] exist at all layers of the SBS. In ISO/IEC/IEEE (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 illlustrates 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.]] | [[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.]] | ||
As shown in Figure 1 | 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 architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements. | + | * 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. | + | * 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 | + | * 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. 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. | This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. 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. | ||
| Line 77: | Line 77: | ||
==System Architecture== | ==System Architecture== | ||
| − | Within the SE community, notions of architecture | + | Within the SE community, notions of architecture have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with [[Design (glossary) |design]] as part of a single system life cycle process called ''architectural design''. Although there are diverse viewpoints on architecture, the different perspectives have much in common. The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture. |
| − | The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' | + | The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' (i.e. relationships between elements). |
| − | Some authors limit the types of structure considered to be architectural; | + | Some authors limit the types of structure considered to be architectural; for example, restricting themselves to ''functional'' and ''physical'' structure. Recent practice has extended consideration to include ''temporal'' and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)). |
| − | ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting | + | ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009). |
| − | While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice | + | While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice that creates the potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group (Wilkinson et al.2010, Wilkinson 2010). |
==System Design== | ==System Design== | ||
| Line 91: | Line 91: | ||
In industrial practices, the term ''design'' is often used to mean both [[Architecture (glossary)]] and [[Design (glossary)]] as defined in the SEBoK. In the recent past, professionals used the term ''design'' when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of ''system'' in dealing with [[Complexity (glossary)]] (interconnections level, multi-techno, emergence, etc.). | In industrial practices, the term ''design'' is often used to mean both [[Architecture (glossary)]] and [[Design (glossary)]] as defined in the SEBoK. In the recent past, professionals used the term ''design'' when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of ''system'' in dealing with [[Complexity (glossary)]] (interconnections level, multi-techno, emergence, etc.). | ||
| − | It was | + | It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as previously described. Practitioners found the term ''structure'' inadequate to describe all of these aspects of a system. The terms ''architecture'' and ''architectural design'' have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system. |
| − | The trend today is to consider system architecture and system design as different sets of activities | + | The trend today is to consider system architecture and system design as different sets of activities. Attempts are made to define separate concurrent processes, but they are strongly intertwined: |
| − | *System design includes activities to conceive a system that answers a specific | + | * System design includes activities to conceive a system that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation. |
| − | *System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern and set of requirements for classes or families of similar or related systems. | + | * System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems. |
| − | + | System design is intended to be the link between the system architecture (at whatever point this milestone is defined in the specific application of the systems engineering process) and the implementation of technological system elements that compose the physical architecture of the system. | |
| − | These related processes are presented together in the present version of the SEBoK, | + | These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities. |
| − | ==General System Architecture and Design | + | ==General System Architecture and Design Principles and Concepts== |
===Classification of Principles and Heuristics=== | ===Classification of Principles and Heuristics=== | ||
| − | Engineers and architects use a mixture of mathematical principles and heuristics learned | + | Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows: |
| − | #'''Static domain''' relates to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces. | + | # '''Static domain''' relates to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces. |
| − | #'''Dynamic domain''' relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (performances, operational conditions) of the system. | + | # '''Dynamic domain''' relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system. |
| − | #'''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions. | + | # '''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions. |
| − | #'''Environmental domain''' relates to enablers (production, logistics support, etc.), but also to [[Survivability (glossary)|survivability]] of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]] of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects. | + | # '''Environmental domain''' relates to enablers (production, logistics support, etc.), but also to the [[Survivability (glossary)|survivability]] of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]] of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects. |
More detailed classification can be found in Maier and Rechtin (2009). | More detailed classification can be found in Maier and Rechtin (2009). | ||
| Line 119: | Line 119: | ||
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of [[Logical Architecture (glossary)]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]]. | The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of [[Logical Architecture (glossary)]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]]. | ||
| − | (System | + | (System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.) |
| − | Design decisions and technological solutions are selected according to performance criteria and non-functional requirements such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.) as illustrated in Figure 3. Creating intermediate models such as logical architecture models | + | Design decisions and technological solutions are selected according to performance criteria and non-functional requirements, such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system. |
[[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|600px|thumb|center|'''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] | [[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|600px|thumb|center|'''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] | ||
| − | ===Iterations between Logical and Physical Architecture | + | ===Iterations between Logical and Physical Architecture Definition=== |
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model. | Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model. | ||
| − | A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not | + | A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models. |
| − | Additional architecture and design iterations can produce | + | Additional architecture and design iterations can produce a through and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can lead to creation of new system requirements, called ''derived requirements''. |
===Concept of Interface=== | ===Concept of Interface=== | ||
| − | The concept of [[Interface (glossary)|interface]] is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function ''“send”'' located in one system element, the function ''“receive”'' located in the other one, and the function ''“carry"'' performed by the physical interface | + | The concept of [[Interface (glossary)|interface]] is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function ''“send”'' located in one system element, the function ''“receive”'' located in the other one, and the function ''“carry"'' as being performed by the physical interface that supports the input/output flow (see Figure 5). |
[[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|400px|thumb|center|'''Figure 4. Complete Interface Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] | [[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|400px|thumb|center|'''Figure 4. Complete Interface Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] | ||
| Line 141: | Line 141: | ||
In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data. | In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data. | ||
| − | === | + | ===Reuse of System Elements=== |
| − | Systems engineers frequently utilize existing system elements. This | + | Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1. |
<center> | <center> | ||
| Line 150: | Line 150: | ||
!Actions and Comments | !Actions and Comments | ||
|- | |- | ||
| − | |'''Case 1:''' The requirements of the system element are up-to-date and it will be re-used with no modification required | + | |'''Case 1:''' The requirements of the system element are up-to-date and it will be re-used with no modification required. |
| | | | ||
| − | *The system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element. | + | * The system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element. |
| − | *If the system element is not adapted, costs, complexity, and risks will increase. | + | * If the system element is not adapted, it is probable that costs, complexity, and risks will increase. |
|- | |- | ||
| − | |'''Case 2:''' The requirements of the system element are up-to-date and it will be re-used with possible modifications | + | |'''Case 2:''' The requirements of the system element are up-to-date and it will be re-used with possible modifications. |
| | | | ||
| − | *The system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element. | + | * The system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element. |
| − | *The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned. | + | * The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned. |
|- | |- | ||
| − | |'''Case 3:''' The requirements are not up-to-date or do not exist | + | |'''Case 3:''' The requirements are not up-to-date or do not exist. |
| | | | ||
| − | *It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior. | + | * It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior. |
| − | *This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient. | + | * This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient. |
| − | *Reverse engineering is expensive in terms of both time and money, and brings with it increased risk. | + | * Reverse engineering is expensive in terms of both time and money, and brings with it increased risk. |
|} | |} | ||
</center> | </center> | ||
| − | There is a common idea that | + | There is a common idea that reuse is ''free''; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity). |
==References== | ==References== | ||
Revision as of 22:36, 18 April 2013
<html> <meta name="citation_title" content="System Definition"> <meta name="citation_author" content="Pyster, Art"> <meta name="citation_author" content="Olwell, David H."> <meta name="citation_author" content="Hutchison, Nicole"> <meta name="citation_author" content="Enck, Stephanie"> <meta name="citation_author" content="Anthony, James F., Jr."> <meta name="citation_author" content="Henry, Devanandham"> <meta name="citation_author" content="Squires, Alice (eds)"> <meta name="citation_publication_date" content="2012/11/30"> <meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"> <meta name="citation_volume" content="version 1.0.1"> <meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html> System definition activities are conducted to describe in detail a system to satisfy an identified need. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected life cycle model. These consist of the definition of system requirements, the definition of the logical architecture and physical architecture, and system analysis. 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 definition, primarily the articulation of the mission of the system-of-interest (SoI), the needs and requirements of stakeholders, and preliminary operational concepts. 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
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 system solution to a defined concept includes a defined set of engineering elements, characteristics, and properties. These elements are grouped in two ways:
- Needs and requirements views
- Architecture views
Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of system elements and their relationships.
Requirements Views
Requirements provide an overall view of the purpose and mission which the system as a whole is intended to satisfy, as well as a technology-independent view of that the system solutions(s) should do. They are conventionally organized into two types:
- Stakeholder requirements are defined and discussed in the Concept Definition KA.
- 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 verification 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 Views
There are several architectural representations or views/models of the system:
- The logical 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 functions and dynamic structures that describe how the mission is performed (behavior).
- The physical architecture is a set of system elements performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles).
The boundary of the system architectures 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.
Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in What is a System? article.
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 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 and physical architecture sections of the KA.
Top-Down and Recursive Approach to System Decomposition
System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form 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 block.
Stakeholder requirements and system requirements exist at all layers of the SBS. In ISO/IEC/IEEE (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 illlustrates this approach.
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. 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.
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.
System Architecture
Within the SE community, notions of architecture have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with design as part of a single system life cycle process called architectural design. Although there are diverse viewpoints on architecture, the different perspectives have much in common. The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture.
The majority of interpretations of system architecture are based on the fairly intangible notion of structure (i.e. relationships between elements).
Some authors limit the types of structure considered to be architectural; for example, restricting themselves to functional and physical structure. Recent practice has extended consideration to include temporal and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).
ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009).
While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice that creates the potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group (Wilkinson et al.2010, Wilkinson 2010).
System Design
In industrial practices, the term design is often used to mean both architecture and design as defined in the SEBoK. In the recent past, professionals used the term design when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of system in dealing with complexity (interconnections level, multi-techno, emergence, etc.).
It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as previously described. Practitioners found the term structure inadequate to describe all of these aspects of a system. The terms architecture and architectural design have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system.
The trend today is to consider system architecture and system design as different sets of activities. Attempts are made to define separate concurrent processes, but they are strongly intertwined:
- System design includes activities to conceive a system that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation.
- System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems.
System design is intended to be the link between the system architecture (at whatever point this milestone is defined in the specific application of the systems engineering process) and the implementation of technological system elements that compose the physical architecture of the system.
These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.
General System Architecture and Design Principles and Concepts
Classification of Principles and Heuristics
Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows:
- Static domain relates to physical structure or organization of the SoI broken down into systems and system elements. It deals with partitioning systems, system elements, and physical interfaces.
- Dynamic domain relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system.
- Temporal domain relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions.
- Environmental domain relates to enablers (production, logistics support, etc.), but also to the survivability of the system in reaction to natural hazards or threats and to the integrity of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects.
More detailed classification can be found in Maier and Rechtin (2009).
Transition from System Requirements to Physical Architecture
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of logical architecture , then to allocate the elements of the logical architecture to system elements of candidate physical architectures.
(System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.)
Design decisions and technological solutions are selected according to performance criteria and non-functional requirements, such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system.
Iterations between Logical and Physical Architecture Definition
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.
A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models.
Additional architecture and design iterations can produce a through and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can lead to creation of new system requirements, called derived requirements.
Concept of Interface
The concept of interface is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function “send” located in one system element, the function “receive” located in the other one, and the function “carry" as being performed by the physical interface that supports the input/output flow (see Figure 5).
In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data.
Reuse of System Elements
Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1.
| Re-use Case | Actions and Comments |
|---|---|
| Case 1: The requirements of the system element are up-to-date and it will be re-used with no modification required. |
|
| Case 2: The requirements of the system element are up-to-date and it will be re-used with possible modifications. |
|
| Case 3: The requirements are not up-to-date or do not exist. |
|
There is a common idea that reuse is free; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity).
References
Works Cited
ANSI/IEEE. 2000. Recommended Practice for Architectural Description for Software-Intensive Systems. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.
ANSI/EIA. 1998. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998.
DOD. 2010. “DOD Architecture Framework.” Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.
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 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008 (E).
ISO/IEC/IEEE. 2011. Systems and software engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), 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.
Maier, M., and E. Rechtin. 2009. The Art of Systems Architecting. 3rd ed. Boca Raton, FL, USA: CRC Press.
MOD. 2010. “MOD Architecture Framework”. Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.
Stevens, R. P. Brook, K. Jackson, S. Arnold. 1998. Systems Engineering - Coping with Complexity. Englewood Cliffs, NJ, USA: Prentice-Hall.
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. “Belief Systems in Systems Architecting: Method and Preliminary Applications," paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.
Wilkinson, M. K. 2010. “Z8: Systems Architecture”, in Z-guide series. INCOSE UK, available from INCOSE UK at: http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications
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. 2011. INCOSE 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. 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. 2008. 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. ISO/IEC/IEEE 15288:2008 (E).
ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), 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.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
Additional References
Baldwin, Carliss Y., and Kim B. Clark. 2000. Design Rules. Cambridge, Mass: MIT Press.
Buede, D.M. 2009. The Engineering Design of Systems: Models and Methods. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.
DoD. 2010. DOD Architecture Framework. Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.
Hatley, Derek J., and Imtiaz A. Pirbhai. 1987. Strategies for Real-Time System Specification. New York, NY: Dorset House Pub.
MOD. 2010. MOD Architecture Framework. Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.
Stevens, R. P. Brook, K. Jackson, S. Arnold. 1998. Systems Engineering - Coping with Complexity. Englewood Cliffs, NJ, USA: Prentice-Hall.
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. Belief Systems in Systems Architecting: Method and Preliminary Applications. paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus