Difference between revisions of "Product as a System Fundamentals"

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")
(96 intermediate revisions by 12 users not shown)
Line 1: Line 1:
−
== Product Elements and Connections ==
+
----
 +
'''''Lead Author:''''' ''Ricardo Pineda''
 +
----
 +
[[File:PPI.png|thumb|250px|right|<center>The "Product Systems Engineering" knowledge area is graciously sponsored by PPI.<center>]]
 +
This article introduces fundamental concepts of product systems. 
  
−
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.”
+
==Product Elements and Connections==
  
−
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.
+
Product systems consist of product elements and two kinds of connections: connections among elements, and connections between elements and things in the system environment. That portion of the environment that can be influenced by the system or that can influence the system is called the “context.”
  
−
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 between elements contain interactions and relationships (Hybertson 2009). A connection is more than a mere interface.
  
−
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.
+
Interactions occur across ''interfaces'' between the elements inside or outside the system, and can be defined as exchanges of data, materials, forces, or energy. Connections with an interactive nature can be represented in various engineering artifacts: schematic block diagrams, data flow diagrams, free body diagrams, interface control diagrams, port specifications, energy transfer diagrams, and so on. Product systems engineering (PSE) usually defines interactions in an interface control document, interface design document, interface requirements document, or the equivalent.  
  
−
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.  
+
Connections also encompass relationships between elements. These relationships can be spatial, motion-related, temporal, or social.  
  
−
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.
+
Spatial relationships:
 +
* one element is underneath another
 +
* two elements are ''x units'' apart
 +
* one element is inside another
  
−
== Core Product & Its Enabling Products & Operational Services ==
+
Motion-related relationships:
 +
* the relative velocity of two elements is ''v units''
 +
* the relative acceleration between two elements is ''a units''
  
−
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.
+
Temporal relationships:
 +
* one element exists before another
 +
* two elements must exist at the same time
 +
* two elements must be separated in time by ''t units''
  
 +
Social relationships:
 +
* a human element feels a particular way about a system
 +
* a human element owns another (non-human) element
 +
* a human element understands the operation of a system in a particular way
  
 +
Relationships that are not about time can still change over time. For example, an element that is inside another element during one mode of operation can be outside of it during a different mode of operation. Therefore, one should not assume that non-temporal relationships are necessarily static in time.
  
−
Figure 1. Example of Enabling Systems (Lawson (2010))
+
Relationships can be represented in engineering artifacts, including the timing diagram, timeline diagram, mission reference profile, capability road map, and project schedule chart.  
  
−
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.  
+
Social relationships include the implicit or explicit social obligations or expectations between the roles that human elements play in a system. These roles may be assigned different authorities, responsibilities, and accountabilities. See the discussion on organization behavior in the article [[Team Dynamics]]. Organizational behavior theories and human factors may need to be considered when engineering such a product system.
  
−
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.  
+
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. 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.  
  
−
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.
+
There are many such social relationships in a product system that are often ignored or misunderstood when performing PSE. Social relationships can affect the overall performance or behavior of a product system to the point of determining its success or failure.
  
−
== Product Architecture, Modeling & Analysis ==
+
== Core Product and its Enabling Products & Operational Services ==
  
−
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 variety of systems (themselves being products or services) enable the development, delivery, operation and eventual disposal of a product, as shown in Figure 1.  The concept of enabling systems is defined in the ISO/IEC 15288 standard (2015).
  
−
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).
+
[[File:PSE_PAAS_Fig1.png|600px|thumb|center|'''Figure 1. Example of Enabling Systems (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
  
−
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.
+
In the figure, the system-of-interest (SoI) goes into operation as a delivered product or offered service in the utilization stage while maintenance and logistics are provided (by a product sustainment system) simultaneously in the support stage. These two stages are commonly executed in parallel, and they offer opportunities to observe any need for changes in the properties of the product or service or how it is operated and supported. Making changes iterates the life cycle and results in new or improved products or features.  
  
−
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 delivered product and its enabling systems collectively form a wider system-of-interest (WSOI). 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 Project Management Institute (PMI).  
  
−
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.
+
Product systems should be viewed as enabling service systems. That is, once deployed, a product system provides a service that contributes to an enterprise’s operations. To the {{Term|Acquirer (glossary)|acquirer}}, the SoI provides operational services to users. This is true at several levels:
 +
*Hardware and software products are used to enable the provisioning of service systems,  
 +
*Enterprises incorporate products as system assets and use them to enable operations, and  
 +
*Provided products are integrated into the system of systems.
  
−
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.
+
== Product Architecture, Modeling, and Analysis ==
  
−
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).
+
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" (IEEE 2000). Similarly, 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" (ISO/IEC 2011).
  
−
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.
+
A product's purpose (stakeholder’s need) is realized by a product system (the SoI). Because product systems are composed of different entities (components, assemblies, subsystems, information, facilities, processes, organizations, people, etc.) that together produce the results unachievable by any of the entities alone, architecting the product is based on a whole systems approach. To architect with a whole systems approach means to define, document, design, develop, manufacture, distribute, maintain, improve, and to certify proper implementation of the product’s objectives in terms of the functional (the "what"), the behavioral (the use, or intended operations), the logical (interaction and relationships between entities) and the physical constructs (Wasson 2006; Maier 2009; Blanchard and Fabrycky 2011).
  
−
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.
+
The system architect starts at the highest level of abstraction, concentrating on needs, functions, systems characteristics and constraints (concerns) before identifying components, assemblies, or subsystems. This is the systems view, and it is used to represent the stakeholder’s market service description or the concept of operations (understanding of the opportunity/problem space).
−
 
  
 +
Next to be documented, as needs become better understood, are architectural descriptions at different levels of abstraction, representing various stakeholders interests. These are the architecture models. They define the possible solution spaces for the product purpose in the form of detailed system, operational, behavioral, and physical requirements of the product system. 
  
−
Figure 2. System Architectural Description Elements (Adapted from [Wasson 2006])
+
Different modeling techniques are then used to analyze different types of requirements. For operational scenarios and different modes of operation, there are hierarchical decomposition and allocation, architectural block diagrams (ABD), functional block diagrams (FBD), functional flow block diagrams (FFBD), and use case diagrams. For interactions and relationships among hardware and/or software components there are sequence diagrams, activity diagrams, state diagrams, and  data flow diagrams. See (Maier 2009) Chapter 8 for an introduction to models and modeling.
  
−
== Specialty Engineering Integration ==
+
Analysis of the solution space makes it possible to produce detailed technical specs, engineering drawings, blueprints, software architectures, information flows, and so on, that describe the entities in the product system. An entity’s requirements bound its attributes and characteristics, levels of performance, operational capabilities, and design constraints. During design and integration, entity characteristics can be traced back to requirements (requirements {{Term|Traceability (glossary)|traceability}} being a key aspect of SE). Verification and validation plans created during the requirements phase are the basis of testing certification that the product does what it was intended to do.
  
−
The INCOSE handbook defines Specialty Engineering as:
+
Overall, what occurs is the transformation of a set of requirements into products and processes that satisfy the stakeholder's need. The architecture is represented by a set of models that communicate an integrated view of the product's intent and purpose, and the interactions and interfaces required among all the different participating entities. The product's purpose is articulated in terms of business objectives (market, cost, functionality, performance, and time to deliver). The set of models includes sufficient variety to convey information appropriately to the stakeholders, designers/developers, specialty engineering, operations, manufacturers, management, and marketing and sales personnel.
  
−
“Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle.”
+
Different architecture frameworks have been developed to guide product teams in defining the product architecture for commercial and for public enterprises.  In general, an architecture framework describes a "view," meaning a "collection of models that represent the whole system from the perspective of a set of related stakeholder concerns." Prime examples of architecture frameworks are the Zachman framework (Zachman 1992), The Open Group Architecture Framework (TOGAF) (TOGAF 2011), the Enhanced-Telecom Operations Map (e-TOM), just to mention a few in the commercial sector. In the case of public enterprises a few architecture frameworks include the Department of Defense Architecture Framework (DODAF 2.0) (DoD 2010), the Federal Enterprise Architecture Framework (FEAF) (FEA 2001), the British Ministry of Defense Architecture Framework (MODAF) (MOD 2004), etc.  
  
−
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.
+
Differences between acquired products and offered products play an important role in defining product system requirements. Acquired products are life cycle-managed directly by the acquirer; for instance, acquired defense systems are defined, developed, tested, owned, operated, maintained and upgraded by the defense agency. See the article [[Product Systems Engineering Key Aspects]] within this KA.
−
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
+
[[File:PSE_PAAS_Fig2.png|725px|thumb|center|'''Figure 2. System Architectural Description Elements (Adapted from Wasson 2006).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
  
−
2) Reliability and Maintainability
+
== Specialty Engineering Integration ==
  
−
3) Certification (essential were human safety is an issue)
+
The INCOSE ''SE Handbook'' defines specialty engineering as:
  
−
4) Logistics support
+
“Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle.”
  
−
5) Electromagnetic compatibility (if they radiate)
+
Areas of expertise that fall under this umbrella definition include logistics support, electromagnetic compatibility analysis, environmental impact, human factors, safety and health analysis, and training. The unique characteristics, requirements, and design challenges of a system-of-interest all help determine the areas of specialty that apply.
  
−
6) Environmental impact
+
A number of specialty engineering areas are typically important to systems engineers working on the development, deployment, and sustainment of product systems. For example, logistics support is essential for fielded product systems that require maintenance and repair. The delivery of services, materials, parts, and software necessary for supporting the system must all be considered very early in the development activity. These factors should usually be considered before the system requirements and concept definition are complete. To integrate these specialty disciplines sufficiently early on, the systems engineer needs to know what specialties relate to the system under development, how they relate to the systems engineering process, and how to integrate them into the life cycle process.
  
−
7) Human factors
+
For product systems with significant hardware content and that operate in challenging environments, the following specialty engineering areas must usually be considered:
  
−
8) Safety & Health
+
* manufacturability,
 +
* reliability and maintainability,
 +
* certification (essential where human safety is an issue),
 +
* logistics support,
 +
* electromagnetic compatibility (if they radiate),
 +
* environmental impact,
 +
* human factors,
 +
* safety and health, and
 +
* 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:
+
* when the specialty needs to be considered,
 +
* what essential data or information it provides,
 +
* the consequences of not including the specialty in the systems engineering process, and
 +
* how the systems engineers should interact with the specialty engineers.
  
−
a) When the specialty needs to be considered,
+
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.
  
−
b) What essential data or information it provides,
+
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.”  Some of what we consider specialty engineering in the present article, Eisner includes among his “thirty elements” of systems engineering, but not as part of the specialty engineering element.
  
−
c) The consequences of not including the specialty in the systems engineering process and
+
There is no standard list of specialty engineering disciplines. What is considered specialty engineering varies according to the community to which the systems engineering belongs, and sometimes to the preferences of the customer.
  
−
d) How the systems engineers should interact with the specialty engineers.
+
==References==
  
−
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.
+
===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.
  
−
(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.
+
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice Hall.
  
−
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.
+
Eisner, H. 2008. "Chapter 7. Essentials of Project and Systems Engineering Management," in ''The Thirty Elements of Systems Engineering'', 3rd ed. New York, NY, USA: John Wiley & Sons.
  
 +
Grady, J. 2006. "Chapter 3.7. System Requirements Analysis," in ''Specialty Engineering Requirements Analysis''. New York, NY, USA: Academic Press.
  
−
==References==
+
Grady, J. 2006. ''System Requirements Analysis''. New York, NY, USA: Academic Press.
  
−
===Citations===
+
Grady, J. 2010. ''Systems Synthesis - Product and Process Design''. Boca Raton, FL, USA: CRC Press.
−
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
+
Hybertson, D. 2009. ''Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems''. Boston, MA, USA: Auerbach Publications.
  
−
Eisner, H. 2008. The Thirty Elements of Systems Engineering - Chapter 7. Essentials of Project and Systems Engineering Management. Third Edition. John Wiley & Sons.
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
−
Grady, J. 2006. System Requirements Analysis. Elsevier. ISBN 978-0-12-088514-5
+
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.[[ISO/IEC/IEEE 15288|ISO/IEC 15288]]:2015.
  
−
Grady, J. 2006. Specialty Engineering Requirements Analysis - Chapter 3.7. System Requirements Analysis.  Academic Press.  
+
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.
  
−
Grady, J. 2010. Systems Synthesis- Product and Process Design. CRC Press. ISBN 978-1-4398-1961-6
+
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]]''. London, UK: College Publications.
  
−
Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Auerbach Publications. ISBN 978-1-4200-7251-8
+
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]]'', 3rd ed. Boca Raton, FL, USA: CRC Press.
  
−
INCOSE Systems Engineering Handbook v3.1
+
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: UK Ministry of Defence.
  
−
ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions.  
+
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
  
−
ISO/IEC 2008. Systems and software engineering -- System life cycle processes.  
+
Wasson, C.S. 2006. ''[[System Analysis, Design, and Development]]''. Hoboken, NJ, USA: John Wiley & Sons.
  
−
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.
+
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal''. 31 (3): 590-616.
  
−
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
+
===Primary References===
  
−
Maier, M. and Rechtin, E. 2009. The Art of Systems Architecting. Third edition. CRC Press. ISBN 978-1-4200-7913-5
+
Eisner, H. 2008. "Chapter 7. Essentials of Project and Systems Engineering Management," in ''[[The Thirty Elements of Systems Engineering]]'', 3rd ed. New York, NY, USA: John Wiley & Sons.
  
−
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA.
+
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]]''. London, UK: College Publications.
  
−
===Primary References===
+
Wasson, C.S. 2006. ''[[System Analysis, Design, and Development]]''. Hoboken, NJ, USA: John Wiley & Sons.
−
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
+
===Additional References===
 +
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.
  
−
Grady, J. 2006. System Requirements Analysis. Elsevier. ISBN 978-0-12-088514-5
+
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice Hall.
  
−
Grady, J. 2010. Systems Synthesis- Product and Process Design. CRC Press. ISBN 978-1-4398-1961-6
+
Grady, J. 2006. "Chapter 3.7. System Requirements Analysis," in ''Specialty Engineering Requirements Analysis''. New York, NY, USA: Academic Press.
  
−
INCOSE Systems Engineering Handbook v3.1
+
Grady, J. 2006. ''System Requirements Analysis''. New York, NY: Academic Press.
  
−
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.
+
Grady, J. 2010. ''Systems Synthesis- Product and Process Design''. Boca Raton, FL, USA: CRC Press.
  
−
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
+
Hybertson, D. 2009. ''Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems''. Boston, MA, USA: Auerbach Publications.
  
−
Maier, M. and Rechtin, E. 2009. The Art of Systems Architecting. Third edition. CRC Press. ISBN 978-1-4200-7913-5
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
−
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA.  
+
ISO/IEC. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering]] -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.
  
−
===Additional References===
+
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.
−
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
+
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]]'', 3rd ed. Boca Raton, FL, USA: CRC Press.
  
−
ISO/IEC/IEEE 15288:2008. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions.  
+
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
  
−
ISO/IEC 2008. Systems and software engineering -- System life cycle processes.
+
----
 +
<center>[[Product Systems Engineering Background|< Previous Article]]  |  [[Product Systems Engineering|Parent Article]]  |  [[Business Activities Related to Product Systems Engineering|Next Article >]]</center>
  
−
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.
+
<center>'''SEBoK v. 2.9, released 20 November 2023'''</center>
  
−
[[Category:Part 1]][[Category:Topic]]
+
[[Category:Part 4]][[Category:Topic]]
 +
[[Category:Product Systems Engineering]]

Revision as of 22:11, 18 November 2023

Lead Author: Ricardo Pineda

The "Product Systems Engineering" knowledge area is graciously sponsored by PPI.

This article introduces fundamental concepts of product systems.

Product Elements and Connections

Product systems consist of product elements and two kinds of connections: connections among elements, and connections between elements and things in the system environment. That portion of the environment that can be influenced by the system or that can influence the system is called the “context.”

Connections between elements contain interactions and relationships (Hybertson 2009). A connection is more than a mere interface.

Interactions occur across interfaces between the elements inside or outside the system, and can be defined as exchanges of data, materials, forces, or energy. Connections with an interactive nature can be represented in various engineering artifacts: schematic block diagrams, data flow diagrams, free body diagrams, interface control diagrams, port specifications, energy transfer diagrams, and so on. Product systems engineering (PSE) usually defines interactions in an interface control document, interface design document, interface requirements document, or the equivalent.

Connections also encompass relationships between elements. These relationships can be spatial, motion-related, temporal, or social.

Spatial relationships:

  • one element is underneath another
  • two elements are x units apart
  • one element is inside another

Motion-related relationships:

  • the relative velocity of two elements is v units
  • the relative acceleration between two elements is a units

Temporal relationships:

  • one element exists before another
  • two elements must exist at the same time
  • two elements must be separated in time by t units

Social relationships:

  • a human element feels a particular way about a system
  • a human element owns another (non-human) element
  • a human element understands the operation of a system in a particular way

Relationships that are not about time can still change over time. For example, an element that is inside another element during one mode of operation can be outside of it during a different mode of operation. Therefore, one should not assume that non-temporal relationships are necessarily static in time.

Relationships can be represented in engineering artifacts, including the timing diagram, timeline diagram, mission reference profile, capability road map, and project schedule chart.

Social relationships include the implicit or explicit social obligations or expectations between the roles that human elements play in a system. These roles may be assigned different authorities, responsibilities, and accountabilities. See the discussion on organization behavior in the article Team Dynamics. 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. 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 PSE. Social relationships can affect the overall performance or behavior of a product system to the point of determining its success or failure.

Core Product and its Enabling Products & Operational Services

A variety of systems (themselves being products or services) enable the development, delivery, operation and eventual disposal of a product, as shown in Figure 1. The concept of enabling systems is defined in the ISO/IEC 15288 standard (2015).

Figure 1. Example of Enabling Systems (Lawson 2010). Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.

In the figure, the system-of-interest (SoI) goes into operation as a delivered product or offered service in the utilization stage while maintenance and logistics are provided (by a product sustainment system) simultaneously in the support stage. These two stages are commonly executed in parallel, and they offer opportunities to observe any need for changes in the properties of the product or service or how it is operated and supported. Making changes iterates the life cycle and results in new or improved products or features.

The delivered product and its enabling systems collectively form a wider system-of-interest (WSOI). 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 Project Management Institute (PMI).

Product systems should be viewed as enabling service systems. That is, once deployed, a product system provides a service that contributes to an enterprise’s operations. To the acquireracquirer, the SoI provides operational services to users. This is true at several levels:

  • Hardware and software products are used to enable the provisioning of service systems,
  • Enterprises incorporate products as system assets and use them to enable operations, and
  • Provided products are integrated into the system of systems.

Product Architecture, Modeling, and 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" (IEEE 2000). Similarly, 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" (ISO/IEC 2011).

A product's purpose (stakeholder’s need) is realized by a product system (the SoI). Because product systems are composed of different entities (components, assemblies, subsystems, information, facilities, processes, organizations, people, etc.) that together produce the results unachievable by any of the entities alone, architecting the product is based on a whole systems approach. To architect with a whole systems approach means to define, document, design, develop, manufacture, distribute, maintain, improve, and to certify proper implementation of the product’s objectives in terms of the functional (the "what"), the behavioral (the use, or intended operations), the logical (interaction and relationships between entities) and the physical constructs (Wasson 2006; Maier 2009; Blanchard and Fabrycky 2011).

The system architect starts at the highest level of abstraction, concentrating on needs, functions, systems characteristics and constraints (concerns) before identifying components, assemblies, or subsystems. This is the systems view, and it is used to represent the stakeholder’s market service description or the concept of operations (understanding of the opportunity/problem space).

Next to be documented, as needs become better understood, are architectural descriptions at different levels of abstraction, representing various stakeholders interests. These are the architecture models. They define the possible solution spaces for the product purpose in the form of detailed system, operational, behavioral, and physical requirements of the product system.

Different modeling techniques are then used to analyze different types of requirements. For operational scenarios and different modes of operation, there are hierarchical decomposition and allocation, architectural block diagrams (ABD), functional block diagrams (FBD), functional flow block diagrams (FFBD), and use case diagrams. For interactions and relationships among hardware and/or software components there are sequence diagrams, activity diagrams, state diagrams, and data flow diagrams. See (Maier 2009) Chapter 8 for an introduction to models and modeling.

Analysis of the solution space makes it possible to produce detailed technical specs, engineering drawings, blueprints, software architectures, information flows, and so on, that describe the entities in the product system. An entity’s requirements bound its attributes and characteristics, levels of performance, operational capabilities, and design constraints. During design and integration, entity characteristics can be traced back to requirements (requirements traceabilitytraceability being a key aspect of SE). Verification and validation plans created during the requirements phase are the basis of testing certification that the product does what it was intended to do.

Overall, what occurs is the transformation of a set of requirements into products and processes that satisfy the stakeholder's need. The architecture is represented by a set of models that communicate an integrated view of the product's intent and purpose, and the interactions and interfaces required among all the different participating entities. The product's purpose is articulated in terms of business objectives (market, cost, functionality, performance, and time to deliver). The set of models includes sufficient variety to convey information appropriately to the stakeholders, designers/developers, specialty engineering, operations, manufacturers, management, and marketing and sales personnel.

Different architecture frameworks have been developed to guide product teams in defining the product architecture for commercial and for public enterprises. In general, an architecture framework describes a "view," meaning a "collection of models that represent the whole system from the perspective of a set of related stakeholder concerns." Prime examples of architecture frameworks are the Zachman framework (Zachman 1992), The Open Group Architecture Framework (TOGAF) (TOGAF 2011), the Enhanced-Telecom Operations Map (e-TOM), just to mention a few in the commercial sector. In the case of public enterprises a few architecture frameworks include the Department of Defense Architecture Framework (DODAF 2.0) (DoD 2010), the Federal Enterprise Architecture Framework (FEAF) (FEA 2001), the British Ministry of Defense Architecture Framework (MODAF) (MOD 2004), etc.

Differences between acquired products and offered products play an important role in defining product system requirements. Acquired products are life cycle-managed directly by the acquirer; for instance, acquired defense systems are defined, developed, tested, owned, operated, maintained and upgraded by the defense agency. See the article Product Systems Engineering Key Aspects within this KA.

Figure 2. System Architectural Description Elements (Adapted from Wasson 2006). Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

Specialty Engineering Integration

The INCOSE SE 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.”

Areas of expertise that fall under this umbrella definition include logistics support, electromagnetic compatibility analysis, environmental impact, human factors, safety and health analysis, and training. The unique characteristics, requirements, and design challenges of a system-of-interest all help determine the areas of specialty that apply.

A number of specialty engineering areas are typically important to systems engineers working on the development, deployment, and sustainment of product systems. For example, logistics support is essential for fielded product systems that require maintenance and repair. The delivery of services, materials, parts, and software necessary for supporting the system must all be considered very early in the development activity. These factors should usually be considered before the system requirements and concept definition are complete. To integrate these specialty disciplines sufficiently early on, the systems engineer needs to know what specialties relate to the system under development, how they relate to the systems engineering process, and how to integrate them into the life cycle process.

For product systems with significant hardware content and that operate in challenging environments, the following specialty engineering areas must usually be considered:

  • manufacturability,
  • reliability and maintainability,
  • certification (essential where human safety is an issue),
  • logistics support,
  • electromagnetic compatibility (if they radiate),
  • environmental impact,
  • human factors,
  • safety and health, and
  • training.

The relationship of these specialty areas to the systems engineering process must be understood and considered. The key aspects of the relationship are:

  • when the specialty needs to be considered,
  • what essential data or information it provides,
  • the consequences of not including the specialty in the systems engineering process, and
  • 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.” Some of what we consider specialty engineering in the present article, Eisner includes among his “thirty elements” of systems engineering, but not as part of the specialty engineering element.

There is no standard list of specialty engineering disciplines. What is considered specialty engineering varies according to the community to which the systems engineering belongs, and sometimes to the preferences of the customer.

References

Works Cited

ANSI/IEEE. 2000. Recommended practice for architectural description for software-intensive systems. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.

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

Eisner, H. 2008. "Chapter 7. Essentials of Project and Systems Engineering Management," in The Thirty Elements of Systems Engineering, 3rd ed. New York, NY, USA: John Wiley & Sons.

Grady, J. 2006. "Chapter 3.7. System Requirements Analysis," in Specialty Engineering Requirements Analysis. New York, NY, USA: Academic Press.

Grady, J. 2006. System Requirements Analysis. New York, NY, USA: Academic Press.

Grady, J. 2010. Systems Synthesis - Product and Process Design. Boca Raton, FL, USA: CRC Press.

Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Boston, MA, USA: Auerbach Publications.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

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.ISO/IEC 15288:2015.

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.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Maier, M., and E. Rechtin. 2009. The Art of Systems Architecting, 3rd ed. Boca Raton, FL, USA: CRC Press.

MOD. 2004. Ministry of Defence Architecture Framework (MODAF), version 2. London, UK: UK Ministry of Defence.

The Open Group. 2011. TOGAF, version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.

Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.

Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." IBM Systems Journal. 31 (3): 590-616.

Primary References

Eisner, H. 2008. "Chapter 7. Essentials of Project and Systems Engineering Management," in The Thirty Elements of Systems Engineering, 3rd ed. New York, NY, USA: John Wiley & Sons.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.

Additional References

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.

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

Grady, J. 2006. "Chapter 3.7. System Requirements Analysis," in Specialty Engineering Requirements Analysis. New York, NY, USA: Academic Press.

Grady, J. 2006. System Requirements Analysis. New York, NY: Academic Press.

Grady, J. 2010. Systems Synthesis- Product and Process Design. Boca Raton, FL, USA: CRC Press.

Hybertson, D. 2009. Model-oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Boston, MA, USA: Auerbach Publications.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

ISO/IEC. 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.

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.

Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™." Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.

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