Difference between revisions of "Systems Engineering and Quality Attributes"

From SEBoK
Jump to navigation Jump to search
(33 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
----
 
----
'''''Lead Author:''''' ''Dave Olwell'', '''''Contributing Authors:''''' ''Richard Turner, Dick Fairley, Scott Jackson, Alice Squires''
+
'''''Lead Authors:''''' ''Dave Olwell,'' ''Art Pyster''''''Contributing Authors:''''' ''Richard Turner, Dick Fairley, Scott Jackson, Alice Squires''
 
----
 
----
Every system has a set of properties that are largely a function of the system as a whole rather than just its constituent parts; e.g., security, reliability, cost, and resilience. This KA describes the engineering disciplines that enable the realization of those properties. Collectively, these disciplines are referred to as {{Term|Specialty Engineering (glossary)|Specialty engineering}}.  
+
Every system has a set of properties that are largely a function of the system as a whole rather than just its constituent parts. There are dozens of these properties such as security, reliability, safety, resistance to electromagnetic interference, usability, and resilience. This Knowledge Area (KA) describes many of the most important such properties and how they are realized. The vocabulary to talk about these properties is not standard. Alternatively, they are called ''quality attributes,'' ''non-functional requirements, -ilities,'' and  ''specialties.'' In this KA, the term {{Term|Specialty Engineering (glossary)|specialty engineering}} refers to the collective engineering of all quality attributes of a system.  
  
Some consider specialty engineering to be a sub-discipline of SE itself; e.g. they consider security engineering, safety engineering, resilience engineering, etc. to be part of SE. Others consider them to be stand-alone disciplines in their own right. Either way, their mastery is important to a system engineer. Moreover, they are usually interdependent; e.g. increasing system reliability often requires using more expensive parts and adding redundant components. Hence, higher reliability often means higher cost to deliver a system – another system property. However, higher reliability might mean lower maintenance cost – another system property. A systems engineer typically makes many decisions and takes many actions with regard to system properties; e.g., specifying which properties are important for a particular system, stating how those properties will be measured, trading off conflicting properties, and verifying that a system has the specified properties.
+
Quality attributes are often interdependent rather than orthogonal; e.g. making a system more secure may make it harder to use but also safer. Increasing system reliability often requires using more expensive parts and adding redundant components. Hence, higher reliability often means higher cost to deliver a system – another system property. However, higher reliability might mean lower maintenance cost – another system property. A systems engineer typically makes many decisions and takes many actions with regard to system properties; e.g. specifying which properties are important for a particular system, stating how those properties will be measured, trading off conflicting properties, and verifying that a system has the specified properties. Barry Boehm (2016), as the lead for a project of the [https://sercuarc.org Systems Engineering Research Center], introduced an ontology to describe system quality attributes as a way of enabling smarter tradeoffs between them and understanding the impact of those trades on cost. Also, see the article on [[Quality Management]] for more information on how these decisions and actions are managed.   
This Knowledge Area includes topical articles on several specialty engineering disciplines such as Reliability, Availability, and Maintainability. .
+
 
 +
Many consider specialty engineering to be a sub-discipline of SE itself; e.g. they consider security engineering, safety engineering, resilience engineering, etc. to be part of SE. Others consider them to be stand-alone disciplines in their own right with close ties to SE. Either way, their mastery is important to a system engineer. This KA includes topical articles on several specialty engineering disciplines. Some articles will treat the topic of the article as a sub-discipline of SE itself; others will treat it as a closely related but separate discipline. This disparity reflects both the diversity of opinions on this matter and the fact that SEBoK articles are written by a wide array of authors.  
  
 
==Topics==
 
==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:  
+
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 articles on the following topics, shown in alphabetical order:  
*[[System Availability]]
 
 
*[[Human Systems Integration]]
 
*[[Human Systems Integration]]
*[[Security Engineering]]
+
*[[Manufacturability and Producibility]]
*[[Electromagnetic Interference/Electromagnetic Compatibility]]
+
*[[System Affordability]]
 +
*[[System Hardware Assurance]]
 +
*[[System Reliability, Availability, and Maintainability]]
 
*[[System Resilience]]
 
*[[System Resilience]]
*[[Manufacturability and Producibility]]
+
*[[System Resistance to Electromagnetic Interference]]
*[[Affordability]]
+
*[[System Safety]]
*[[Environmental Engineering]]
+
*[[System Security]]
 +
Over time, this KA will expand to add topical articles about other quality attributes.
  
 
==Specialty Requirements==
 
==Specialty Requirements==
The systems engineering team must ensure that specialty requirements are properly reviewed with regard to their impact on life cycle costs, development schedule, technical performance, and operational utility.  For example, security requirements can impact operator workstations, electromagnetic interference requirements can impact the signal in the interfaces between subsystems, and mass-volume requirements may preclude the use of certain materials to reduce subsystem weight.   
+
The systems engineering team must ensure that requirements about quality attributes (also called specialty requirements) are properly reviewed with regard to their impact on life cycle costs, development schedule, technical performance, and operational utility.  For example, security requirements can impact operator workstations, electromagnetic interference requirements can impact the signal in the interfaces between subsystems, and mass-volume requirements may preclude the use of certain materials to reduce subsystem weight.   
  
Engineering specialists audit the evolving design and resulting configuration items to ensure that the overall system performance also satisfies the specialty requirements.  Including appropriate specialty engineers within each systems engineering team assures that all system requirements are identified and balanced throughout the development cycle.
+
Engineering specialists audit the evolving design and resulting configuration items to ensure that the overall system performance also satisfies the specialty requirements.  Including appropriate specialty engineers within each systems engineering team ensures that all specialty requirements are identified and balanced throughout the development cycle.
  
 
== Integration of Specialty Engineering ==
 
== Integration of Specialty Engineering ==
Integration of engineering specialties into a project or program is, or should be, a major objective of systems engineering management. (Endler 2016) With properly implemented procedures, the rigor of the systems engineering process ensures participation of the specialty disciplines at key points in the technical decision-making process. Special emphasis on integration is mandatory because a given design could in fact be accomplished without consideration of these specialty disciplines, leading to the possibility of system ineffectiveness or failure when an unexamined situation occurs in the operational environment.
+
Integration of specialty engineering into a project or program is, or should be, a major objective of systems engineering management. (Endler 2016, Kossiakoff et al. 2020) With properly implemented procedures, the rigor of the systems engineering process ensures participation of the specialty disciplines at key points in the technical decision-making process. Special emphasis on integration is mandatory because a given design could in fact be accomplished without consideration of these specialty disciplines, leading to the possibility of system ineffectiveness or failure when an unexamined situation occurs in the operational environment.
  
For example, human factors considerations can contribute to reduced workloads and therefore lower error rates by operators in aircraft cockpits, at air-traffic consoles, or nuclear reactor stations.  Similarly, mean-time-to-repair features can significantly increase overall system availability in challenging physical environments, such as mid-ocean or outer space.  {{Term|Specialty Engineering (glossary)|Specialty engineering}} requirements are often manifest as constraints on the overall system design space. The role of system engineering is to balance these constraints with other functionality in order to harmonize total system performance. The end goal is to produce a system that provides utility and effectiveness to the customer at an affordable price.
+
For example, human factors considerations can contribute to reduced workloads and therefore lower error rates by operators in aircraft cockpits, at air-traffic consoles, or in nuclear reactor stations.  Similarly, mean-time-to-repair features can significantly increase overall system availability in challenging physical environments, such as mid-ocean or outer space or in safety critical environments such as hospital intensive care units or in traffic control systems in city centers.  Specialty engineering requirements are often manifest as constraints on the overall system design space. The role of systems engineering is to balance these constraints with other functionality in order to harmonize total system performance. The end goal is to produce a system that provides utility and effectiveness to the customer at an affordable price.
  
 
As depicted in Figure 1, systems engineering plays a leadership role in integrating traditional disciplines, specialty disciplines, and unique system product demands to define the system design. Relationships for this integration process are represented as interactions among three filters.  
 
As depicted in Figure 1, systems engineering plays a leadership role in integrating traditional disciplines, specialty disciplines, and unique system product demands to define the system design. Relationships for this integration process are represented as interactions among three filters.  
Line 36: Line 39:
 
==References==  
 
==References==  
 
===Works Cited===
 
===Works Cited===
D. Endler. 2016. ''"Integration of Specialty Engineering Activities".'' Proceedings of the 26th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 18-21, 2016, Edinburgh, Scotland, UK.
+
Boehm, B. 2016. ''System Qualities Ontology, Tradespace, and Affordability (SQOTA) Project - Phase 4.'' Systems Engineering Research Center: Stevens Institute of Technology. February 2016. SERC-2016-TR-101.Accessed on March 3, 2021. Available at https://www.archive.sercuarc.org/wp-content/uploads/2014/05/SERC-2016-TR-101-Phase-4_RT-137.pdf.
 +
 
 +
Endler, D. 2016. ''"Integration of Specialty Engineering Activities."'' Proceedings of the 26th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 18-21, 2016, Edinburgh, Scotland, UK.
 +
 
 +
Kossiakoff, A., W.N. Sweet, S.J. Seymour, and S.M. Biemerl. 2020. ''Systems Engineering Principles and Practice'', Third Edition. John Wiley & Sons, Inc: Hoboken, NJ, USA.  
  
USAF. 2000. ''[[Guidelines for Successful Acquisition and Management of Software-Intensive Systems]]: Weapon Systems Command and Control Systems Management Information Systems'', version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on September 11, 2011. Available at http://www.stsc.hill.af.mil/resources/tech%5Fdocs/.
+
USAF. 2000. ''[[Guidelines for Successful Acquisition and Management of Software-Intensive Systems]]: Weapon Systems Command and Control Systems Management Information Systems'', version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on March 3, 2021. Available at https://onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.1999.tb00315.x.
  
 
===Primary References===
 
===Primary References===
USAF. 2000. ''[[Guidelines for Successful Acquisition and Management of Software-Intensive Systems]]: Weapon Systems Command and Control Systems Management Information Systems'', version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on September 11, 2011. Available at http://www.stsc.hill.af.mil/resources/tech%5Fdocs/.
+
USAF. 2000. ''[[Guidelines for Successful Acquisition and Management of Software-Intensive Systems]]: Weapon Systems Command and Control Systems Management Information Systems'', version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on March 3, 2021. Available at https://onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.1999.tb00315.x.
  
 
===Additional References===
 
===Additional References===
Line 47: Line 54:
  
 
----
 
----
<center>[[Systems Engineering and Geospatial/Geodetic Engineering|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[System Availability|Next Article >]]</center>
+
<center>[[Software Engineering Features - Models, Methods, Tools, Standards, and Metrics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Human Systems Integration|Next Article >]]</center>
  
<center>'''SEBoK v. 2.3, released 30 October 2020'''</center>
+
<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>
  
 
[[Category: Part 6]]
 
[[Category: Part 6]]
 
[[Category:Knowledge Area]]
 
[[Category:Knowledge Area]]
 
[[Category:Systems Engineering and Quality Attributes]]
 
[[Category:Systems Engineering and Quality Attributes]]

Revision as of 20:50, 19 May 2021


Lead Authors: Dave Olwell, Art Pyster Contributing Authors: Richard Turner, Dick Fairley, Scott Jackson, Alice Squires


Every system has a set of properties that are largely a function of the system as a whole rather than just its constituent parts. There are dozens of these properties such as security, reliability, safety, resistance to electromagnetic interference, usability, and resilience. This Knowledge Area (KA) describes many of the most important such properties and how they are realized. The vocabulary to talk about these properties is not standard. Alternatively, they are called quality attributes, non-functional requirements, -ilities, and specialties. In this KA, the term specialty engineeringspecialty engineering refers to the collective engineering of all quality attributes of a system.

Quality attributes are often interdependent rather than orthogonal; e.g. making a system more secure may make it harder to use but also safer. Increasing system reliability often requires using more expensive parts and adding redundant components. Hence, higher reliability often means higher cost to deliver a system – another system property. However, higher reliability might mean lower maintenance cost – another system property. A systems engineer typically makes many decisions and takes many actions with regard to system properties; e.g. specifying which properties are important for a particular system, stating how those properties will be measured, trading off conflicting properties, and verifying that a system has the specified properties. Barry Boehm (2016), as the lead for a project of the Systems Engineering Research Center, introduced an ontology to describe system quality attributes as a way of enabling smarter tradeoffs between them and understanding the impact of those trades on cost. Also, see the article on Quality Management for more information on how these decisions and actions are managed.

Many consider specialty engineering to be a sub-discipline of SE itself; e.g. they consider security engineering, safety engineering, resilience engineering, etc. to be part of SE. Others consider them to be stand-alone disciplines in their own right with close ties to SE. Either way, their mastery is important to a system engineer. This KA includes topical articles on several specialty engineering disciplines. Some articles will treat the topic of the article as a sub-discipline of SE itself; others will treat it as a closely related but separate discipline. This disparity reflects both the diversity of opinions on this matter and the fact that SEBoK articles are written by a wide array of authors.

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 articles on the following topics, shown in alphabetical order:

Over time, this KA will expand to add topical articles about other quality attributes.

Specialty Requirements

The systems engineering team must ensure that requirements about quality attributes (also called specialty requirements) are properly reviewed with regard to their impact on life cycle costs, development schedule, technical performance, and operational utility. For example, security requirements can impact operator workstations, electromagnetic interference requirements can impact the signal in the interfaces between subsystems, and mass-volume requirements may preclude the use of certain materials to reduce subsystem weight.

Engineering specialists audit the evolving design and resulting configuration items to ensure that the overall system performance also satisfies the specialty requirements. Including appropriate specialty engineers within each systems engineering team ensures that all specialty requirements are identified and balanced throughout the development cycle.

Integration of Specialty Engineering

Integration of specialty engineering into a project or program is, or should be, a major objective of systems engineering management. (Endler 2016, Kossiakoff et al. 2020) With properly implemented procedures, the rigor of the systems engineering process ensures participation of the specialty disciplines at key points in the technical decision-making process. Special emphasis on integration is mandatory because a given design could in fact be accomplished without consideration of these specialty disciplines, leading to the possibility of system ineffectiveness or failure when an unexamined situation occurs in the operational environment.

For example, human factors considerations can contribute to reduced workloads and therefore lower error rates by operators in aircraft cockpits, at air-traffic consoles, or in nuclear reactor stations. Similarly, mean-time-to-repair features can significantly increase overall system availability in challenging physical environments, such as mid-ocean or outer space or in safety critical environments such as hospital intensive care units or in traffic control systems in city centers. Specialty engineering requirements are often manifest as constraints on the overall system design space. The role of systems engineering is to balance these constraints with other functionality in order to harmonize total system performance. The end goal is to produce a system that provides utility and effectiveness to the customer at an affordable price.

As depicted in Figure 1, systems engineering plays a leadership role in integrating traditional disciplines, specialty disciplines, and unique system product demands to define the system design. Relationships for this integration process are represented as interactions among three filters.

The first filter is a conceptual analysis that leverages traditional design consideration (structural, electronics, aerodynamics, mechanical, thermodynamics, etc.). The second filter evaluates the conceptual approach using specialty disciplines, such as safety, affordability, quality assurance, human factors, reliability and maintainability, producibility, packaging, test, logistics, and others, to further requirements development. Design alternatives that pass through these two processes go through a third filter that incorporates facility design, equipment design, procedural data, computer programs, and personnel to develop the final requirements for design selection and further detailed development.

Figure 1. Integration Process for Specialty Engineering (USAF 2000). Released by the U.S. Air Force.

References

Works Cited

Boehm, B. 2016. System Qualities Ontology, Tradespace, and Affordability (SQOTA) Project - Phase 4. Systems Engineering Research Center: Stevens Institute of Technology. February 2016. SERC-2016-TR-101.Accessed on March 3, 2021. Available at https://www.archive.sercuarc.org/wp-content/uploads/2014/05/SERC-2016-TR-101-Phase-4_RT-137.pdf.

Endler, D. 2016. "Integration of Specialty Engineering Activities." Proceedings of the 26th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 18-21, 2016, Edinburgh, Scotland, UK.

Kossiakoff, A., W.N. Sweet, S.J. Seymour, and S.M. Biemerl. 2020. Systems Engineering Principles and Practice, Third Edition. John Wiley & Sons, Inc: Hoboken, NJ, USA.

USAF. 2000. Guidelines for Successful Acquisition and Management of Software-Intensive Systems: Weapon Systems Command and Control Systems Management Information Systems, version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on March 3, 2021. Available at https://onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.1999.tb00315.x.

Primary References

USAF. 2000. Guidelines for Successful Acquisition and Management of Software-Intensive Systems: Weapon Systems Command and Control Systems Management Information Systems, version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on March 3, 2021. Available at https://onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.1999.tb00315.x.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.4, released 19 May 2021