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")
 
(203 intermediate revisions by 12 users not shown)
Line 1: Line 1:
−
After the determination of the need for a new or modified system, System Definition activities are conducted to describe the system in detail. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected [[Life Cycle (glossary)|development cycle model]]. These consist of the definition of [[System Requirements|system requirements]], the definition of the [[Architectural Design: Logical|logical]] and [[Architectural Design: Physical|physical]] system architecture, and [[System Analysis|system analysis]]. During and/or at the end of each iteration, gap analysis is performed to insure that all System Requirements have been mapped to the Architecture and Design.
+
----
 +
'''''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.
  
−
System definition activities build on the artifacts and decisions from [[Concept Definition]], primarily the articulation of the [[Mission Analysis|mission]] of the [[System of Interest (SoI) (glossary)|system of interest]], the [[Stakeholder Needs and Requirements|needs and requirements of stakeholders]], and preliminary operational concepts.  The products of system definition activities ([[System Requirements|system requirements]], [[Architecture (glossary)|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 Models|life cycle model]] being utilized.
+
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.
  
−
To download a PDF of all of Part 3 (including this knowledge area), please [http://www.sebokwiki.org/075/images/0/07/SEBoK075_Part3.pdf click here].
+
The products of system definition activities (system requirements, architecture and design) are inputs to {{Term|System Realization (glossary)|system 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 {{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==
 
==Topics==
−
The topics contained within this knowledge area include:
+
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 Requirements]]
−
*[[Architectural Design: Logical]]
+
* [[System Architecture]]
−
*[[Architectural Design: Physical]]
+
*[[Logical Architecture Model Development]]
 +
*[[Physical Architecture Model Development]]
 +
* [[System Design]]
 
*[[System Analysis]]
 
*[[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 ==
 
==System Views and System Elements ==
−
To engineer a system, a set of engineering elements, characteristics, and  properties have to be defined. These elements can be grouped in several views as follows.
+
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
−
'''Needs and Requirements view''' - Following characteristics provide a global understanding of the system in its context of use and seen as a black box.
+
* Architecture and design views
−
 
 
−
*The [[Purpose (glossary)|Purpose]] states the relevance of the system within the [[Context (glossary)]] of use.
 
−
*The [[Mission (glossary)|Mission]] expresses the set of services the system provides, the main and global transformation it performs, and how it fulfills a capability or need for the enterprise.
 
−
*The '''objectives''' are elements that quantify the mission, as a set of measurable data related to space, time and effectiveness.
 
−
*The expression of the mission is generally an abstraction of a set of actions performed by the system within its context of use and under '''operational conditions'''.  This set of actions is called [[Operational Scenario (glossary)]]  and describes how these actions are related to each other and what they exchange with the elements of the context.
 
−
 
 
−
All these elements are refined iteratively until a comprehensive view of the system within its context is obtained. They are used to elicit needs, to define [[Stakeholder Requirement (glossary)|Stakeholder Requirements]], and then [[System Requirement (glossary)|System Requirements]].
 
−
 
 
−
 
 
−
'''Architecture view''' - There are several architectural representations or views/models of the system; major and basic ones follows.
 
−
*'''The [[Logical Architecture (glossary)|Logical Architecture]]''' supports the logical operation of the system all along its life cycle, and includes as a minimum Functional, Behavioral and Temporal views/models. Operational Scenarios refine the mission into a collection of [[Function (glossary)|Functions]] and dynamic structures that describe how 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 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.
 
−
 
 
−
 
 
−
'''Boundary and interface view''' - Boundary of the system depends on what engineers include within the scope of the system and outside of it. This view encompasses:
 
−
*[[Input-Output Flow (glossary)|Input-Output Flows]] exchanged between the system and elements of its context of use (functional interface),
 
−
*[[Physical Interface (glossary)|Physical Interfaces]] (physical connections) that support these exchanges.
 
−
 
 
−
Interactions are modelled and defined using Operational Scenarios.
 
−
 
 
−
 
 
−
'''System breakdown view''' – Facing the potential number of System Elements that constitute the Physical Architecture, sets of System Elements can be grouped to form systems. So, the decomposition of the [[System of Interest (SoI) (glossary)]] (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.
 
−
 
 
−
Because a System Element is primarily a 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.
 
−
 
 
−
Other views of a system are possible to describe a more complete set of characteristics – refer to Architectural Frameworks (DoDAF, MODAF, NAF, TOGAF, etc.).
 
−
 
 
−
==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 purpose, 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. 2011), these layers are known as levels of abstraction. As well as systematically introducing layers of systems, the Architecture and Design process manages transformation of [[System Requirements]] through levels of abstraction. 
 
−
 
 
−
Figure 1  portrays this approach.
 
−
 
 
−
*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 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 that serves to identify systems and System Elements, and how they operate together to address the SoI requirements.
 
−
 
 
−
[[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) Reprinted with permission of © Alain Faisandier]]
 
−
 
 
  
−
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.
+
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.
−
As necessary, System Elements are defined through sets of System Element Requirements. These lower-level requirements act as Stakeholder Requirements as they become inputs to other system blocks (level n+1).
 
  
−
The approach is then recursively applied using the system definition processes.
+
===Needs and Requirements Views===
  
−
At level n + 1, 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.
+
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:
  
−
[[File:Recursive_Instantiation_of_Def_Process_AF_071112.png|thumb|center|700px|center|Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012) Reprinted with permission of © Alain Faisandier]]
+
*Business or mission requirements and {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}} are defined and discussed in the [[Concept Definition]] KA.
  
−
==Different understandings of “requirements”==
+
*{{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.
  
−
To avoid confusion in the multitude of terms around ''[[Requirement (glossary)]]'' consider the following classifications:
+
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.
−
* '''Process role or state''': The role the requirement plays in the Definition process; for instance, its position in the system block: translated, derived, satisfied; or its state of agreement:  Proposed, Approved, Cancelled.
 
−
* '''Level of abstraction''': The level within the Definition process for the requirement stands; for instance, Stakeholder Requirement, System Requirement, System Element Requirement.
 
−
* '''Type of requirement''': The nature of the requirement itself; for instance Functional, Performance, Constraint, etc.
 
  
−
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type.
+
The process activities that are used to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA.
  
−
For additional explanations about differences between stakeholder, user, and customer, and between kinds of requirements, refer to (Martin, J. N. 1997) chapter 2.
+
===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.  
  
−
==System Architecture==
+
{{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.
−
Within the Systems Engineering community, notions of architecture seem to have been heavily influenced by ISO/IEC 15288, 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. We consider systems engineering to cover all aspects of the creation of a system, including system architecture.
+
* 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).
  
−
===Definitions===
+
* 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).
  
−
See the entry [[Architecture (glossary)]].   
+
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.
  
−
===Some Common Concepts===
+
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.  
−
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, say 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 (e.g DODAF, MODAF) – refer to (DODAF, 2010) and (MODAF, 2010).
+
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.
  
−
ISO/IEC/IEEE 42010 provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting in the life cycle. A discussion of the features of Systems Architectures can be found in (Maier, M., and E. Rechtin. 2009).
+
==System Synthesis and Decomposition==
  
−
While architectural concepts are very useful and widely used in Systems Engineering, there is a lack of consistency across communities of practice with 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 – refer to (Wilkinson et al. 2010) and (Wilkinson 2010).
+
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''.
  
−
==System design==
+
{{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.
  
−
In industrial practices the two notions of Architecture and Design are often merged and called simply “Design”. In the recent past, it is clear that professionals used the term Design when they deal with technological products that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In new multi-technologies products and services, professionals early recognized the usefulness of the notion of system facing the complexity (interconnections level, multi-techno, emergence, etc.). It is at this point that the necessity of structuring what composes a system appeared because of hundreds of functions, interfaces, System Elements, etc. This explains the functional, behavioral, temporal, physical, and other structures as presented before.
+
[[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.]]
  
−
But the term “structure” did not seem appropriate, so the terms "architecture" and "architectural design" have been selected from approximately the 1980 years, in particular in software intensive systems, and in some domains such as Space industry. The set of different types and interrelated "structures" can be understood as THE architecture of the system.
+
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.  
  
−
The trend today is to consider different sets of activities for System Architecture and for System Design, but considering they are strongly intertwined. Attempts are made to define separate concurrent processes. The following two complementary new definitions answer well this issue and trend:
+
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.
  
−
#System Design includes activities to conceive a system that answers an 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 traded-off System Requirements.
+
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.
−
#System Design is the complete set of detailed models, properties or characteristics described into a form suitable for implementation.
 
  
−
System Architecture is more abstract, conceptualization oriented, global, focused to achieve the mission, and focused on high level structure in (sub) systems. While System Design is more technology oriented through physical, structural, environmental, operational properties forcing decisions for implementation.  
+
[[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.]]
  
−
So we can say that the purpose of System Design is to make the link between the System Architecture and the implementation of technological System Elements that compose the Physical Architecture of the system.  
+
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.
  
−
In the present version of this guide to the SEBoK, we still present the related processes together, but we try to make distinction between the corresponding activities.
+
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.
−
 
 
−
==General System Architecture and Design principles and concepts==
 
−
 
 
−
===Classification of principles and heuristics===
 
−
 
 
−
Engineers and architects often use mathematical principles, and also heuristics learned from experience. When an issue is identified through System Requirements, principles and heuristics may be able to address the issue or not. Principles and heuristics that are used in system views/models can be classified in following domains.
 
−
 
 
−
# '''Static domain''' relates to physical structure or organization of the System of Interest 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 deals also with effectiveness (performances, operational conditions) of the system.
 
−
# '''Temporal domain''' concerns 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 also 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)]] of the system in reaction to natural hazards or threats, and to [[Integrity (glossary)]] 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 much as possible independent of technology) 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]]. 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.) – see Figure 3. Creating intermediate models such as Logical Architecture models enables in particular facilitating the validation of functional, behavioral, temporal properties of the system against System Requirements which have no major technological influence, and changing 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 models during Architecture and Design (Faisandier 2012) Reprinted with permission of © Alain Faisandier]]
 
−
 
 
−
===Iterations between Logical and Physical Architecture definition===
 
−
 
 
−
Architecture and Design activities require spending several iterations from Logical Architecture models definition to Physical Architecture models definition 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 then enables to determine main System Elements that could perform system Functions and to organize them into a Physical Architecture model.
 
−
 
 
−
A second Logical Architecture definition loop allows taking into account allocations of functions to System Elements and derived functions coming from physical solution choices, as well as supplementing the initial Logical Architecture model by introducing other scenarios, failure analyses, and every operational requirement not taken before. Derived Functions must, in their turn, be allocated to System Elements, and this, in turn, affects the Physical Architecture models.
 
−
 
 
−
Other Architecture and Design loops must be considered to produce an exhaustive and consistent Logical and Physical solution. During System Design, technological choices lead potentially to new functions, new input/output and control flows, and new physical interfaces. These new elements can conduct 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, inputs/outputs of functions are also carried by physical elements, 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 which 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) Reprinted with permission of © Alain Faisandier]]
 
−
 
 
−
In the context of complex exchanges between system elements (IT systems), a protocol is seen as a physical interface that carries exchanges of data.
 
−
 
 
−
==Re-use of System Elements==
 
−
Systems frequently incorporate existing system elements. This re-use constraint has to be identified as a system requirement and carefully taken into account during design. One can distinguish three general cases when re-using system elements. Table 1.
 
−
 
 
−
<center>'''Table 1. System Element re-use cases (Faisandier 2011)Reprinted with permission of © Alain Faisandier.'''</center>
 
−
[[File:SEBoKv05_KA-SystDef_System_Element_Reuse.png|thumb|center|600px|center]]
 
−
 
 
−
Re-use may introduce risks that can be significant for the project (costs, deadlines, complexity). Disappointment can be severe because of the widespread false idea that re-use is free.
 
  
 +
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==  
Line 164: Line 81:
 
===Works Cited===
 
===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.
−
 
 
−
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. 2011 (unpublished). ''Engineering and Architecting Multidisciplinary Systems.''
+
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/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 - 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.
−
 
 
−
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 - 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.
 
−
 
 
−
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st 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===
 
===Primary References===
Line 196: Line 93:
 
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.  
 
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.  
+
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.
+
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 Electronical Commission (IEC), [[ISO/IEC 26702]]:2007.
+
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/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (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/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].
+
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/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]].
 
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.
+
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A Process for Developing Systems and Products,'' 1st ed. Boca Raton, FL, USA: CRC Press.
  
−
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
+
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C., USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.
  
 
===Additional References===
 
===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.  
 
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.
−
 
 
−
Faisandier, A. 2011 (unpublished). ''Engineering and Architecting Multidisciplinary Systems''.
 
−
 
 
−
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.
+
Hatley, D.J., and I.A. Pirbhai. 1987. ''Strategies for Real-Time System Specification''. New York, NY, USA: Dorset House Pub.
  
−
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.
+
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/.
  
 
----
 
----
 
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center>
 
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center>
  
−
{{5comments}}
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
  
−
[[Category: Part 3]][[Category:Knowledge Area]]
+
[[Category:Part 3]][[Category:Knowledge Area]][[Category:System Definition]]
−
{{DISQUS}}
 

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"