Difference between revisions of "Product as a System Fundamentals"
| Line 1: | Line 1: | ||
| − | |||
== Product Elements and Connections == | == Product Elements and Connections == | ||
| Line 5: | Line 4: | ||
The connections in a product system are not merely the interfaces. The connections between elements contain interactions and relationships (Hybertson 2009). Interactions occur across “interfaces” between the elements inside or outside the system, i.e., they can be either internal or external to the system. These interactions can be in the form of data, materials, forces, or energy. Product SE usually captures the definition of these interactions in an interface control document, interface design document, interface requirements document, or some other equivalent form. Interaction-like connections can be represented in various engineering artifacts: schematic block diagram, data flow diagram, free body diagram, interface control diagram, port specification, energy transfer diagram, and so on. | The connections in a product system are not merely the interfaces. The connections between elements contain interactions and relationships (Hybertson 2009). Interactions occur across “interfaces” between the elements inside or outside the system, i.e., they can be either internal or external to the system. These interactions can be in the form of data, materials, forces, or energy. Product SE usually captures the definition of these interactions in an interface control document, interface design document, interface requirements document, or some other equivalent form. Interaction-like connections can be represented in various engineering artifacts: schematic block diagram, data flow diagram, free body diagram, interface control diagram, port specification, energy transfer diagram, and so on. | ||
| − | |||
Connections also have relationships between elements. These can be spatial relationships like underneath, inside, ten feet apart, and so on. They are not necessarily static relationships since these can change over time. An element can be inside another element during one mode and outside during a different mode of operation. Also this relationship could be motion-related such as the relative velocity or acceleration between two elements. | Connections also have relationships between elements. These can be spatial relationships like underneath, inside, ten feet apart, and so on. They are not necessarily static relationships since these can change over time. An element can be inside another element during one mode and outside during a different mode of operation. Also this relationship could be motion-related such as the relative velocity or acceleration between two elements. | ||
| Line 18: | Line 16: | ||
The development, delivery, operation and eventual disposal of a product is supported by a variety of enabling systems (themselves being products or services) that enable appropriate activities during various stages of the life cycle as portrayed in Figure x. Enabling systems are an important concept incorporated in the ISO/IEC 15288 standard. | The development, delivery, operation and eventual disposal of a product is supported by a variety of enabling systems (themselves being products or services) that enable appropriate activities during various stages of the life cycle as portrayed in Figure x. Enabling systems are an important concept incorporated in the ISO/IEC 15288 standard. | ||
| − | + | ||
| + | |||
| + | |||
Figure 1. Example of Enabling Systems (Lawson (2010)) | Figure 1. Example of Enabling Systems (Lawson (2010)) | ||
| Line 31: | Line 31: | ||
IEEE standard 1471-2000 defines architecture as “The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”. ISO/IEC 42010-2011 defines architecture as “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.” | IEEE standard 1471-2000 defines architecture as “The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”. ISO/IEC 42010-2011 defines architecture as “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.” | ||
| − | A product’s purpose (stakeholder’s desire) is realized by a product system (the SOI) but product systems are composed of different entities (components, assemblies, subsystems, information, facilities, processes, organizations, people) that together produce the results unachievable by any of the entities alone. Thus in architecting the product a whole systems approach is taken to define, document, design, develop, manufacture, distribute, maintain, improve, and to certify proper implementation of the product’s objectives in terms of functional (what), behavioral/use (intended operations), Logical (entities interaction and relationships) and the physical constructs. (Wasson 2006) (Maier 2009) (Blanchard | + | A product’s purpose (stakeholder’s desire) is realized by a product system (the SOI) but product systems are composed of different entities (components, assemblies, subsystems, information, facilities, processes, organizations, people) that together produce the results unachievable by any of the entities alone. Thus in architecting the product a whole systems approach is taken to define, document, design, develop, manufacture, distribute, maintain, improve, and to certify proper implementation of the product’s objectives in terms of functional (what), behavioral/use (intended operations), Logical (entities interaction and relationships) and the physical constructs. (Wasson 2006) (Maier 2009) (Blanchard and Fabrycky 2011). |
The system architect starts at the highest level of abstraction to represent the stakeholder’s Market Service Description or the Concept of Operations (understanding the opportunity/problem space) by concentrating on needs, functions, systems characteristics and constraints (concerns) before identifying components, assemblies, subsystems, etc. This is known as the systems view. | The system architect starts at the highest level of abstraction to represent the stakeholder’s Market Service Description or the Concept of Operations (understanding the opportunity/problem space) by concentrating on needs, functions, systems characteristics and constraints (concerns) before identifying components, assemblies, subsystems, etc. This is known as the systems view. | ||
| Line 46: | Line 46: | ||
There are some differences between acquired products and offered products that play a very important role in the definition of the Product System requirements. Acquired products are Lifecycle managed directly by the acquirer; for instance acquired defense systems are defined, developed, tested, owned, operated, maintained and upgraded by the defense agency. The reader is referred to the Offered vs. Acquired Products article in this KA. | There are some differences between acquired products and offered products that play a very important role in the definition of the Product System requirements. Acquired products are Lifecycle managed directly by the acquirer; for instance acquired defense systems are defined, developed, tested, owned, operated, maintained and upgraded by the defense agency. The reader is referred to the Offered vs. Acquired Products article in this KA. | ||
| − | |||
Figure 2. System Architectural Description Elements (Adapted from [Wasson 2006]) | Figure 2. System Architectural Description Elements (Adapted from [Wasson 2006]) | ||
| − | |||
== Specialty Engineering Integration == | == Specialty Engineering Integration == | ||
The INCOSE handbook defines Specialty Engineering as: | The INCOSE handbook defines Specialty Engineering as: | ||
| + | |||
“Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle.” | “Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle.” | ||
| + | |||
There are many areas of expertise that fall under this umbrella definition including: logistics support, electromagnetic compatibility analysis, environmental impact, human factors, safety & health analysis, and training. The areas of specialty that apply are determined by the system of interest, its unique characteristics, requirements and design challenges. | There are many areas of expertise that fall under this umbrella definition including: logistics support, electromagnetic compatibility analysis, environmental impact, human factors, safety & health analysis, and training. The areas of specialty that apply are determined by the system of interest, its unique characteristics, requirements and design challenges. | ||
Product systems have a number of specialty engineering areas that are typically important to the systems engineers working on the development, deployment and sustainment of the product systems. For example, logistics support is essential for fielded product systems that require maintenance and repair. The delivery of the services, and the materials, parts and software necessary for supporting the system must all be considered very early in the development activity, usually before the system requirements and concept definition are complete. It is the necessity of integrating these specialty disciplines early that makes it necessary for the systems engineer to know what the specialties are that related to the system under development and to know how they related to the systems engineering process and how to integrate the specialties into the life cycle process. | Product systems have a number of specialty engineering areas that are typically important to the systems engineers working on the development, deployment and sustainment of the product systems. For example, logistics support is essential for fielded product systems that require maintenance and repair. The delivery of the services, and the materials, parts and software necessary for supporting the system must all be considered very early in the development activity, usually before the system requirements and concept definition are complete. It is the necessity of integrating these specialty disciplines early that makes it necessary for the systems engineer to know what the specialties are that related to the system under development and to know how they related to the systems engineering process and how to integrate the specialties into the life cycle process. | ||
Product Systems that have significant hardware content and that operate in challenging environments usually have the following specialty engineering areas that must be considered: | Product Systems that have significant hardware content and that operate in challenging environments usually have the following specialty engineering areas that must be considered: | ||
| + | |||
1) Manufacturability | 1) Manufacturability | ||
| + | |||
2) Reliability and Maintainability | 2) Reliability and Maintainability | ||
| + | |||
3) Certification (essential were human safety is an issue) | 3) Certification (essential were human safety is an issue) | ||
| + | |||
4) Logistics support | 4) Logistics support | ||
| + | |||
5) Electromagnetic compatibility (if they radiate) | 5) Electromagnetic compatibility (if they radiate) | ||
| + | |||
6) Environmental impact | 6) Environmental impact | ||
| + | |||
7) Human factors | 7) Human factors | ||
| + | |||
8) Safety & Health | 8) Safety & Health | ||
| + | |||
9) Training | 9) Training | ||
The relationship of these specialty areas to the systems engineering process must be understood and considered. The key aspects of the relationship are: | The relationship of these specialty areas to the systems engineering process must be understood and considered. The key aspects of the relationship are: | ||
| + | |||
a) When the specialty needs to be considered, | a) When the specialty needs to be considered, | ||
| + | |||
b) What essential data or information it provides, | b) What essential data or information it provides, | ||
| + | |||
c) The consequences of not including the specialty in the systems engineering process and | c) The consequences of not including the specialty in the systems engineering process and | ||
| + | |||
d) How the systems engineers should interact with the specialty engineers. | d) How the systems engineers should interact with the specialty engineers. | ||
| − | Grady 2006) provides an overview, with references, for many of the specialty engineering disciplines: including Reliability Engineering, Parts, Materials, and Process Engineering (PMP), Maintainability Engineering, Availability, Producibility Engineering, Design to Cost/Life-Cycle Cost (DTC/LCC), Human Factors Engineering, Corrosion Prevention and Control (CPC), System Safety Engineering, Electromagnetic Compatibility (EMC) Engineering, System Security Engineering, Mass Properties Engineering , and Environmental Impact Engineering. | + | Grady (2006) provides an overview, with references, for many of the specialty engineering disciplines: including Reliability Engineering, Parts, Materials, and Process Engineering (PMP), Maintainability Engineering, Availability, Producibility Engineering, Design to Cost/Life-Cycle Cost (DTC/LCC), Human Factors Engineering, Corrosion Prevention and Control (CPC), System Safety Engineering, Electromagnetic Compatibility (EMC) Engineering, System Security Engineering, Mass Properties Engineering , and Environmental Impact Engineering. |
(Eisner 2008) lists Specialty Engineering as one of the Thirty Elements of Systems Engineering. “Specialty engineering refers to a set of engineering topics that have to be explored on some, but not all, systems engineering efforts. In other words, some systems involve these special disciplines and some do not. Examples of specialty engineering areas include: Electromagnetic compatibility and interference, Safety, Physical security, Computer security, Communications security, Demand forecasting, Object-oriented design, and Value engineering.” Eisner lists many of the specialty items above in this article as one of the thirty elements of SE and not as part of the specialty engineering list. | (Eisner 2008) lists Specialty Engineering as one of the Thirty Elements of Systems Engineering. “Specialty engineering refers to a set of engineering topics that have to be explored on some, but not all, systems engineering efforts. In other words, some systems involve these special disciplines and some do not. Examples of specialty engineering areas include: Electromagnetic compatibility and interference, Safety, Physical security, Computer security, Communications security, Demand forecasting, Object-oriented design, and Value engineering.” Eisner lists many of the specialty items above in this article as one of the thirty elements of SE and not as part of the specialty engineering list. | ||
| Line 88: | Line 101: | ||
ANSI/IEEE. 2000 1471. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000. | ANSI/IEEE. 2000 1471. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000. | ||
| − | Blanchard and Fabrycky 2011. | + | Blanchard, B and Fabrycky, W. 2011. Systems Engineering and Analysis. Prentice Hall International Series in Industrial and Systems Engineering. ISBN 978-0-13-221735-4 |
| − | Eisner, | + | Eisner, H. 2008. The Thirty Elements of Systems Engineering - Chapter 7. Essentials of Project and Systems Engineering Management. Third Edition. John Wiley & Sons. |
| − | Grady, J. 2006 | + | Grady, J. 2006. System Requirements Analysis. Elsevier. ISBN 978-0-12-088514-5 |
| − | Grady, | + | Grady, J. 2006. Specialty Engineering Requirements Analysis - Chapter 3.7. System Requirements Analysis. Academic Press. |
| − | Grady, J. 2010 | + | Grady, J. 2010. Systems Synthesis- Product and Process Design. CRC Press. ISBN 978-1-4398-1961-6 |
Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8 | Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8 | ||
| − | INCOSE v3.1 | + | INCOSE Systems Engineering Handbook v3.1 |
ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. | ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. | ||
ISO/IEC 2008. Systems and software engineering -- System life cycle processes. | ISO/IEC 2008. Systems and software engineering -- System life cycle processes. | ||
| + | |||
| + | ISO/IEC/IEEE 42010. 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. | ||
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK. | Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK. | ||
| − | Maier, M. Rechtin E. 2009 | + | Maier, M. and Rechtin, E. 2009. The Art of Systems Architecting. Third edition. CRC Press. ISBN 978-1-4200-7913-5 |
| − | + | Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA. | |
| − | + | ===Primary References=== | |
| + | ANSI/IEEE. 2000 1471. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000. | ||
| − | + | Blanchard, B and Fabrycky, W. 2011. Systems Engineering and Analysis. Prentice Hall International Series in Industrial and Systems Engineering. ISBN 978-0-13-221735-4 | |
| − | Blanchard and Fabrycky 2011. | ||
| − | Grady, J. 2006 | + | Grady, J. 2006. System Requirements Analysis. Elsevier. ISBN 978-0-12-088514-5 |
| − | Grady, J. 2010 | + | Grady, J. 2010. Systems Synthesis- Product and Process Design. CRC Press. ISBN 978-1-4398-1961-6 |
| − | + | INCOSE Systems Engineering Handbook v3.1 | |
| − | + | ISO/IEC/IEEE 42010. 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. | |
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK. | Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK. | ||
| − | Maier, M. Rechtin E. 2009 | + | Maier, M. and Rechtin, E. 2009. The Art of Systems Architecting. Third edition. CRC Press. ISBN 978-1-4200-7913-5 |
| − | + | Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA. | |
| − | |||
| − | Wasson, C. S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA | ||
===Additional References=== | ===Additional References=== | ||
| − | Grady, | + | Grady, J. 2006. Specialty Engineering Requirements Analysis - Chapter 3.7. System Requirements Analysis. Academic Press. |
| − | Eisner, | + | |
| + | Eisner, H. 2008. The Thirty Elements of Systems Engineering - Chapter 7. Essentials of Project and Systems Engineering Management. Third Edition. John Wiley & Sons. | ||
Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8 | Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8 | ||
| + | |||
ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. | ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. | ||
| − | + | ||
ISO/IEC 2008. Systems and software engineering -- System life cycle processes. | ISO/IEC 2008. Systems and software engineering -- System life cycle processes. | ||
| + | |||
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK. | Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK. | ||
[[Category:Part 1]][[Category:Topic]] | [[Category:Part 1]][[Category:Topic]] | ||
Revision as of 16:54, 16 January 2012
Product Elements and Connections
Product systems consist of product elements and connections among these elements and between these elements and things in the environment of that system. That portion of the environment that can be influenced by the system or that can influence the system is called the “context.”
The connections in a product system are not merely the interfaces. The connections between elements contain interactions and relationships (Hybertson 2009). Interactions occur across “interfaces” between the elements inside or outside the system, i.e., they can be either internal or external to the system. These interactions can be in the form of data, materials, forces, or energy. Product SE usually captures the definition of these interactions in an interface control document, interface design document, interface requirements document, or some other equivalent form. Interaction-like connections can be represented in various engineering artifacts: schematic block diagram, data flow diagram, free body diagram, interface control diagram, port specification, energy transfer diagram, and so on.
Connections also have relationships between elements. These can be spatial relationships like underneath, inside, ten feet apart, and so on. They are not necessarily static relationships since these can change over time. An element can be inside another element during one mode and outside during a different mode of operation. Also this relationship could be motion-related such as the relative velocity or acceleration between two elements.
Temporal relationships can be exist between elements such as: this item exists before that one does, these items must exist at the same time, these two items must be separated in time by three years, and so on. Relationships can be represented in various engineering artifacts such as, timing diagram, timeline diagram, mission reference profile, capability roadmap, and project schedule chart.
Social relationships can be important to the success of a product system, especially when one or more of the components are human beings serving in particular roles. See the discussion on organization behavior in (http://www.sebokwiki075.org/wiki/index.php?title=Team_Dynamics). The human roles may have different assigned authorities, responsibilities, and accountabilities that can lead to either implicit or explicit social obligations or expectations between those roles. Organizational behavior theories and human factors may need to be considered when engineering such a product system.
There can also be social relationships between the humans and the non-human elements of the system. This may involve how the human “feels” about things in the system or perhaps even the system as a whole, which could affect the overall performance or behavior of the system. Humans inside or outside the system of interest may have different degrees of “understanding” with respect to how the system operates, its limitations and capabilities, and the best way to operate it safely and effectively. The “ownership” relationship can be important in determining things like who can operate or change some configuration or mode of the system. There are many such social relationships in a product system that are often ignored or misunderstood when performing Product SE.
Core Product & Its Enabling Products & Operational Services
The development, delivery, operation and eventual disposal of a product is supported by a variety of enabling systems (themselves being products or services) that enable appropriate activities during various stages of the life cycle as portrayed in Figure x. Enabling systems are an important concept incorporated in the ISO/IEC 15288 standard.
Figure 1. Example of Enabling Systems (Lawson (2010))
In the figure the System of Interest (SOI) when put into operation as a delivered product or offered service occurs in the Utilization stage. It is common that this stage is paralleled by a Support stage (Product Sustainment System) where maintenance, logistics are provided. During these two stages the need for changes in the properties of the product or service as well as the means of operating and supporting may be observed. This can result in an iteration of the life cycle in order to make the desired changes and can result in products, improved products and/or potentially new products/service features or functionalities.
During the life cycle stages various enabling systems must be deployed. Collectively the delivered product or service and all of the related enabling systems form a Wider System of Interest (WSOI) that includes the enabling systems shown in Figure x. The Project Design enabling system is an enterprise based system asset that establishes the strategy and means of organizing the projects to be executed along the life cycle. In many larger organizations, this type of enabling system is institutionalized and can be based upon recommendations of the PMI (Project Management Institute). The other enabling systems illustrated in the figure provide needed products and services; for example, the Deployment System can provide installation instructions and training.
Products are provided to enterprises that incorporate them as system assets and then use them to enable their operations. Likewise various hardware and software products are often utilized in enabling the provisioning of service systems. In the system of systems context, provided products are integrated into the system of systems. In all cases, the product systems should be viewed as enabling service systems (that is when deployed they provide a service) that contribute in some manner to the enterprise’s operations. To the acquirer of the product system, their system of interest when delivered provides operational services to their users.
Product Architecture, Modeling & Analysis
IEEE standard 1471-2000 defines architecture as “The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”. ISO/IEC 42010-2011 defines architecture as “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”
A product’s purpose (stakeholder’s desire) is realized by a product system (the SOI) but product systems are composed of different entities (components, assemblies, subsystems, information, facilities, processes, organizations, people) that together produce the results unachievable by any of the entities alone. Thus in architecting the product a whole systems approach is taken to define, document, design, develop, manufacture, distribute, maintain, improve, and to certify proper implementation of the product’s objectives in terms of functional (what), behavioral/use (intended operations), Logical (entities interaction and relationships) and the physical constructs. (Wasson 2006) (Maier 2009) (Blanchard and Fabrycky 2011).
The system architect starts at the highest level of abstraction to represent the stakeholder’s Market Service Description or the Concept of Operations (understanding the opportunity/problem space) by concentrating on needs, functions, systems characteristics and constraints (concerns) before identifying components, assemblies, subsystems, etc. This is known as the systems view.
As the level of understanding of the needs increases then architectural descriptions at different levels of abstractions representing various stakeholders interests are documented to express the detailed system’s requirements, operational requirements, behavior requirements and the physical constructs requirements of the product system; these descriptions then constitute the Product Systems architecture Models and define the possible solution spaces for the product purpose.
The Architectural descriptions are expressed through different modeling techniques to analyze different types of requirements; e.g., hierarchical decomposition and allocation, Architectural Block Diagrams (ABD), Functional Block Diagrams (FBD), Functional Flow Block Diagrams (FFBD), use case for operational scenarios and different modes of operations, sequence diagrams, activity diagrams, state diagrams, and components relationships through data flow diagrams and ports for interactions among hardware/SW components. The reader is referred to (Maier 2009) Chapter 8 for a good introduction to Models and Modeling.
Analysis of the solution space will then transform the set of requirements into products and processes that satisfy the stakeholder’s need through detailed technical specs, engineering drawings, blue prints, software architectures, information flows, etc. for the Product System’s entities. The entity’s requirements then bound the entity’s attributes/characteristics, levels of performance, its operational capabilities and its design constraints. The entity’s design are traced back (requirements traceability) and tested during the design through Integration, Verification & Validation plans build during the requirement phase to certify the product does what was intended to do.
We can they say that the architecture is represented by a set of models that communicate to the stakeholders, designers/developers, specialty engineering, operations, manufacturers, management, marketing & sales an integrated view of the product’s intent and purpose and the interactions and interfaces required among all the different participating entities to realize the product purpose in terms of the business objectives (market, cost, functionality, performance, time to deliver).
Architectural Frameworks have been defined for commercial enterprises and public enterprises to guide product teams in defining the product architecture. In general, architectural frameworks describe a “collection of models that represent the whole system from the perspective of a set of related stakeholder concerns a “view”” produced and delivered to the stakeholders of the product system.
There are some differences between acquired products and offered products that play a very important role in the definition of the Product System requirements. Acquired products are Lifecycle managed directly by the acquirer; for instance acquired defense systems are defined, developed, tested, owned, operated, maintained and upgraded by the defense agency. The reader is referred to the Offered vs. Acquired Products article in this KA.
Figure 2. System Architectural Description Elements (Adapted from [Wasson 2006])
Specialty Engineering Integration
The INCOSE handbook defines Specialty Engineering as:
“Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle.”
There are many areas of expertise that fall under this umbrella definition including: logistics support, electromagnetic compatibility analysis, environmental impact, human factors, safety & health analysis, and training. The areas of specialty that apply are determined by the system of interest, its unique characteristics, requirements and design challenges. Product systems have a number of specialty engineering areas that are typically important to the systems engineers working on the development, deployment and sustainment of the product systems. For example, logistics support is essential for fielded product systems that require maintenance and repair. The delivery of the services, and the materials, parts and software necessary for supporting the system must all be considered very early in the development activity, usually before the system requirements and concept definition are complete. It is the necessity of integrating these specialty disciplines early that makes it necessary for the systems engineer to know what the specialties are that related to the system under development and to know how they related to the systems engineering process and how to integrate the specialties into the life cycle process. Product Systems that have significant hardware content and that operate in challenging environments usually have the following specialty engineering areas that must be considered:
1) Manufacturability
2) Reliability and Maintainability
3) Certification (essential were human safety is an issue)
4) Logistics support
5) Electromagnetic compatibility (if they radiate)
6) Environmental impact
7) Human factors
8) Safety & Health
9) Training
The relationship of these specialty areas to the systems engineering process must be understood and considered. The key aspects of the relationship are:
a) When the specialty needs to be considered,
b) What essential data or information it provides,
c) The consequences of not including the specialty in the systems engineering process and
d) How the systems engineers should interact with the specialty engineers.
Grady (2006) provides an overview, with references, for many of the specialty engineering disciplines: including Reliability Engineering, Parts, Materials, and Process Engineering (PMP), Maintainability Engineering, Availability, Producibility Engineering, Design to Cost/Life-Cycle Cost (DTC/LCC), Human Factors Engineering, Corrosion Prevention and Control (CPC), System Safety Engineering, Electromagnetic Compatibility (EMC) Engineering, System Security Engineering, Mass Properties Engineering , and Environmental Impact Engineering.
(Eisner 2008) lists Specialty Engineering as one of the Thirty Elements of Systems Engineering. “Specialty engineering refers to a set of engineering topics that have to be explored on some, but not all, systems engineering efforts. In other words, some systems involve these special disciplines and some do not. Examples of specialty engineering areas include: Electromagnetic compatibility and interference, Safety, Physical security, Computer security, Communications security, Demand forecasting, Object-oriented design, and Value engineering.” Eisner lists many of the specialty items above in this article as one of the thirty elements of SE and not as part of the specialty engineering list.
There is no standard list of specialty engineering disciplines. The list of what is or is not specialty engineering will depend upon the community the SE belongs to and sometimes to the specific preferences of the customer.
References
Citations
ANSI/IEEE. 2000 1471. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.
Blanchard, B and Fabrycky, W. 2011. Systems Engineering and Analysis. Prentice Hall International Series in Industrial and Systems Engineering. ISBN 978-0-13-221735-4
Eisner, H. 2008. The Thirty Elements of Systems Engineering - Chapter 7. Essentials of Project and Systems Engineering Management. Third Edition. John Wiley & Sons.
Grady, J. 2006. System Requirements Analysis. Elsevier. ISBN 978-0-12-088514-5
Grady, J. 2006. Specialty Engineering Requirements Analysis - Chapter 3.7. System Requirements Analysis. Academic Press.
Grady, J. 2010. Systems Synthesis- Product and Process Design. CRC Press. ISBN 978-1-4398-1961-6
Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8
INCOSE Systems Engineering Handbook v3.1
ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions.
ISO/IEC 2008. Systems and software engineering -- System life cycle processes.
ISO/IEC/IEEE 42010. 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.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
Maier, M. and Rechtin, E. 2009. The Art of Systems Architecting. Third edition. CRC Press. ISBN 978-1-4200-7913-5
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA.
Primary References
ANSI/IEEE. 2000 1471. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.
Blanchard, B and Fabrycky, W. 2011. Systems Engineering and Analysis. Prentice Hall International Series in Industrial and Systems Engineering. ISBN 978-0-13-221735-4
Grady, J. 2006. System Requirements Analysis. Elsevier. ISBN 978-0-12-088514-5
Grady, J. 2010. Systems Synthesis- Product and Process Design. CRC Press. ISBN 978-1-4398-1961-6
INCOSE Systems Engineering Handbook v3.1
ISO/IEC/IEEE 42010. 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.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
Maier, M. and Rechtin, E. 2009. The Art of Systems Architecting. Third edition. CRC Press. ISBN 978-1-4200-7913-5
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA.
Additional References
Grady, J. 2006. Specialty Engineering Requirements Analysis - Chapter 3.7. System Requirements Analysis. Academic Press.
Eisner, H. 2008. The Thirty Elements of Systems Engineering - Chapter 7. Essentials of Project and Systems Engineering Management. Third Edition. John Wiley & Sons.
Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8
ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions.
ISO/IEC 2008. Systems and software engineering -- System life cycle processes.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.