Difference between revisions of "Guidance for Systems Engineering Customers"

From SEBoK
Jump to navigation Jump to search
m (Text replace - "Knowledge Area" to "knowledge area")
(19 intermediate revisions by 5 users not shown)
Line 1: Line 1:
  
Customers of [[Systems Engineering (glossary)|systems engineering]] (SE) provide resources to SE organizations and individuals, and receive SE products and services in return.  They are among the [[Stakeholder (glossary)|stakeholders]] for a [[System of Interest (SoI) (glossary)|system of interest]] (SoI). They and other stakeholders express needs and expectations for results that system engineers provide.  
+
Customers of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) provide resources to SE organizations and individuals, and receive SE products and services in return.  They are among the {{Term|Stakeholder (glossary)|stakeholders}} for a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI). They and other stakeholders express needs and expectations for results that systems engineers provide.  
  
Although their main SE activity is helping to define the [[System (glossary)|system]], customers must take account of all life cycle aspects. The better they understand the activities that systems engineers perform, the better customers know what to request, how to request it, how much to pay for it, and how to judge the quality and value of the results of systems engineering. In short, what customers need to grasp is how systems engineers participate in the realization of [[Engineered System (glossary)|engineered systems]] resulting in [[Product (glossary)|products]], [[Service (glossary)|services]], [[Enterprise (glossary)|enterprises]], and [[System of Systems (SoS) (glossary)|systems of systems]] (SoS).
+
Although their main SE activity is helping to define the {{Term|System (glossary)|system}}, customers must take account of all life cycle aspects. The better they understand the activities that systems engineers perform, the better customers know what to request, how to request it, how much to pay for it, and how to judge the quality and value of the results of systems engineering. In short, what customers need to grasp is how systems engineers participate in the realization of {{Term|Engineered System (glossary)|engineered systems}} resulting in {{Term|Product (glossary)|products}}, {{Term|Service (glossary)|services}}, {{Term|Enterprise (glossary)|enterprises}}, and {{Term|System of Systems (SoS) (glossary)|systems of systems}} (SoS).
  
 
The SEBoK assists the customers of systems engineering by providing a broad, comprehensive treatment of the concepts, principles, theory, and practice related to systems in general and SE in particular. Its references inform customers about books and articles that provide important perspectives on systems and SE.   
 
The SEBoK assists the customers of systems engineering by providing a broad, comprehensive treatment of the concepts, principles, theory, and practice related to systems in general and SE in particular. Its references inform customers about books and articles that provide important perspectives on systems and SE.   
  
 
Customers of SE include:  
 
Customers of SE include:  
*sponsors of internal SE organizations
+
*sponsors of internal SE organizations,
 
*organizations that maintain long-term customer-domain relationships with external SE organizations, and  
 
*organizations that maintain long-term customer-domain relationships with external SE organizations, and  
 
*organizations that outsource SE functions to general-purpose SE organizations.   
 
*organizations that outsource SE functions to general-purpose SE organizations.   
  
The two vignettes below show how the SEBoK can assist SE customers.  In one, the customer of an internal, corporate SE organization leads the transition to  a mobile supply chain management system. In the other, the customer of a mixture of customer-domain and other SE organizations presides over the SE of a catastrophe-response sSoS, which entails integration over multiple domains.
+
The two vignettes below show how the SEBoK can assist SE customers.  In one, the customer of an internal, corporate SE organization leads the transition to  a mobile supply chain management system. In the other, the customer of a mixture of customer-domain and other SE organizations presides over the SE of a catastrophe-response SoS, which entails integration over multiple domains.
  
 
==Use of Topics==
 
==Use of Topics==
 
For customers of SE, most parts of the SEBoK offer immediately relevant knowledge about SE.
 
For customers of SE, most parts of the SEBoK offer immediately relevant knowledge about SE.
  
[[SEBoK 1.0 Introduction|Part 1]]:
+
[[SEBoK Introduction|Part 1: SEBoK Introduction]]:
 
*explains the relationship between SE, system development, and project management,
 
*explains the relationship between SE, system development, and project management,
 
*summarizes overall trends in the rate of growth of systems interdependency, complexity, assurance levels, and pace of change, and of the evolving nature of integrated hardware-software-human systems, and  
 
*summarizes overall trends in the rate of growth of systems interdependency, complexity, assurance levels, and pace of change, and of the evolving nature of integrated hardware-software-human systems, and  
 
*provides pointers to other parts of the SEBoK of interest to customers.
 
*provides pointers to other parts of the SEBoK of interest to customers.
  
[[Systems Engineering and Management|Part 3]]:  
+
[[Systems Engineering and Management|Part 3: Systems Engineering and Management]]:  
 
*explains evolving system life cycle models and their elements, indicating which elements are SE-intensive (see [[Life Cycle Models]]),
 
*explains evolving system life cycle models and their elements, indicating which elements are SE-intensive (see [[Life Cycle Models]]),
 
*provides overall perspectives on customer participation in SE activity,
 
*provides overall perspectives on customer participation in SE activity,
Line 27: Line 27:
 
*explains how customers can express their concerns in the form of needs, expectations, and requirements (see [[System Definition]]).
 
*explains how customers can express their concerns in the form of needs, expectations, and requirements (see [[System Definition]]).
  
[[Applications of Systems Engineering|Part 4]]:
+
[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]]:
*explains how the SE function varies by class of system [[Product (glossary)|product]], [[Service (glossary)|service]], [[Enterprise (glossary)|enterprise]], and [[System of Systems (SoS) (glossary)|systems of systems]] engineering).
+
*explains how the SE function varies by class of system {{Term|Product (glossary)|product}}, {{Term|Service (glossary)|service}}, {{Term|Enterprise (glossary)|enterprise}}, and {{Term|System of Systems (SoS) (glossary)|systems of systems}} engineering).
  
[[Systems Engineering and Other Disciplines|Part 6]]:  
+
[[Systems Engineering and Other Disciplines|Part 6: Systems Engineering and Other Disciplines]]:  
 
*explains how SE relates to project management, procurement and acquisition, and specialty engineering for such customer-intensive specialties as safety, security, maintainability, usability, and affordability.
 
*explains how SE relates to project management, procurement and acquisition, and specialty engineering for such customer-intensive specialties as safety, security, maintainability, usability, and affordability.
  
[[Systems_Engineering_Implementation_Examples|Part 7]]:
+
[[Systems_Engineering_Implementation_Examples|Part 7: Systems Engineering Implementation Examples]]:
*provides case studies and vignettes to illustrate how the parts have been used in similar situations, presenting successes to emulate and failures to avoid.
+
*provides case studies and examples to illustrate how the parts have been used in similar situations, presenting successes to emulate and failures to avoid.
  
 
If there is a central theme here, it is that the quality of customer input is critical. That is because the systems engineer evaluates customer input, then uses it in formulating an approach to defining and realizing the system. [[Systems Engineering and Management|Part 3]] addresses this, explaining that the customer should expect the systems engineer to provide:
 
If there is a central theme here, it is that the quality of customer input is critical. That is because the systems engineer evaluates customer input, then uses it in formulating an approach to defining and realizing the system. [[Systems Engineering and Management|Part 3]] addresses this, explaining that the customer should expect the systems engineer to provide:
 
*a well-architected product, service, enterprise, or system of systems that meets customer needs and expectations (again, this depends on high quality input from stakeholders — see [[System Definition]])
 
*a well-architected product, service, enterprise, or system of systems that meets customer needs and expectations (again, this depends on high quality input from stakeholders — see [[System Definition]])
 
*a managed life cycle model from the customer need and requirements to the delivered product, service, enterprise or system of systems (see [[Life Cycle Models]])
 
*a managed life cycle model from the customer need and requirements to the delivered product, service, enterprise or system of systems (see [[Life Cycle Models]])
*[[System Verification|verification]] that the system of interest (SoI) meets the needs and requirements of the stakeholders, and
+
*both [[System Verification|verification]] that the system-of-interest (SoI) meets the needs and requirements of the stakeholders, and [[System Validation|validation]] that the final result, when deployed in an operational environment, provides the value added that was desired are critical to systems engineering (see [[System Realization]] and [[System Deployment and Use]]).
*[[System Validation|validation]] that the final result, when deployed in an operational environment, provides the value added that was desired are critical to systems engineering (see [[System Realization]] and [[System Deployment and Use]]).
 
  
 
==Implementation Examples==
 
==Implementation Examples==
Good examples provide a basis for deeper understanding.  In [[Systems Engineering Implementation Examples|Part 7]], the SEBoK provides summaries of and references to full case studies, as well as overviews of events (vignettes).  These are linked back to the appropriate areas of the SEBoK and a [[Matrix of Implementation Examples|matrix]] is provided that shows the primary areas of the SEBoK addressed by each case study or vignette.  Readers can use the matrix to find case studies and vignettes - and through these, references - that relate to their concerns.   
+
Good examples provide a basis for deeper understanding.  In [[Systems Engineering Implementation Examples|Part 7]], the SEBoK provides summaries of and references to full case studies and examples.  These are linked back to the appropriate areas of the SEBoK and a [[Matrix of Implementation Examples|matrix]] is provided that shows the primary areas of the SEBoK addressed by each example.  Readers can use the matrix to find case studies and examples- and through these, references - that relate to their concerns.   
  
 
===Vignette: Mobile Supply Chain Management===
 
===Vignette: Mobile Supply Chain Management===
Line 52: Line 51:
 
Barbara decides that these challenges require formal SE. As a first step, she plans to put together a Next-Generation Supply Chain Management System integrated product team (IPT). Members of the IPT will include Barbara's supply chain experts, her supply-chain success-critical stakeholders, and the corporate SE organization.  
 
Barbara decides that these challenges require formal SE. As a first step, she plans to put together a Next-Generation Supply Chain Management System integrated product team (IPT). Members of the IPT will include Barbara's supply chain experts, her supply-chain success-critical stakeholders, and the corporate SE organization.  
  
Barbara has never used the corporate SE organization before, and wants to better understand an SE organization’s overall capabilities and modes of operation. She turns to the SEBoK for answers to the questions about SE that are on her mind:
+
Barbara has never used the corporate SE organization before and wants to better understand an SE organization’s overall capabilities and modes of operation. She turns to the SEBoK for answers to the questions about SE that are on her mind:
 
   
 
   
 
*How do we maintain continuity of service while pursuing incremental development?
 
*How do we maintain continuity of service while pursuing incremental development?
Line 86: Line 85:
 
*candidate solution capabilities in communications, data access, geolocation services, public emergency warning systems, coordinating evacuation procedures, architectural connector approaches for improving interoperability, and sharable models for evaluating alternative solution approaches.
 
*candidate solution capabilities in communications, data access, geolocation services, public emergency warning systems, coordinating evacuation procedures, architectural connector approaches for improving interoperability, and sharable models for evaluating alternative solution approaches.
  
The workshop brings the primary organizations involved in catastrophe responses together with the most capable SoS SE provider organizations. The results of their discussions provide Ahmed and his Minister with sufficient information to prepare a phased plan, budget, and schedule for incremental development of improved catastrophe response capabilities, beginning with simple interoperability aids and analysis of architecture alternatives for performance, scalability, and feasibility of evolution from the initial simple fixes. The plan is then iterated with the key stakeholders, and converged to a common-consensus approach for achieving strong, credible early improvements and a way forward to a much more scalable and cost-effective catastrophe-response SoS.
+
The workshop brings the primary organizations involved in catastrophe responses together with the most capable SoS SE provider organizations. The results of their discussions provide Ahmed and his Minister with sufficient information to prepare a phased plan, budget, and schedule for incremental development of improved catastrophe response capabilities, beginning with simple interoperability aids and analyses of architecture alternatives for performance, scalability, and feasibility of evolution from the initial simple fixes. The plan is then iterated with the key stakeholders and converged to a common-consensus approach for achieving strong, credible early improvements and a way forward to a much more scalable and cost-effective catastrophe-response SoS.
  
 
This vignette is based on the Regional Area Crisis Response SoS (RACRS) in (Lane and Bohn 2010).
 
This vignette is based on the Regional Area Crisis Response SoS (RACRS) in (Lane and Bohn 2010).
Line 101: Line 100:
 
INCOSE. 2011. ''Systems Engineering Handbook'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
 
INCOSE. 2011. ''Systems Engineering Handbook'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
  
Jamshidi, M. (ed.) 2009. ''Systems of Systems Engineering - Principles and Applications''. Boca Raton, FL, USA: CRC Press.
+
Jamshidi, M. Ed. 2009. ''Systems of Systems Engineering - Principles and Applications''. Boca Raton, FL, USA: CRC Press.
  
Sage, A., and Rouse, W. (eds.) 1999. ''Handbook of Systems Engineering and Management''. Hoboken, NJ, USA: John Wiley and Sons, Inc.  
+
Sage, A., and Rouse, W. Eds. 1999. ''Handbook of Systems Engineering and Management''. Hoboken, NJ, USA: John Wiley and Sons, Inc.  
  
U.S. Department of Defense. 2008. ''Systems Engineering Guide for System of Systems'', version 1.0. DOI= http://www.acq.osd.mil/sse/docs/SE-Guide-for-SoS.pdf
+
U.S. Department of Defense. 2008. ''Systems Engineering Guide for System of Systems'', version 1.0. Arlington, VA, USA: U.S. Department of Defense. Available at: http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed April 18, 2013.
  
 
===Additional References===
 
===Additional References===
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''Guide to the Software Engineering Body of Knowledge (SWEBOK)''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok
+
P. Bourque and R.E. Fairley Eds. 2014. ''Guide to the Software Engineering Body of Knowledge'', Version 3.0.  Los Alamitos, CA, USA: IEEE Computer Society. Available at http://www.swebok.org.
  
 
----
 
----
Line 116: Line 115:
 
[[Category:Part 1]][[Category:Use Case]]
 
[[Category:Part 1]][[Category:Use Case]]
 
[[Category:SEBoK Users and Uses]]
 
[[Category:SEBoK Users and Uses]]
{{DISQUS}}
+
 
 +
<center>'''SEBoK v. 2.4, released 19 May 2021'''</center>

Revision as of 19:46, 19 May 2021

Customers of systems engineeringsystems engineering (SE) provide resources to SE organizations and individuals, and receive SE products and services in return. They are among the stakeholdersstakeholders for a system-of-interestsystem-of-interest (SoI). They and other stakeholders express needs and expectations for results that systems engineers provide.

Although their main SE activity is helping to define the systemsystem, customers must take account of all life cycle aspects. The better they understand the activities that systems engineers perform, the better customers know what to request, how to request it, how much to pay for it, and how to judge the quality and value of the results of systems engineering. In short, what customers need to grasp is how systems engineers participate in the realization of engineered systemsengineered systems resulting in productsproducts, servicesservices, enterprisesenterprises, and systems of systemssystems of systems (SoS).

The SEBoK assists the customers of systems engineering by providing a broad, comprehensive treatment of the concepts, principles, theory, and practice related to systems in general and SE in particular. Its references inform customers about books and articles that provide important perspectives on systems and SE.

Customers of SE include:

  • sponsors of internal SE organizations,
  • organizations that maintain long-term customer-domain relationships with external SE organizations, and
  • organizations that outsource SE functions to general-purpose SE organizations.

The two vignettes below show how the SEBoK can assist SE customers. In one, the customer of an internal, corporate SE organization leads the transition to a mobile supply chain management system. In the other, the customer of a mixture of customer-domain and other SE organizations presides over the SE of a catastrophe-response SoS, which entails integration over multiple domains.

Use of Topics

For customers of SE, most parts of the SEBoK offer immediately relevant knowledge about SE.

Part 1: SEBoK Introduction:

  • explains the relationship between SE, system development, and project management,
  • summarizes overall trends in the rate of growth of systems interdependency, complexity, assurance levels, and pace of change, and of the evolving nature of integrated hardware-software-human systems, and
  • provides pointers to other parts of the SEBoK of interest to customers.

Part 3: Systems Engineering and Management:

  • explains evolving system life cycle models and their elements, indicating which elements are SE-intensive (see Life Cycle Models),
  • provides overall perspectives on customer participation in SE activity,
  • identifies customer influence points on SE activity, and
  • explains how customers can express their concerns in the form of needs, expectations, and requirements (see System Definition).

Part 4: Applications of Systems Engineering:

Part 6: Systems Engineering and Other Disciplines:

  • explains how SE relates to project management, procurement and acquisition, and specialty engineering for such customer-intensive specialties as safety, security, maintainability, usability, and affordability.

Part 7: Systems Engineering Implementation Examples:

  • provides case studies and examples to illustrate how the parts have been used in similar situations, presenting successes to emulate and failures to avoid.

If there is a central theme here, it is that the quality of customer input is critical. That is because the systems engineer evaluates customer input, then uses it in formulating an approach to defining and realizing the system. Part 3 addresses this, explaining that the customer should expect the systems engineer to provide:

  • a well-architected product, service, enterprise, or system of systems that meets customer needs and expectations (again, this depends on high quality input from stakeholders — see System Definition)
  • a managed life cycle model from the customer need and requirements to the delivered product, service, enterprise or system of systems (see Life Cycle Models)
  • both verification that the system-of-interest (SoI) meets the needs and requirements of the stakeholders, and validation that the final result, when deployed in an operational environment, provides the value added that was desired are critical to systems engineering (see System Realization and System Deployment and Use).

Implementation Examples

Good examples provide a basis for deeper understanding. In Part 7, the SEBoK provides summaries of and references to full case studies and examples. These are linked back to the appropriate areas of the SEBoK and a matrix is provided that shows the primary areas of the SEBoK addressed by each example. Readers can use the matrix to find case studies and examples- and through these, references - that relate to their concerns.

Vignette: Mobile Supply Chain Management

Barbara Bradley is the Director of Supply Chain Management Systems for a large manufacturing company. Her main area of expertise is transportation logistics. She has led the evolution of a highly successful corporate supply chain management system based on desktop and mainframe technology, more by making incremental strategic choices than by applying formal SE.

Now, many of her suppliers and distributors adopt mobile devices and cloud services and Barbara sees that her own company must do the same. The company's status quo approach of incremental, ad hoc choices is clearly inadequate for a technology transition of this magnitude. Not only that, but the company must evolve to the new mode of operation while providing continuity of service to the supply chain stakeholders.

Barbara decides that these challenges require formal SE. As a first step, she plans to put together a Next-Generation Supply Chain Management System integrated product team (IPT). Members of the IPT will include Barbara's supply chain experts, her supply-chain success-critical stakeholders, and the corporate SE organization.

Barbara has never used the corporate SE organization before and wants to better understand an SE organization’s overall capabilities and modes of operation. She turns to the SEBoK for answers to the questions about SE that are on her mind:

  • How do we maintain continuity of service while pursuing incremental development?
    • What choices about life cycle models can make this possible?
  • What is the role of the customer in defining systems of interest (SoIs)?
    • How do we provide guidance to the customer in expressing needs, concerns, and requirements?
  • What is the role of the customer at early decision milestones?
    • How do we ensure that results of our interaction with the customer include well-architected products and thorough development plans, budgets, and schedules?
  • What is the role of the customer in product acceptance, specifically when we verify stakeholder requirements and when we validate the final result?

Barbara seeks the answer to one question in Part 4: Applications of Systems Engineering:

  • Given that a supply chain management system combines product, service, enterprise, and SoS views, how do we understand what goes into all those views, and keep the overall picture clear?

Barbara's final question is addressed in Part 6: Systems Engineering and Other Disciplines:

  • How do we integrate SE and software engineering (SwE)?

Once in command of the answers to these questions, Barbara is ready to lead the IPT in analyzing, negotiating, and defining an approach that is satisfactory to all of the success-critical stakeholders. By having the IPT members read the portions of the SEBoK that she has found most valuable, Barbara begins to build a shared vision within the IPT. As the IPT defines a Next-Generation Supply Chain Management System and prepares the transition from the old system to the new, the SEBoK is an important tool and resource.

Vignette: Catastrophe-Response System of Systems

Ahmed Malik is the Information Systems Division General Manager in his country’s Department of Natural Resources. The country suffers frequent wildfires that destroy crops, forests, villages, and parts of cities, and also cause problems with emergency care, crime prevention, and the water supply.

During a recent catastrophic wildfire, personnel responsible for firefighting, crime prevention, traffic control, water supply maintenance, emergency care facilities, and other key capabilities found themselves unable to communicate with each other. As a result, the Minister for Natural Resources has been tasked with improving the country’s catastrophe response capabilities, and has named Ahmed as the SE customer lead for this effort.

The Minister suggests that Ahmed organize a workshop to scope the problem and explore candidate solutions to the communications problems. Ahmed invites the various actors involved in catastrophe response — medical, insurance, and news media organizations from both public and private sectors. He also invites SE organizations with SoS experience.

Ahmed has strong experience in information SE, but none in the development of SoSs. To come up to speed in his role as the SE customer lead, Ahmed turns to the SEBoK Part 3: Systems Engineering and Management. To better understand the challenges of SoS SE, he studies the SoS knowledge area in Part 4, and its references. Ahmed also schedules meetings with the leading SoS SE provider organizations, who are eager to tell him about their capabilities. Overall, Ahmed looks for both guidance and pointers to candidate solution sources in the SEBoK.

Thus prepared, Ahmed structures the workshop to address three key challenges:

  • mutual understanding of organization roles, responsibilities, and authority
  • summary analyses of previous catastrophe response communication gaps and needs
  • candidate solution capabilities in communications, data access, geolocation services, public emergency warning systems, coordinating evacuation procedures, architectural connector approaches for improving interoperability, and sharable models for evaluating alternative solution approaches.

The workshop brings the primary organizations involved in catastrophe responses together with the most capable SoS SE provider organizations. The results of their discussions provide Ahmed and his Minister with sufficient information to prepare a phased plan, budget, and schedule for incremental development of improved catastrophe response capabilities, beginning with simple interoperability aids and analyses of architecture alternatives for performance, scalability, and feasibility of evolution from the initial simple fixes. The plan is then iterated with the key stakeholders and converged to a common-consensus approach for achieving strong, credible early improvements and a way forward to a much more scalable and cost-effective catastrophe-response SoS.

This vignette is based on the Regional Area Crisis Response SoS (RACRS) in (Lane and Bohn 2010).

Summary

For the customers of SE, the SEBoK provides both general and specific knowledge that will help users gain important insight in relating to systems engineers. Key to this is learning about life cycles, the definition of SoIs, and how to provide guidance in expressing needs, concerns, and requirements. Further, customers need to know what to expect as a result of SE activities in the form of well-architected products, services, enterprises, or systems of systems and a managed life cycle. The results of verification of stakeholder requirements and the validation of the final result in respect to fulfilling the user needs are vital.

References

Works Cited

Lane, J. and T. Bohn. 2010. Using SySML to Evolve Systems of Systems. Los Angeles, CA, USA: USC CSSE Technical Report. USC-CSSE-2010-506.

Primary References

INCOSE. 2011. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.

Jamshidi, M. Ed. 2009. Systems of Systems Engineering - Principles and Applications. Boca Raton, FL, USA: CRC Press.

Sage, A., and Rouse, W. Eds. 1999. Handbook of Systems Engineering and Management. Hoboken, NJ, USA: John Wiley and Sons, Inc.

U.S. Department of Defense. 2008. Systems Engineering Guide for System of Systems, version 1.0. Arlington, VA, USA: U.S. Department of Defense. Available at: http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed April 18, 2013.

Additional References

P. Bourque and R.E. Fairley Eds. 2014. Guide to the Software Engineering Body of Knowledge, Version 3.0. Los Alamitos, CA, USA: IEEE Computer Society. Available at http://www.swebok.org.


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