Product as a System Fundamentals
Product Elements and Connections
Product systems consist of product elements and two kinds of connections: among elements, and 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 diagram, data flow diagram, free body diagram, interface control diagram, port specification, energy transfer diagram, and so on. Product SE 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 ten feet apart
- one element is inside another
Motion-related relationships:
- the relative velocity of two elements is X
- the relative acceleration between two elements is X
Temporal relationships:
- one element exists before another
- two elements must exist at the same time
- two elements must be separated in time by three years
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 roadmap, and project schedule chart.
Social relationships
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 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 Product SE. Social relationships can affect the overall performance or behavior of a product system, to the point of determining its success or failure.
Core Product & 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.
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 acquirer, the system of interest 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.
- Provided products are integrated into the system of systems.
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.” 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.”
A product’s purpose (stakeholder’s desire) is realized by a product system (the SOI). Because 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, 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 a good 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 traceability being a key aspect of SE). Verification & Validation plans created during the requirements phase are the basis of testing certify 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 purpose is articulated in terms of business objectives (market, cost, functionality, performance, 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 & sales personnel.
Different architectural Frameworks have been defined to guide product teams in defining the product architecture for commercial and for public enterprises. In general, an architectural framework describes a “view,” meaning a “collection of models that represent the whole system from the perspective of a set of related stakeholder concerns.”
Differences between acquired products and offered products play an important role in defining 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. See the Offered vs. Acquired Products article DOES NOT EXIST in this KA.
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.”
Areas of expertise that fall under this umbrella definition include logistics support, electromagnetic compatibility analysis, environmental impact, human factors, safety & 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, usually 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
3) Certification (essential where 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.” Some of what we consider specialty engineering in the present article, Eisner includes among his “thirty elements” of SE, 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 SE belongs, and sometimes to the preferences of the customer.
References
Works Cited
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.
Comments from 0.5 Wiki
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus