Difference between revisions of "Product as a System Fundamentals"

From SEBoK
Jump to: navigation, search
Line 1: Line 1:
== 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.”
  
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.
+
Connections between elements contain interactions and relationships (Hybertson 2009). A connection is more than a mere interface.
  
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.
+
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 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 encompass relationships between elements. These relationships can be spatial, motion-related, temporal,  or social.  
  
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.
+
Spatial relationships:  
 +
* one element is underneath another
 +
* two elements are ten feet apart
 +
* one element is inside another
  
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.  
+
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 (http://www.sebokwiki075.org/wiki/index.php?title=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.
  
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 ==
 
== 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 xEnabling systems are an important concept incorporated in the ISO/IEC 15288 standard.
+
A variety of systems (themselves being products or services) enable the development, delivery, operation and eventual disposal of a product, as shown in Figure 1The concept of enabling systems is defined in the ISO/IEC 15288 standard.
  
  
 
[[File:PSE_PAAS_Fig1.png|600px|thumb|left|Figure 1. Example of Enabling Systems (Lawson 2010) Reprinted with permission of Harold "Bud" Lawson.]]
 
[[File:PSE_PAAS_Fig1.png|600px|thumb|left|Figure 1. Example of Enabling Systems (Lawson 2010) Reprinted with permission of Harold "Bud" Lawson.]]
  
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 providedDuring 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.  
+
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 stageThese 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.  
  
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.  
+
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).  
  
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 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 ==
 
== 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.”
+
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) 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).
+
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 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, 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).
  
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.   
+
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.   
  
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 componentsThe reader is referred to (Maier 2009) Chapter 8 for a good introduction to Models and Modeling.
+
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 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 entitiesThe 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.  
+
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 SystemAn 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.  
  
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).
+
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.
  
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.
+
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.
  
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.
+
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 <font color=FF3300>Offered vs. Acquired Products article DOES NOT EXIST</font> in this KA.
 
   
 
   
 
[[File:PSE_PAAS_Fig2.png|725px|thumb|center|Figure 2. System Architectural Description Elements (Adapted from Wasson 2006) Permission Pending]]
 
[[File:PSE_PAAS_Fig2.png|725px|thumb|center|Figure 2. System Architectural Description Elements (Adapted from Wasson 2006) Permission Pending]]
Line 54: Line 84:
 
“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.
+
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.
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:
+
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:
  
 
1) Manufacturability
 
1) Manufacturability
Line 62: Line 93:
 
2) Reliability and Maintainability
 
2) Reliability and Maintainability
  
3) Certification (essential were human safety is an issue)
+
3) Certification (essential where human safety is an issue)
  
 
4) Logistics support
 
4) Logistics support
Line 86: Line 117:
 
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.”  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. 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.
+
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.
  
  

Revision as of 15:35, 28 February 2012

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 (http://www.sebokwiki075.org/wiki/index.php?title=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.


Figure 1. Example of Enabling Systems (Lawson 2010) Reprinted with permission of Harold "Bud" Lawson.

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.

Figure 2. System Architectural Description Elements (Adapted from Wasson 2006) Permission Pending

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:

1) Manufacturability

2) 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 v. 1.9.1 released 30 September 2018

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