Systems Engineering and Other Disciplines
As discussed in the Scope and Context of the SEBoK topic, there are many touch points and overlaps between systems engineering (SE) and other disciplines. Systems engineers should have a basic understanding of the nature of these other disciplines, and often need to understand aspects of another discipline in detail. This article describes the landscape of disciplines that are intertwined with SE. For a closer view of the individual disciplines, see Part 6.
Engineering Disciplines Other than Systems Engineering
Engineering disciplines are mostly component-oriented and value-neutral in their intellectual content (Boehm and Jain 2006). Their underlying laws and equations, such as Ohm’s Law, Hooke’s Law, Newton’s Laws, Maxwell’s equations, the Navier-Stokes equations, Knuth’s compendia of sorting and searching algorithms, and Fitts’s Law of human movement, pertain to performance in a system-of-interest. They do not address how that performance contributes to the value propositions of stakeholders.
In contrast, SE is more holistic than component-oriented, and more stakeholder value-oriented than value-neutral, performance-oriented in its intellectual content. Realizing successful systems requires reasoning with stakeholders about the relative value of alternative realizations, and about the organization of components and people into a system that satisfies the often-conflicting value propositions of stakeholders. Stakeholders who are critical to the system’s success include funders, owners, users, operators, maintainers, manufacturers, and safety and pollution regulators.
In some disciplines, the engineer evaluates and integrates design elements into a system that satisfies proxies of value. The wider the scope of the SoI, the broader the set of SE skills the engineer needs.
For example, an aeronautical engineer might integrate mechanical, electrical, fluid, combustion-chemical, software, and cockpit design elements into a system that satisfies proxies of value like flight range, payload capacity, fuel consumption, maneuverability, and cost of production and maintenance. In so doing, the engineer operates partly as a systems engineer. The SoI is the aircraft itself and the engineer applies aircraft-domain expertise.
However, the same engineer could participate in the engineering of passenger services, airport configurations, baggage handling, and local surface transportation options. All of these contribute to the value propositions of success-critical stakeholders. The SoIs are wider, and the engineer needs broader SE knowledge, skills, and abilities to operate as a systems engineer. The aircraft-domain expertise remains needed for effective engineering of the wider systems. As discussed in (Guest 1991), most good systems engineers are “T-shaped” people, with both a working knowledge of wider-system considerations, and a deep expertise in a relevant domain, such as aeronautical, manufacturing, software, or human factors engineering.
Engineering disciplines that are intertwined with SE include software engineering (SwE), human factors engineering, and industrial engineering. SwE and SE are not just allied disciplines, they are intimately intertwined (Boehm 1994). Most functionality of commercial and government systems is now implemented in software, and software plays a prominent or dominant role in differentiating competing systems in the marketplace. Software is usually prominent in modern systems architectures and is often the “glue” for integrating complex system components.
The scope of SwE includes both software SE and software construction, but does not include hardware SE. Thus neither SwE nor SE is a subset of the other. See Figure 2 in Scope and Context of the SEBoK. For a definition of the relationship between the SEBoK and the Guide to the Software Engineering Body of Knowledge (SWEBOK), which is published by the Institute of Electrical and Electronics Engineers (IEEE) (Abran et al. 2004) and is currently under revision, see Systems Engineering and Software Engineering.
Human factors engineering, from micro-ergonomics to macro-ergonomics, is intertwined with SE (Booher 2003; Pew-Mavor 2007). See Human Systems Integration in Part 6.
Industrial engineering overlaps significantly with SE in the industrial domain, but also includes manufacturing and other implementation activities outside of SE. See Systems Engineering and Industrial Engineering in Part 6.
Finally, to field a successful system, a systems engineer may need to know one or more of the many specialty fields in engineering, e.g., security, safety, reliability, availability, and maintainability engineering. Most of these are considered professional disciplines in their own right and many have their own bodies of knowledge. For explanations of how these disciplines relate to SE, overviews of what most systems engineers need to know about them, and references within their bodies of knowledge, see Systems Engineering and Specialty Engineering in Part 6.
Non-Engineering Disciplines
SE is intimately intertwined with two non-technical disciplines: technical management (TM), and procurement and acquisition (also known as acquisition and procurement). TM often falls within the purview of a systems engineer. Many SE textbooks, competency models, and university programs include material about TM. TM is a specialization of project management (PM). SE and PM have significant common content in TM, but neither is a subset of the other. See Figure 1 in the article Scope and Context of the SEBoK. For a definition of the relationship between the SEBoK and the Guide to the Project Management Body of Knowledge (PMBOK), which is published by the Project Management Institute (PMI) (PMI 2013), see Systems Engineering and Project Management in Part 6.
Procurement and acquisition practitioners draw upon SE to determine the scope and overall requirements of the system to be procured or acquired. They then prepare requests for proposals and statements of work, determine evaluation criteria, and design source selection processes. Once a leading source is selected, they decide upon contracting options that encompass payments, reviews, audits, incentive fees, acceptance criteria, procedures, and the nature of deliverables. Finally, they monitor progress with respect to plans (including those for SE), and negotiate and execute changes and corrective actions. Many of these activities amount to specialty disciplines within procurement and acquisition. See the article Related Disciplines in Part 6.
References
Works Cited
Abran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 version. Los Alamitos, CA, USA and Tokyo, Japan: IEEE Computer Society Press.
Boehm, B. and A. Jain. 2006. "A Value-Based Theory of Systems Engineering." Proceedings, INCOSE IS 2006. Also available at: http://sunset.usc.edu/csse/TECHRPTS/2006/usccse2006-619/usccse2006-619.pdf.
Booher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.
Guest, D. 1991. "The hunt is on for the Renaissance Man of computing." The Independent. London, England: September 17, 1991.
INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.
Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, DC, USA: The National Academies Press.
PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
Primary References
Abran, A., J. W. Moore, P. Bourque, R. Dupuis, and L. L. Tripp. 2004. Guide to the Software Engineering Body of Knowledge (SWEBOK), 2004 version. Los Alamitos, CA, USA and Tokyo, Japan: IEEE Computer Society Press.
Booher, H. 2003. Handbook of Human-Systems Integration. New York, NY, USA: John Wiley & Sons Inc.
Gallagher, B., M. Phillips, K. Richter, and S. Shrum. 2011. CMMI For Acquisition: Guidelines for Improving the Acquisition of Products and Services, second ed. Upper Saddle River, NJ, USA: Addison Wesley.
Paulk, M., C. Weber, B. Curtis, and M. Chrissis. 1995. The Capability Maturity Model: Guidelines for Improving the Software Process. Upper Saddle River, NJ, USA: Addison Wesley.
Pyster, A. (ed.). 2009. Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines for Graduate Degree Programs in Software Engineering. Integrated Software & Systems Engineering Curriculum Project. Hoboken, NJ, USA: Stevens Institute of Technology, September 30, 2009.
Pew, R. and A. Mavor. 2007. Human-System Integration in the System Development Process. Washington, DC, USA: The National Academies Press.
PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
Additional References
None.
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